Monitoring on a database server shows CPU at about 15 percent, ample free memory, and most query wait time attributed to reading and writing data files. Disk queue length is high and average read latency has climbed sharply during business hours. What is the bottleneck?

IOPS, input/output operations per second, measures how many read and write operations storage can complete, and latency measures how long each one takes. When query waits are dominated by data file I/O, disk queues grow and read latency rises under load while CPU is low and memory is plentiful, the storage subsystem has become the limiting resource. Remedies include faster storage tiers, spreading data and log files across more devices, provisioning more IOPS on cloud volumes, and reducing I/O demand through indexing and query tuning. Insufficient CPU would show high processor utilization and runnable queues; at 15 percent the processors are mostly idle while queries wait elsewhere. Lock contention produces lock waits and blocking chains in the engine's wait statistics; the scenario attributes waits to file I/O rather than to locks, so blocking is not the primary issue. Too little memory for the database would typically appear as falling cache efficiency and increased paging, but here free memory is ample, so the reads are not caused by memory starvation. Exam caveat: storage problems sometimes have a memory root cause, so ruling out memory pressure first, as this scenario does, strengthens the conclusion. Operational check: compare measured IOPS and latency with the volume's provisioned limits, identify the files and queries generating the most I/O, and confirm improvement after changing storage or tuning the heaviest queries.