TL;DR: On Linux, load average counts processes that are runnable and processes in uninterruptible sleep (state D), which are almost always blocked on I/O. A load of 30 with low CPU suggests blocked tasks or runnable work constrained by CPU affinity/quota; the average is not a current count of I/O waiters. Confirm with the process states before touching anything.
How to approach it
Correct the premise in one sentence: load is not CPU. Then show how to prove it, and name the specific causes. This is a Linux-internals question wearing a performance costume.
A strong answer
Load average on Linux is the exponentially-weighted count of tasks in state R (running or runnable) plus state D (uninterruptible sleep). That D inclusion is a Linux-specific choice; most other Unixes count only runnable tasks. So Linux load average is a measure of demand for resources generally, and I/O is a resource.
Compare the averaging windows and inspect task states. Blocked kernel work is one explanation; a cpuset, CPU quota or uneven affinity can also leave runnable work waiting while other host cores are idle. Prove it:
ps -eo state,pid,comm | awk '$1 ~ /D/' # count tasks in D
vmstat 1 5 # the b column is blocked tasks
iostat -x 1 5 # %util and await per device
Correlate await, queue depth and throughput with the workload. Near-100% util means the device had I/O in flight, not necessarily that a parallel NVMe device reached capacity. High await with low IOPS points at a slow device or a saturated network volume rather than raw volume of requests.
The usual causes, in the order I would check them.
Storage. A network-attached volume that has exhausted its IOPS or throughput allowance is the most common cause in cloud environments, and it is invisible from CPU metrics. Cloud volumes have burst credits; when they run out, latency multiplies and every process touching the disk enters D. The graph shape is characteristic: fine for hours, then a cliff.
NFS or a network filesystem. A hung mount can block tasks in kernel waits. Truly uninterruptible waits delay SIGKILL until the wait ends, but some NFS waits are killable; state D alone does not prove permanent unkillability.
Memory pressure causing swap. Reclaim and swap-in are disk operations, so memory pressure presents as I/O wait. Check si/so in vmstat before concluding it is a disk problem.
Too many threads doing small synchronous writes, where the fix is batching or fsync policy rather than hardware.
The senior framing: load average is a poor alerting signal precisely because it conflates two different resources, and its 1, 5 and 15 minute windows are all lagging. Alert on the thing users feel (latency), and use load as a diagnostic once you are already looking.
What interviewers probe next
"How would you kill a process stuck in D?" A fatal signal can terminate a killable wait. For a truly uninterruptible wait, restore the dependency so the kernel can complete it; a controlled reboot is a last resort.
"Is a load of 30 on 32 cores bad?" If they were all runnable, it is roughly full utilisation and fine. The number is meaningless without knowing the state mix and the core count.
"What is PSI?" Pressure Stall Information in /proc/pressure, which reports time lost to CPU, memory and I/O contention separately. It is the metric load average should have been, and it is available in modern kernels and surfaced by Kubernetes.
Common mistakes
Saying load average is CPU utilisation. It is the whole misconception the question exists to find.
Adding cores or replicas. If the bottleneck is a saturated volume, more consumers make it worse.
Not checking swap, which turns a memory problem into a misdiagnosed disk problem.
References