Server
Disk I/O
Disk I/O is the reading and writing of data on storage, and it is far slower than touching memory. When a process has to wait on it, requests wait too.
How it is measured
Watch IOPS, throughput in MB/s, average queue depth, and per-operation latency from `iostat -x` or your cloud provider's volume metrics. High utilization with a growing queue and latencies above 10 ms on SSD is the warning.
Cloud volumes also have burst credits. A volume that ran fast for an hour can fall to its baseline figure with no change to your code, so check the credit balance when disk latency jumps.
Worked example
A small VPS hosts a WordPress multisite on a 100 GB volume with a baseline of 300 IOPS. A backup job starts at 02:00 and reads at 280 IOPS. Page requests that need an uncached template read wait behind it, and TTFB moves from 220 ms to 3.5 seconds.
Moving the backup to 04:00 and enabling object cache cut the read load. Disk latency fell from 40 ms to 3 ms and TTFB came back to 230 ms.
How it differs
Disk I/O is time spent talking to storage. Swap is a specific, painful case where the operating system uses disk as if it were RAM. Disk I/O excludes in-memory work and can be perfectly healthy. Swap excludes ordinary file reads, and its presence usually means memory is short.
Common errors
Reading CPU as the bottleneck when it is I/O wait. Ignoring cloud burst limits. Logging at debug level to the same volume as the database. Running backups and traffic peaks together. Measuring throughput while the real limit is IOPS or latency.
In practice
Check `iowait` and disk latency during your busiest hour and your backup window. Move logs and backups off the primary volume, add an object or page cache so repeat reads stay in memory, and set an alert for volume credit balance.