Disk I/O (disk input/output) is the reading and writing of data between a server and its storage devices, such as SSDs, hard drives or network-attached volumes. Among server resources, it is usually described with three measurements: IOPS (operations per second), throughput (megabytes per second) and latency (time per operation).
On servers, disk I/O is frequently the slowest and most contended resource, because storage access is orders of magnitude slower than memory access. When storage cannot keep up, processes wait, I/O wait rises, the load average climbs and response times grow, even if the CPU itself is mostly idle.
How disk I/O moves through the server
An application rarely talks to the disk directly. A read or write request passes through the operating system page cache, the file system, the block layer with its I/O scheduler, the device driver and finally the storage controller or the device itself.
Most writes are buffered in memory first and flushed later, which makes them appear fast until the cache fills or an application forces durability with fsync. Reads that hit the page cache never touch the disk at all, which is why free memory directly improves disk I/O on a busy server.
Modern NVMe devices expose many parallel hardware queues, while older SATA devices offer a single queue with a depth of 32 commands. The queue depth, meaning how many requests are outstanding at once, strongly influences how much performance a device can deliver.
Key disk I/O metrics and typical values
Disk I/O performance is described by several related metrics, and no single number is sufficient. A device can deliver high throughput for large sequential transfers while struggling with small random operations, which dominate database and web workloads.
| Metric | What it measures | Where it matters |
|---|---|---|
| IOPS | Read or write operations completed per second | Databases, mail servers, small files |
| Throughput | Data transferred per second, MB/s or GB/s | Backups, media, log streaming |
| Latency | Time to complete one operation, ms or µs | Interactive and transactional work |
| Queue depth | Requests waiting or in flight | Indicator of saturation and parallelism |
| Utilization | Share of time the device was busy | Reliable only for single-queue devices |
Typical values differ by several orders of magnitude between storage classes. The ranges below are approximate and depend on block size, queue depth, model and workload mix.
| Storage type | Random 4K IOPS | Typical latency |
|---|---|---|
| 7,200 rpm hard drive | About 75-150 | 5-15 ms |
| SATA SSD | Tens of thousands | About 0.1 ms |
| NVMe SSD | Hundreds of thousands or more | Tens of microseconds |
| Cloud block volume | Provisioned limit, often thousands | About 0.5-2 ms |
Cloud volumes add an important twist: their performance is often capped by the provider at a provisioned IOPS or throughput level, sometimes with burst credits that run out under sustained load.
Disk I/O compared with related server resources
Disk I/O is closely tied to other server resource metrics, and confusing them leads to wrong diagnoses. The table separates disk I/O from the neighboring concepts with which it is most often mixed up.
| Concept | What it describes | Relationship to disk I/O |
|---|---|---|
| Disk I/O | Activity and performance of storage access | The underlying workload |
| I/O wait | CPU time idle while waiting for I/O | Symptom of slow or saturated storage |
| Disk space | Capacity used and free | Unrelated to speed; full disks fail writes |
| Swap | Memory pages moved to disk | Heavy swapping creates disk I/O load |
| Load average | Runnable and uninterruptible tasks | On Linux, rises with blocked I/O |
A frequent mistake is to treat disk space and disk I/O as the same problem. A half-empty volume can still be completely saturated by random writes, while a nearly full volume may perform well until it runs out of space.
Measuring and diagnosing disk I/O
On Linux, iostat -x reports per-device read and write rates, average wait time and queue size, while iotop and pidstat -d show which processes generate the load. The vmstat column for I/O wait gives a quick system-wide signal.
The most reliable sign of saturation is rising latency together with a growing queue. The utilization percentage can be misleading on NVMe and RAID devices, because a device that serves many requests in parallel may show 100% busy while still having spare capacity.
| Symptom | Likely cause | Typical remedy |
|---|---|---|
| High await, long queue | Device saturated by random I/O | Faster storage, caching, query tuning |
| Throughput plateaus early | Provisioned cloud limit reached | Raise provisioned IOPS or throughput |
| Periodic latency spikes | Write-back flushes or backups | Spread jobs, tune dirty page limits |
| Constant reads despite free RAM | Working set exceeds cache | More memory or smaller working set |
Reducing disk I/O pressure in practice
The most effective optimization is usually avoiding disk access altogether. Caching layers, enough memory for the page cache and well-designed database indexes remove a large share of reads before they reach storage.
- Batch small writes into larger sequential ones, for example through write-ahead logs or buffered logging.
- Separate workloads such as database files, logs and backups onto different volumes.
- Schedule heavy jobs like backups and index rebuilds outside peak hours.
- Choose the right storage class for random workloads, since NVMe reduces latency dramatically compared with hard drives.
- Watch noisy neighbors on shared virtual hosts, where other tenants can consume the same storage backend.
In simple terms
Think of a server as a busy office and its storage as a filing room down the hall. Every time someone needs a document that is not already on their desk, they must walk to the filing room and back. Disk I/O is all that walking: the trips to fetch and store information.
If too many people need the filing room at once, a queue forms at the door and work stops while everyone waits. Faster storage shortens the walk, and keeping frequently used documents on the desk, which is what memory caching does, avoids the trip entirely.
A practical example
An online shop runs its database on a cloud virtual machine with a general-purpose volume limited to 3,000 IOPS. Every weekday morning, pages slow down sharply, although CPU usage stays around 30%. The administrator runs iostat -x and sees the volume pinned at its IOPS limit, with average wait times rising from about 1 ms to over 40 ms.
The cause is a nightly report that now finishes late and overlaps with morning traffic, reading large tables without suitable indexes. The team adds two indexes, moves the report to a read replica, and increases the server memory so that the hot part of the database fits in cache.
After the change, disk reads drop by roughly two thirds, wait times return to about 1 ms and the morning slowdown disappears without buying a faster volume.