Performance Tuning and Troubleshooting

# Step 1: Check resource usage
docker stats --no-stream

# Step 2: Check host IO
iostat -x 1 5

# Step 3: Identify the bottleneck
docker system df -v

# Real-time stats for all containers
docker stats

# One-time snapshot
docker stats --no-stream

# Custom format
docker stats --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.NetIO}}\t{{.BlockIO}}"

# Run stress to simulate CPU load
docker run --rm --name stress-test \
  --cpus=1 \
  progrium/stress --cpu 1 --timeout 30s

# Monitor with docker stats (in another terminal)
docker stats stress-test --no-stream

# Start container with 50 MB memory limit
docker run -d --name oom-test \
  --memory=50m \
  --restart=on-failure:3 \
  progrium/stress --vm 1 --vm-bytes 100M --timeout 10s

# Watch for OOM events
docker events --filter event=oom --since 1m

# Check exit code
docker inspect oom-test --format='ExitCode: {{.State.ExitCode}}, OOMKilled: {{.State.OOMKilled}}'

# Show Docker disk usage
docker system df

# Detailed breakdown
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%)

# Remove unused data (images, containers, volumes, build cache)
docker system prune

# More aggressive: remove all unused images (not just dangling)
docker system prune -a

# Remove build cache only
docker builder prune

# Remove volumes (WARNING: deletes data)
docker volume prune

# Start iperf3 server in a container
docker run -d --name iperf-server --network host networkstatic/iperf3 -s

# Run iperf3 client from another container
docker run --rm --network host networkstatic/iperf3 -c localhost -t 10

# Test between two containers on different networks
docker run --rm --network app-net networkstatic/iperf3 -c db -t 5

# Monitor container lifecycle events
docker events --filter type=container

# Filter for specific events
docker events --filter event=oom --filter event=die --filter event=restart

# Time-based filter
docker events --since "2024-01-15T03:00:00" --until "2024-01-15T04:00:00"

# Get container's main PID
PID=$(docker inspect --format='{{.State.Pid}}' myapp)

# Enter the container's network namespace for debugging
nsenter -t $PID -n tcpdump -i eth0 -c 100 port 8080

# Enter the container's process namespace
nsenter -t $PID -p -m strace -p 1

# ============================================
# Complete walkthrough: OOM diagnosis and fix
# Covers: stats, events, logs, inspect, fix
# ============================================

# 1. Deploy the problematic container
docker run -d \
  --name leaky-app \
  --memory=100m \
  --restart=on-failure:5 \
  -p 8080:8080 \
  myapp:1.0

# 2. Monitor resource usage
docker stats leaky-app --no-stream

# 3. Simulate memory leak (trigger OOM)
docker exec leaky-app python -c "
import itertools
data = []
for i in itertools.count():
    data.append('x' * 1024 * 1024)  # 1 MB each
    if i % 10 == 0:
        import time; time.sleep(0.1)
"

# 4. Capture OOM event
docker events --filter container=leaky-app --filter event=oom --since 1m

# 5. Check exit code and OOM status
docker inspect leaky-app --format='
ExitCode: {{.State.ExitCode}}
OOMKilled: {{.State.OOMKilled}}
Memory Limit: {{.HostConfig.Memory}}
'

# 6. Check application logs for memory patterns
docker logs --tail 100 leaky-app 2>&1 | grep -i "memory\|alloc\|oom"

# 7. Fix: increase memory limit
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. Set up monitoring alert
docker events --filter event=oom | while read event; do
  echo "ALERT: OOM detected at $(date)" >> /var/log/docker-alerts.log
done