Docker: パフォーマンスチューニングとトラブルシューティング

# ステップ 1: リソース使用量を確認
docker stats --no-stream

# ステップ 2: ホストの I/O を確認
iostat -x 1 5

# ステップ 3: ボトルネックを特定
docker system df -v

# 全コンテナをリアルタイムで監視
docker stats

# ワンショットスナップショット
docker stats --no-stream

# カスタムフォーマット
docker stats --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.NetIO}}\t{{.BlockIO}}"

# stress を実行して CPU 負荷をシミュレート
docker run --rm --name stress-test \
  --cpus=1 \
  progrium/stress --cpu 1 --timeout 30s

# 別のターミナルで docker stats を使って監視
docker stats stress-test --no-stream

# 50 MB のメモリ制限でコンテナを起動
docker run -d --name oom-test \
  --memory=50m \
  --restart=on-failure:3 \
  progrium/stress --vm 1 --vm-bytes 100M --timeout 10s

# OOM イベントを監視
docker events --filter event=oom --since 1m

# 終了コードを確認
docker inspect oom-test --format='ExitCode: {{.State.ExitCode}}, OOMKilled: {{.State.OOMKilled}}'

# Docker のディスク使用量を表示
docker system df

# 詳細な内訳
docker system df -v

TYPE            TOTAL   ACTIVE  SIZE      RECLAIMABLE
Images          12      5       4.2GB     2.8GB (66%)
Containers      8       3       350MB     280MB (80%)
Local Volumes   5       3       1.2GB     500MB (41%)
Build Cache     45      0       800MB     800MB (100%)

# 未使用のデータ (イメージ、コンテナ、ボリューム、ビルドキャッシュ) を削除
docker system prune

# より積極的: 未使用のイメージをすべて削除 (dangling だけでなく)
docker system prune -a

# ビルドキャッシュのみを削除
docker builder prune

# ボリュームを削除 (注意: データが削除されます)
docker volume prune

# コンテナ内で iperf3 サーバーを起動
docker run -d --name iperf-server --network host networkstatic/iperf3 -s

# 別のコンテナから iperf3 クライアントを実行
docker run --rm --network host networkstatic/iperf3 -c localhost -t 10

# 異なるネットワーク上の 2 つのコンテナ間でテスト
docker run --rm --network app-net networkstatic/iperf3 -c db -t 5

# コンテナライフサイクルイベントを監視
docker events --filter type=container

# 特定のイベントでフィルタ
docker events --filter event=oom --filter event=die --filter event=restart

# 時刻ベースのフィルタ
docker events --since "2024-01-15T03:00:00" --until "2024-01-15T04:00:00"

# コンテナのメイン PID を取得
PID=$(docker inspect --format='{{.State.Pid}}' myapp)

# コンテナのネットワーク名前空間に進入してデバッグ
nsenter -t $PID -n tcpdump -i eth0 -c 100 port 8080

# コンテナのプロセス名前空間に進入
nsenter -t $PID -p -m strace -p 1

# ============================================
# 完全な手順: OOM 診断と修正
# カバー範囲: stats、events、logs、inspect、修正
# ============================================

# 1. 問題のあるコンテナをデプロイ
docker run -d \
  --name leaky-app \
  --memory=100m \
  --restart=on-failure:5 \
  -p 8080:8080 \
  myapp:1.0

# 2. リソース使用量を監視
docker stats leaky-app --no-stream

# 3. メモリリークをシミュレート (OOM を発生させる)
docker exec leaky-app python -c "
import itertools
data = []
for i in itertools.count():
    data.append('x' * 1024 * 1024)  # 1 MB ずつ
    if i % 10 == 0:
        import time; time.sleep(0.1)
"

# 4. OOM イベントをキャプチャ
docker events --filter container=leaky-app --filter event=oom --since 1m

# 5. 終了コードと OOM ステータスを確認
docker inspect leaky-app --format='
ExitCode: {{.State.ExitCode}}
OOMKilled: {{.State.OOMKilled}}
Memory Limit: {{.HostConfig.Memory}}
'

# 6. アプリログでメモリパターンを確認
docker logs --tail 100 leaky-app 2>&1 | grep -i "memory\|alloc\|oom"

# 7. 対策: メモリ上限を引き上げる
docker stop leaky-app && docker rm leaky-app
docker run -d \
  --name leaky-app \
  --memory=512m \
  --restart=on-failure:5 \
  --log-opt max-size=10m \
  --log-opt max-file=3 \
  -p 8080:8080 \
  myapp:1.0

# 8. 監視アラートを設定
docker events --filter event=oom | while read event; do
  echo "ALERT: OOM detected at $(date)" >> /var/log/docker-alerts.log
done