High Load cPanel Server: Find the Culprit Fast (5 Tools)

“Load is high” is a symptom, not a diagnosis. A load average of 30 on a 16-core server can be a runaway backup, one WordPress site under a bot storm, a single slow query holding table locks, or a disk that has started to fail. The tools to tell these apart ship with every cPanel install; what matters is the order you use them in. The sequence below moves from the whole machine to the one process, account or query that is causing it, and it takes a few minutes rather than an hour of guessing.

Short answer: Classify the load first with top, vmstat and sar as CPU-bound, I/O-bound, memory pressure or hypervisor steal, then use ps --sort=-pcpu and the D-state list to find the process and the account. For web workers, whm-server-status and the domlog show the vhost, URL and IPs being hammered; for mysqld, SHOW FULL PROCESSLIST and the slow query log name the query and the site that owns it.

Establish what kind of load it is

Load average counts runnable and uninterruptible processes. Start by finding out whether they are waiting for CPU, disk or memory:

uptime
top -bn1 | head -15
vmstat 1 5

In the top header, compare %us (user CPU), %sy (system), %wa (I/O wait) and %st (steal, on VMs). In vmstat, watch the r (runnable) and b (blocked) columns and si/so (swap in/out). A rough map:

• High %us, r large, b small: CPU-bound. Something is computing, probably PHP.
• High %wa, b large: I/O-bound. Backups, a scanner, a database doing full scans, or a failing disk.
• si/so non-zero and free memory near zero: memory pressure. Everything looks slow because the box is swapping.
• High %st: the hypervisor is overcommitted. Nothing on this server will fix it.

If the spike has already passed, sar has the history. sysstat is installed on cPanel and collects every ten minutes:

sar -q | tail -20
sar -u -f /var/log/sa/sa$(date -d yesterday +%d) | tail -20
sar -d -p | sort -k10 -n | tail

sar -q shows load over the day, sar -u shows the CPU split at that time, and sar -d identifies the busiest block device.

Find the process and the account

With the type of load known, find who is responsible. Sort by CPU or by state:

ps -eo pid,user,pcpu,pmem,stat,etime,cmd --sort=-pcpu | head -20
ps -eo pid,user,stat,cmd | awk '$3 ~ /^D/'

The second command lists processes in uninterruptible sleep, which is the I/O-bound set. On a shared server the user column immediately tells you the account. If PHP-FPM workers dominate, the pool name in the command line (php-fpm: pool example.com) names the site without any further digging. If it is mysqld, jump to the database section. If it is cpbackup, clamd, imunify, lfd or rsync, you have found a maintenance job running at the wrong time.

On CloudLinux, lveps -c or lvetop shows per-account CPU and I/O within their LVE limits, and an account pinned at 100% of its limit for long periods is the usual answer.

Look at what Apache is serving

For CPU or I/O load that traces to web workers, mod_status shows which vhosts and URLs are being hit right now. It is enabled on cPanel by default for localhost:

curl -s 'http://localhost/whm-server-status?auto' | head -20
curl -s 'http://localhost/whm-server-status' | grep -oE '[a-z0-9.-]+\.[a-z]+ +(GET|POST) [^ ]+' | sort | uniq -c | sort -rn | head

The second command counts in-flight requests by host and path. A hundred concurrent POST /wp-login.php or GET /xmlrpc.php requests on one domain is a brute-force run; block it with ModSecurity or CSF and the load drops within seconds. A hundred GET /?s=... search requests is a scraper. Correlate with the domlog:

tail -5000 /etc/apache2/logs/domlogs/example.com | awk '{print $1}' | sort | uniq -c | sort -rn | head

The top IPs by request count, along with their user agents, tell you whether to block a range or tell the customer their plugin is misbehaving. On LiteSpeed, the real-time report in the WebAdmin console gives the same view.

Check the database

MariaDB is the usual cause of high %wa and of PHP workers piling up in D state waiting for query results. Two commands give the immediate picture:

mysql -e "SHOW FULL PROCESSLIST" | awk -F'\t' '$6 > 5' 
mysql -e "SHOW ENGINE INNODB STATUS\G" | grep -A20 'LATEST DETECTED DEADLOCK\|TRANSACTIONS'

Queries in Sending data, Copying to tmp table or Waiting for table metadata lock for more than a few seconds, from one database, are the culprit. Then enable the slow log if it is not already on so you can see the pattern rather than a snapshot:

mysql -e "SET GLOBAL slow_query_log=1; SET GLOBAL long_query_time=2; SET GLOBAL slow_query_log_file='/var/lib/mysql/slow.log';"

Leave it running for an hour and summarise with mariadb-dumpslow -s t /var/lib/mysql/slow.log | head -40. The query at the top usually belongs to one plugin on one site. A common pitfall is chasing PHP tuning when a single unindexed wp_options autoload or a wp_postmeta join with millions of rows is the actual problem. Our MySQL health snapshot script automates this collection.

Rule out mail and the scheduled jobs

Two sources are easy to overlook. An outbound spam run makes Exim consume CPU and I/O across many processes; check exim -bpc for the queue length and see finding the source of outgoing spam if it is in the thousands. And overlapping cron jobs (backups at 01:00, malware scans at 01:00, cpanellogd at 01:00) turn a quiet hour into a daily incident; stagger them in WHM » Backup Configuration, the scanner’s schedule, and /etc/cron.d.

Verify and keep it running

Once you have acted (blocked the IPs, suspended the site, killed the query, moved the cron), confirm the load is falling with uptime every minute and that vmstat shows the blocked count back near zero. Then check sar -q the next day to confirm the spike did not recur at the same time. Record what you found: the account, the cause and the fix. Most high-load incidents on a given server repeat, and the second time should take two minutes. If you want an engineer watching for these patterns and acting on them before the pager goes, that is what our managed services are for.

High load cPanel server at a glance

Official documentation: MySQL reference manual, cPanel & WHM documentation, AlmaLinux wiki.

Related guides: Choosing a VPS for a cPanel or DirectAdmin server in 2026 · CVE-2026-65638, 65639 and 67402 explained: patching the CSF Messenger and URLGET remote-code flaws · Warm up a new mail server IP or sending domain without landing in spam.

Frequently asked questions