Load average is not the same thing as CPU usage. It counts processes waiting to run plus those stuck in uninterruptible sleep, which is often disk I/O. A high load on a quiet CPU chart usually means something else is holding the queue, not that you simply need more cores.
A load of 8 on a 2-vCPU guest can be pure iowait from a backup or a slow disk. A load of 2 with plenty of idle CPU can still mean one busy thread is the real bottleneck. You need to see which of four things moved: user CPU, iowait, steal, or memory pressure. vmstat is the tool that splits those cleanly. Reading only the one-minute load in top and rebooting hides the evidence.
vmstat 1 10
df -h
df -i
free -hRun vmstat 1 10 and watch about ten seconds of samples. Start with the r and b columns, then read us, sy, wa, and st. High wa points at disk or a heavy backup job, not a missing CPU. High st is hypervisor steal from a noisy neighbor or a busy node. High us means PHP, MySQL, or similar work is actually computing. A growing blocked column is disk again, NFS, or a dump in progress.
If RAM has spilled into swap, you already lost headroom; adding more workers will not help. Use df -h and df -i as well. A full disk or exhausted inodes can show load 20 with idle CPU, and that pattern is easy to miss if you only stare at load average.
When extra cores help, and when they do not
The default answer is not to add cores. A WordPress site with load 12 and %wa near 80 usually needs a better index, a quieter backup window, or less lock contention. More vCPUs on a lock-heavy plugin just wait in parallel. Add cores when %us is honestly high, steal is low, RAM is fine, and the work is real compute you cannot cache away.
On shared hosting, CloudLinux LVE I/O caps can feel exactly like iowait. Check Resource Usage in cPanel Metrics first; moving to a VPS is a different conversation than fixing a plugin. Rebooting to “clear load” erases the journal and does not fix a full disk. The load drops because you killed the backup, the cron stampede, or the bad query, then it returns. Keep the numbers from before the reboot. Those four signals—load, iowait, RAM, and disk—tell you what actually moved.
If you already rebooted
The OOM killer leaves a signature in dmesg. Load was a symptom; memory may have been the cause. Paste fresh vmstat output, relevant dmesg lines, and note whether it was a backup window. A colorful htop screenshot is harder to compare than a short set of numbers we can read side by side.
If %wa is high, find the disk job. If %st is high on a VPS, open a ticket with the vmstat paste rather than a long plugin list. If %us is high, look at Query Monitor on staging, PHP workers, and locks. If you are in swap, reduce children, add RAM, or hunt a leak—still not a reboot as the plan.
High load means a queue. That queue might be disk, steal, memory, or real CPU work. Measure first, then choose a query fix or a plan change. Buying cores for iowait is how this page earned its name.
Tagged
Was this article helpful?
Be the first to rate this article.
