Docker Performance Tuning: CPU, Memory, and I/O Optimisation

Docker containers add some overhead compared to running processes directly on the host, but the majority of performance problems in production Docker deployments come from misconfiguration, not from inherent container overhead. Unset memory limits causing swap pressure, no CPU pinning causing scheduling jitter, the wrong storage driver, and excessive container image layers all reduce performance significantly. Most of this is tunable without changing the application.

Where Docker Performance Overhead Actually Comes From

Docker containers share the host kernel and have minimal inherent overhead compared to virtual machines. The actual performance costs are:

Storage driver overhead — overlay2 (the default on modern Linux) adds minimal overhead for reads and a copy-on-write cost for first writes to files that exist in the image. Applications that do heavy writes to the container’s writable layer (rather than volumes) pay this cost. Solution: use volumes for write-heavy paths.

Network overhead — bridge networking adds a small overhead for inter-container traffic due to the iptables processing and virtual bridge traversal. For performance-critical inter-container communication, host networking eliminates this overhead entirely.

Memory pressure from missing limits — a container without a memory limit can consume all available host memory, triggering kernel OOM kills or swap usage. Both are catastrophic for performance. Setting appropriate memory limits allows the kernel to manage memory allocation predictably.

CPU scheduling noise — a container without CPU limits on a shared host can consume all available CPU, starving other containers and host processes. On dedicated hosts this matters less, but on shared infrastructure it is critical.

Logging driver overhead — the json-file logging driver buffers writes to disk. High-throughput log output from a container writes to the docker log file, which competes with application I/O. Use appropriate log buffer sizes and rotation settings.

Performance-Tuned Container Runtime Flags

# CPU tuning: limit to 2 cores, pin to specific CPUs
docker run -d \
  --cpus="2.0" \
  --cpuset-cpus="0,1" \
  --cpu-shares=1024 \
  myapp:latest

# Memory tuning: limit memory, disable swap, set swappiness
docker run -d \
  --memory="2g" \
  --memory-swap="2g" \
  --memory-swappiness=0 \
  myapp:latest

# I/O tuning: limit block device bandwidth
docker run -d \
  --device-read-bps /dev/sda:100mb \
  --device-write-bps /dev/sda:100mb \
  myapp:latest

# Network performance: use host networking (removes bridge overhead)
docker run -d --network host myapp:latest
# Only when bridge overhead is measurable and inter-container
# DNS resolution is not needed

# Logging: configure json-file with rotation and buffering
docker run -d \
  --log-driver json-file \
  --log-opt max-size=50m \
  --log-opt max-file=5 \
  --log-opt compress=true \
  myapp:latest

# Monitor container resource usage
docker stats --format 'table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.MemPerc}}\t{{.BlockIO}}\t{{.NetIO}}'

# Show disk usage by container, image, and volume
docker system df -v

Setting ‘–memory-swap’ equal to ‘–memory’ disables swap for the container entirely. With swap disabled, the container is OOM-killed when it exceeds its memory limit rather than using swap. This is usually preferable for production containers: swap is much slower than RAM and OOM-kill produces a clear error signal, while swap usage produces slow, hard-to-diagnose performance degradation.

Performance Tuning Parameters

Flag / Parameter	Description	Security Note
`--cpus`	Limits the container to a fraction of available CPUs. '–cpus=2.0' allows the container to use at most 2 CPU cores worth of processing time, distributed across any available core. This prevents a single runaway container from consuming all host CPU. For compute-bound workloads, set this to the expected steady-state CPU use plus a headroom buffer — not the peak burst capacity.	CPU limits prevent denial-of-service from runaway containers or buggy application code that spins in a CPU loop. Without limits on a multi-container host, a single container can make all other containers unresponsive.
`--cpuset-cpus`	Pins the container to specific CPU cores. '–cpuset-cpus=0,1' restricts the container to CPU cores 0 and 1 only. This eliminates the scheduling jitter from the container moving between cores (L1/L2 cache misses) and allows NUMA-aware placement on multi-socket servers. Beneficial for latency-sensitive workloads where consistent response time matters more than throughput.	CPU pinning can backfire if the pinned cores are overcommitted. If multiple containers are pinned to the same set of cores, they contend for those cores even if other cores are idle. Use cpuset-cpus for dedicated workloads where you can guarantee exclusive use of the pinned cores.
`--memory and --memory-swap`	Sets the container's memory limit and the combined memory+swap limit. Setting both to the same value disables swap. Without a memory limit, containers can consume all host memory, triggering OOM conditions across the entire host. Start with a limit based on observed steady-state memory use plus 25% headroom. Monitor with 'docker stats' and adjust based on real usage.	An OOM-killed container leaves a clear signal in 'docker inspect <name> –format={{.State.OOMKilled}}'. Regularly check OOMKilled status for all production containers — unexpected OOM kills indicate memory pressure that needs investigation.
`Storage driver (overlay2)`	The overlay2 storage driver is the production default on Linux. It provides good performance for read-heavy workloads. Write-heavy paths (application logs, temp files, uploads) should use volumes or bind mounts rather than the container's writable layer, because every write to the writable layer goes through the overlay copy-on-write mechanism. Volume writes go directly to the host filesystem with no copy-on-write overhead.	The container's writable layer is deleted when the container is removed. Any writes to the writable layer that should persist must use volumes. Losing data because it was written to the container layer instead of a volume is one of the most common Docker data loss patterns.

Performance Profiling Workflows

Identifying Resource Bottlenecks with docker stats

docker stats provides a live view of CPU, memory, I/O, and network usage for all running containers. Use it as the first diagnostic step when a container is slow or a host is under pressure.

# Live stats for all containers
docker stats

# One-shot (no streaming) stats for scripting
docker stats --no-stream --format \
  'table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}/{{.MemLimit}}\t{{.BlockIO}}\t{{.NetIO}}'

# Find the highest-memory container
docker stats --no-stream --format '{{.Name}} {{.MemPerc}}' | \
  sort -k2 -rn | head -5

# Find the highest-CPU container
docker stats --no-stream --format '{{.Name}} {{.CPUPerc}}' | \
  sort -k2 -rn | head -5

# Check if a container has been OOM-killed
docker inspect myapp --format='OOM killed: {{.State.OOMKilled}}'

Reducing Disk Usage and Reclaiming Space

Docker accumulates unused images, stopped containers, dangling volumes, and unused build cache over time. Regular cleanup is necessary to prevent disk full conditions.

# Show disk usage by category
docker system df

# Safe cleanup: remove stopped containers, dangling images,
# unused networks, and build cache
docker system prune

# Aggressive cleanup: also removes unused images
# (images not referenced by any container)
docker system prune -a

# Remove only dangling images (untagged intermediate layers)
docker image prune

# Remove all unused volumes (not mounted by any container)
# WARNING: verify before running
docker volume prune

# Schedule weekly cleanup with cron
# 0 2 * * 0 /usr/bin/docker system prune -f >> /var/log/docker-prune.log 2>&1

Performance Limits as a Security Control

Resource limits in Docker serve a dual purpose: performance isolation and security hardening. An attacker who achieves code execution inside a container is constrained by the container’s resource limits. Without limits, a compromised container can mount a denial-of-service attack against the host by consuming all CPU, memory, or disk I/O — taking down co-located services in the process.

Setting memory and CPU limits on every container converts an unlimited attack surface into a bounded one. The attacker can saturate their own container’s resources but cannot starve the host or neighbouring containers beyond the limits assigned. Additional considerations apply when running Docker in production: monitoring container health metrics, setting up centralised log aggregation, implementing image signing and verification workflows, and auditing container runtime configuration against CIS Docker benchmarks. Each of these layers adds defence in depth beyond the controls described above. Review the full security posture regularly as Docker releases update default security settings and new CVEs are discovered in container runtime components.

Never run production containers without memory limits. Without a memory limit, a memory leak or a traffic spike can cause the entire host's OOM killer to start killing processes — including unrelated critical services.
The 'docker stats' MemUsage shows RSS (resident set size), not virtual memory. A container showing 1.5G/2G in docker stats is close to its limit but has 500M of headroom. When MemUsage reaches the limit, the container is OOM-killed — set limits with enough headroom for peak load.
Containers with '–network host' share the host's network stack. Any port the container binds to is bound on the host directly, bypassing Docker's iptables rules. Use host networking only when the bridge overhead is measurable and the security implications are understood and acceptable.
Aggressive use of 'docker system prune -a' can remove images still needed for rollback. Always maintain a registry with the previous image version before pruning local images on a production server.

Practical Examples

Container Resource Audit Script

#!/bin/bash
# Audit all containers for missing resource limits
echo "=== Container Resource Limit Audit ==="
echo "Containers WITHOUT memory limits:"
docker ps -q | xargs docker inspect \
  --format='{{.Name}}: memory={{.HostConfig.Memory}} swap={{.HostConfig.MemorySwap}}' | \
  grep 'memory=0'

echo ""
echo "Containers WITHOUT CPU limits:"
docker ps -q | xargs docker inspect \
  --format='{{.Name}}: cpus={{.HostConfig.NanoCpus}} cpuset={{.HostConfig.CpusetCpus}}' | \
  grep 'cpus=0'

echo ""
echo "Containers with OOM kill history:"
docker ps -aq | xargs docker inspect \
  --format='{{.Name}}: oom={{.State.OOMKilled}} restarts={{.RestartCount}}' | \
  grep 'oom=true'

Run this audit script after every new container is deployed to ensure all production containers have appropriate resource limits. Containers with memory=0 have no memory limit and can consume all host memory. Containers with OOMKilled=true have already been killed for memory overuse and need their memory limit increased.

Quick Reference: Key Commands and Options

# Inspect current configuration
docker inspect <container> --format='{{json .HostConfig}}' | python3 -m json.tool

# View container resource usage
docker stats <container> --no-stream

# Check container logs
docker logs <container> --tail 50 --timestamps

# Verify running processes inside container
docker exec <container> ps aux

# Check container environment variables
docker exec <container> env | sort

These diagnostic commands work across all container scenarios: ‘docker inspect’ shows the full HostConfig including all runtime parameters, ‘docker stats’ shows real-time resource consumption, and ‘docker logs’ shows output from the main process. Use these as the starting point for any container investigation before diving into more specific tooling.

Common Docker Performance Issues

Problem: Container is slow and docker stats shows high memory usage near the limit

Solution: The container is approaching its memory limit and the kernel may be actively evicting memory pages, causing performance degradation before an OOM kill. Increase the memory limit: ‘docker update –memory= ‘. Then investigate what is consuming memory: run ‘docker exec cat /proc/meminfo’ and look at the application’s memory profiling output to identify leaks or unexpected allocations.

Problem: I/O performance is poor for write-heavy operations

Solution: The application is writing to the container’s writable layer (the overlay filesystem) instead of a volume. Every write to the overlay layer pays a copy-on-write cost. Mount a named volume or bind mount for the write-heavy path: ‘-v myapp-data:/app/data’. Check which paths have heavy writes with ‘docker exec iostat -xz 2′ or by comparing I/O in ‘docker stats’ BlockIO column.

Problem: Host is slow when many containers are running but each shows low individual resource use

Solution: The aggregate resource usage across all containers exceeds host capacity. Sum the memory limits: ‘docker ps -q | xargs docker inspect –format={{.HostConfig.Memory}} | awk {sum+=$1}END{print sum/1024/1024/1024″ GB total committed”}’. Also check for network I/O contention with ‘docker stats’ NetIO column and for disk I/O contention with the BlockIO column.

Set Limits, Use Volumes for Writes, and Profile with docker stats

Docker’s performance overhead is minimal when containers are configured correctly. The three highest-impact tuning actions are: setting memory limits on every container to prevent host OOM pressure, using volumes for write-heavy application paths to avoid overlay copy-on-write overhead, and using ‘docker stats’ to identify which containers are consuming disproportionate resources before they cause problems. These three changes address the majority of Docker performance issues seen in production.

Set ‘–memory’ and ‘–memory-swap’ to the same value on all production containers. This disables swap and produces a clean OOM kill rather than slow, undetected swap degradation when a container exceeds its limit.
Write-heavy application paths must use volumes, not the container’s writable layer. The overlay2 copy-on-write mechanism adds latency to every first write to a file that exists in the image.
Use ‘docker stats –no-stream’ in monitoring scripts to detect resource anomalies early. A container consistently above 80% memory use is at risk of OOM kill under any load spike.

Docker Containers Slow or Consuming Too Many Resources?

INTRAM tunes Docker container resource limits, storage configuration, and runtime flags for production Linux servers.

Get Docker Performance Help