Incident Overview
A mid-sized application platform runs a fleet of Linux virtual machines behind a load balancer. On the fictional host app-node-07, an on-call systems administrator receives an automated alert: the one-minute load average has climbed from a typical value of around 2 to over 18 on a host with 4 CPU cores.
The alert threshold is tuned for load average relative to core count, so this trips a paging alert. The administrator opens a shell session to begin triage.The first instinct is to assume the CPU is saturated and that a runaway process is consuming cycles.
However, the administrator notices that response times for the application on this host have only degraded slightly, not catastrophically, which does not match the usual pattern seen during genuine CPU-bound incidents on this platform.
Investigation Options
Review the available operational moves and select the best immediate action.
Immediately provision additional CPU cores for the host to relieve perceived CPU pressure
Run iostat and ps to confirm whether elevated load average is driven by I/O wait rather than CPU contention before changing capacity
Kill all processes in D state to force the load average back down
Restart the host to clear the load average spike and monitor whether it recurs