2.3.2.3 Cgroup Block IO Limits
A focused guide to Cgroup Block IO Limits, connecting core concepts with practical Docker and container operations.
Cgroup block IO limits constrain how much disk read and write throughput, or how many disk operations per second, a container's processes are permitted to consume, preventing a single container's heavy disk activity from degrading disk performance for every other workload sharing the same underlying storage.
Why Disk IO Limits Matter
Unlike CPU and memory, disk IO is a resource that, when contended, can cause severe, hard-to-diagnose slowdowns across an entire host, since a single container performing intensive disk reads or writes can saturate the available disk throughput that every other container also depends on.
docker run -d --device-read-bps /dev/sda:50mb myapp:disk-intensive
This limits the container's read throughput from the specified device to 50 megabytes per second, regardless of how much disk activity the application inside attempts to perform.
Limiting Read and Write Throughput Separately
Read and write throughput can be limited independently, which is useful when a workload's read and write patterns have very different performance implications for the underlying storage.
docker run -d --device-read-bps /dev/sda:50mb --device-write-bps /dev/sda:20mb myapp:1.0
Limiting IO Operations Per Second
In addition to throughput limits, the number of individual read or write operations per second can be capped, which matters particularly for workloads that perform many small operations rather than a smaller number of large ones.
docker run -d --device-read-iops /dev/sda:1000 myapp:1.0
Relative IO Weighting
Similar to CPU shares, a relative IO weight can be set to determine priority access to disk bandwidth when multiple containers are competing for it, without imposing an absolute cap.
docker run -d --blkio-weight=500 myapp:1.0
Why Block IO Limits Matter
Disk IO limits are especially important on hosts running a mix of latency-sensitive workloads (such as a database) alongside batch or background workloads with heavy disk usage, since without these limits, the batch workload's disk activity could noticeably degrade the latency-sensitive workload's performance.