cPanel Server High Load: How to Find the Exact Cause

A cPanel server can report a high load for many different reasons. One website may be receiving a burst of traffic, a PHP script may be stuck in a loop, MySQL may be processing an expensive query, a backup may be compressing large files, or the server may be dealing with abusive requests.

The load number alone does not identify the cause. It is a signal that work is waiting for CPU time or, on Linux, that tasks may be waiting in an uninterruptible state such as disk I/O. Restarting Apache, PHP or MySQL can make the number fall temporarily, but it also removes evidence and can hide the real problem.

This guide presents a repeatable way to diagnose cPanel server high load. The goal is to move from a general alert to the responsible process, cPanel account, website and request pattern before making changes.

Run diagnostic commands as a privileged administrator only when you are authorized to inspect the server. Access logs, process lists and database activity can contain private information. Do not paste raw output into public tickets or forums.

Quick cPanel High Load Investigation

Start by recording a small snapshot instead of immediately restarting services:

date -u
uptime
nproc
vmstat 1 10
ps -eo pid,user,comm,%cpu,%mem,stat --sort=-%cpu | head -20
free -m
ss -s

These commands answer six useful questions:

1. When did the investigation begin?
2. How high are the 1, 5 and 15 minute load averages?
3. How many logical processors are available?
4. Is the server short of CPU time, memory or disk capacity?
5. Which processes are currently using the most resources?
6. Is there unusual connection pressure?

Save the output privately. It creates a baseline for comparing the server after any intervention.

What cPanel Server Load Actually Means

The three numbers shown by uptime are the average system load over approximately 1, 5 and 15 minutes. They are not CPU percentages.

On a server with one logical processor, a sustained load near 1 means roughly one task is using or waiting for the available processing slot. On a server with 16 logical processors, a load near 16 can mean all processing slots are busy. A brief value above 16 is not automatically a failure, but a sustained value far above the CPU count means work is accumulating faster than the server can complete it.

CPU count is only the starting point. Linux load also includes some tasks waiting in an uninterruptible state. A storage problem can therefore produce a high load while the CPU still appears partly idle. The Linux kernel documentation describes the underlying load calculation in more detail in its CPU load documentation.

Always read the load averages as a trend:

• A high 1 minute value with lower 5 and 15 minute values usually indicates a new spike.
• A low 1 minute value with higher 5 and 15 minute values usually indicates that the incident is clearing.
• All three values rising suggests a continuing problem.
• All three remaining high suggests a sustained or recurring bottleneck.

A Sanitized Real cPanel High Load Example

During one authorized investigation, a 16 CPU cPanel server reported this sanitized snapshot:

logical CPUs:       16
load average:       82.95, 47.60, 33.30
memory available:   38 GB of 64 GB
top PHP process:    about 90% of one CPU
MySQL process:      about 45% of one CPU
TCP connections:    752 total, 231 established
Apache workers:     119
PHP workers:        28

At first glance, a 1 minute load above 82 looked severe. Short vmstat samples taken during the investigation, however, showed between 59% and 79% CPU idle, only 0% to 1% I/O wait, and no active swapping. The system was not continuously exhausting all 16 processors at that exact moment.

The process list showed PHP as the largest active consumer. An anonymized account ranking found that two cPanel accounts were responsible for most of the sampled PHP CPU. MySQL showed only one active query and five sleeping connections at that time, so there was no evidence to justify restarting the database service.

Later, the 1 minute load fell sharply while the 5 and 15 minute values stayed elevated. That was consistent with a burst beginning to clear while the longer averages slowly decayed.

This example demonstrates why a single load number is not a diagnosis. The useful path was:

1. Compare load to CPU count.
2. Check current CPU, I/O and memory pressure.
3. Rank processes by resource use.
4. Map PHP workers to cPanel accounts.
5. Inspect the relevant website traffic privately.
6. Verify the trend after the burst.

It is also important to understand process percentages. A PHP process showing about 90% CPU on a 16 CPU server is using close to one logical processor, not 90% of the whole machine.

Step 1: Classify the Bottleneck With vmstat

Run vmstat with repeated samples:

vmstat 1 10

Ignore the first line when interpreting the immediate state because it can summarize activity since boot. Focus on the following samples.

One unusual sample is not enough. Look for a pattern across several seconds and compare it with the load trend.

Step 2: Find the Process Consuming the Resources

Rank the current processes by CPU:

ps -eo pid,user,ppid,comm,%cpu,%mem,stat,etime --sort=-%cpu | head -25

Then rank them by memory:

ps -eo pid,user,ppid,comm,%cpu,%mem,rss,stat,etime --sort=-%mem | head -25

Common findings on a cPanel server include:

• lsphp, php-fpm or php-cgi: PHP application activity
• mysqld: database queries, inefficient indexing or a traffic-driven workload
• httpd or nginx: web requests or connection pressure
• backup, tar, gzip or pigz: scheduled backup work
• clamd, malware scanners or security tools: an active or scheduled scan
• exim: a large mail queue, spam run or delivery activity
• Kernel workers with high I/O wait: possible disk or filesystem pressure

Take several samples a few seconds apart. A process appearing once may be normal. The same process or account repeatedly dominating the list is much more useful evidence.

If the spike has already ended, WHM's Daily Process Log can help. cPanel records per-user CPU and memory information at intervals, so the historical view may identify an account that is no longer busy when you log in.

Step 3: Map PHP Load to the cPanel Account

PHP is often the largest resource consumer on shared or multi-account cPanel servers. The next question is not simply whether PHP is busy. You need to know which account owns the workers.

ps -eo user,pid,ppid,comm,%cpu,%mem,stat --sort=-%cpu \
  | awk '$4 ~ /^(lsphp|php-fpm|php-cgi)$/ {print}' \
  | head -30

To group current PHP CPU by system user:

ps -eo user,comm,%cpu --no-headers \
  | awk '$2 ~ /^(lsphp|php-fpm|php-cgi)$/ {cpu[$1]+=$3; count[$1]++} END {for (u in cpu) printf "%-24s %8.1f%% %5d workers\n", u, cpu[u], count[u]}' \
  | sort -k2 -nr

The Linux user usually maps to a cPanel account. Once one account is consistently at the top, narrow the investigation to its domains, document roots, application logs and current requests.

Do not suspend an account or terminate all of its processes based on one sample. A legitimate traffic burst, cron job or administrative task can briefly make an account appear first.

Step 4: Find the Website and Request Pattern

cPanel normally stores per-domain Apache access logs under /etc/apache2/logs/domlogs. The exact layout is described in cPanel's official Apache paths documentation.

To rank active domain logs by requests recorded during the current minute:

minute=$(date '+%d/%b/%Y:%H:%M')
find /etc/apache2/logs/domlogs -maxdepth 1 -type f -print0 \
  | xargs -0 -I{} sh -c 'count=$(grep -c "'"$minute"'" "{}" 2>/dev/null); [ "$count" -gt 0 ] && printf "%8d %s\n" "$count" "{}"' \
  | sort -nr \
  | head -20

This output contains real domain names. Keep it private and replace them before sharing a report.

After identifying the relevant log, inspect the busiest source addresses:

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

Then inspect the most requested paths:

tail -n 5000 /etc/apache2/logs/domlogs/example.com \
  | awk -F'"' '{print $2}' \
  | awk '{print $2}' \
  | sort | uniq -c | sort -nr | head -30

Look for evidence such as:

• Repeated requests to one expensive PHP endpoint
• WordPress login, XML-RPC or search abuse
• A crawler requesting many uncached pages
• Large numbers of requests from a small source set
• Repeated 404 responses that still invoke the application
• A promotion or campaign creating legitimate demand
• Requests bypassing the expected cache

An IP address appearing frequently is not, by itself, proof of a DDoS attack. Reverse proxies, monitoring services, office networks and large providers can concentrate legitimate traffic. Combine request rate, path, status code, user agent, connection state and application behavior before deciding.

Step 5: Check Whether MySQL Is the Cause

If mysqld is consuming significant CPU or I/O, inspect active work before restarting it:

mysql -e "SHOW FULL PROCESSLIST\G"

The MySQL SHOW PROCESSLIST documentation explains the command fields. Pay attention to queries that remain active for a long time, locked states, table scans, temporary table operations and many similar concurrent queries.

Sleeping connections are not the same as actively expensive queries. They can reveal poor connection handling, but a small number of sleepers does not prove that MySQL caused the load.

Where Performance Schema is enabled, query digests can show which normalized statements consumed the most total time:

SELECT DIGEST_TEXT,
       COUNT_STAR,
       ROUND(SUM_TIMER_WAIT / 1000000000000, 2) AS total_seconds,
       ROUND(AVG_TIMER_WAIT / 1000000000000, 4) AS avg_seconds
FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 15;

MySQL process lists and query digests may expose database names or application data. Sanitize them before sharing. The official MySQL Performance Schema documentation covers collection and interpretation in more depth.

Step 6: Rule Out Disk, Memory and Filesystem Pressure

Check memory, swap, filesystem capacity and inode availability:

free -m
swapon --show
df -h
df -i

If iostat is installed, inspect device latency and utilization:

iostat -xz 1 5

Also review recent kernel storage or out-of-memory messages:

journalctl -k --since "30 minutes ago" --no-pager \
  | grep -Ei 'out of memory|oom|blocked for more than|I/O error|filesystem|nvme|ata'

Useful warning signs include:

• Active swap-in and swap-out over multiple samples
• Filesystems close to 100% usage
• Exhausted inodes even when disk space remains
• High I/O wait and device latency
• Tasks repeatedly blocked in uninterruptible sleep
• Recent out-of-memory kills

Linux normally uses available memory for cache, so a low free value alone is not proof of a memory shortage. Consider the available estimate, swap activity and process behavior together.

Step 7: Check Traffic and Connection Pressure

Start with a protocol summary:

ss -s

Then rank current remote peers connected to common web ports:

ss -Hnt state established '( sport = :80 or sport = :443 )' \
  | awk '{print $5}' \
  | sed 's/\[//; s/\]//; s/:[^:]*$//' \
  | sort | uniq -c | sort -nr | head -20

Connection counts should be compared with normal traffic for that server. A busy site can legitimately hold hundreds of connections, while a smaller site may struggle with far fewer expensive uncached requests.

For a suspected attack, preserve timestamps, firewall counters, web request samples and the resource trend. Blocking an address without understanding the pattern can be ineffective when sources rotate, and an overly broad rule can block legitimate visitors.

Step 8: Check Scheduled Work, Email and Security Events

High load is sometimes caused by normal work starting at the wrong time. Look for active backup and compression processes:

ps -eo pid,user,comm,%cpu,%mem,etime,args \
  | grep -E '[b]ackup|[t]ar|[g]zip|[p]igz|[r]sync'

Check whether the Exim queue has grown unexpectedly:

exim -bpc

Also review the timing of cPanel backups, account cron jobs, malware scans, package updates and log processing. Two individually reasonable jobs can create a serious bottleneck when they overlap.

Security events deserve special care. A compromised website may generate both incoming PHP load and outgoing mail activity. In that case, optimizing PHP limits alone does not solve the incident. The affected application must be investigated and secured.

Step 9: Choose the Smallest Safe Intervention

Make the response match the evidence:

Avoid making several unrelated changes at once. If the load falls, you need to know which action helped. One measured intervention followed by verification produces a much stronger diagnosis.

If the server hosts important production websites and the cause remains unclear, an experienced administrator can preserve evidence and reduce the risk of making the outage worse. iServerSupport provides cPanel server management for ongoing administration and emergency server support for urgent incidents.

Step 10: Verify That the Server Recovered

Repeat the original measurements after the intervention:

date -u
uptime
vmstat 1 10
ps -eo pid,user,comm,%cpu,%mem,stat --sort=-%cpu | head -20
free -m
ss -s

Confirm more than a lower load number:

1. The 1 minute load is falling and the longer averages follow over time.
2. The run queue and CPU idle values have returned to a normal range.
3. I/O wait and swap activity are not building.
4. The affected websites return expected responses.
5. Error rates are normal.
6. MySQL queries complete normally.
7. Mail and scheduled services are functioning.
8. The same account or endpoint is not immediately recreating the spike.

The final step is prevention. Add alerts for load, CPU, memory, disk latency, filesystem capacity and service failures. Retain enough metrics and logs to reconstruct future incidents. Our guides to reducing server CPU usage and monitoring a server for better performance provide further practical checks. For ongoing oversight, see proactive server management.

Common Questions About cPanel High Load

What load average is too high on a cPanel server?

There is no universal failure number. Compare sustained load with the logical CPU count, normal server baseline, response time, run queue, I/O wait and application health. A short burst above the CPU count can be harmless. A sustained queue accompanied by slow websites needs investigation.

Can one cPanel account cause high server load?

Yes. One account can create heavy PHP, database, email or backup activity. Rank PHP processes by user, use WHM's Daily Process Log for historical data, and inspect that account's private access and application logs before taking action.

Should I restart MySQL when the load is high?

Not without evidence. First check whether mysqld is actually consuming resources and inspect the active query list. A restart interrupts every database-backed website and may erase the most useful evidence while leaving the underlying query or traffic problem unchanged.

Why is the server load high when CPU usage is low?

The spike may have ended while the load averages are still decaying, or tasks may be waiting for storage or another uninterruptible operation. Repeated vmstat samples, process states and disk statistics help separate current CPU saturation from historical or I/O-related load.

How do I find which website is causing high CPU in cPanel?

First map busy PHP processes to their Linux user, which normally identifies the cPanel account. Then rank recent requests in that account's domain logs and compare request paths with application and database activity. Do not publish the raw output because it can contain domains, addresses and private query data.

Final Diagnostic Checklist

Use this order during the next cPanel high load alert:

1. Record the time, load averages and CPU count.
2. Use repeated vmstat samples to classify CPU, disk or memory pressure.
3. Rank processes by CPU and memory more than once.
4. Map PHP workers to cPanel accounts.
5. Identify the affected website and request pattern.
6. Inspect active MySQL work before considering a database action.
7. Check disk space, inodes, latency, swap and kernel messages.
8. Review connections, scheduled jobs, mail and security events.
9. Apply the smallest change supported by the evidence.
10. Repeat the baseline checks and confirm application recovery.

That sequence turns a vague cPanel server high load warning into a documented cause. It also creates a useful incident record, which makes the next alert faster to diagnose and easier to prevent.

Practical support, not another hosting package

Want an engineer to manage the server behind this problem?

iServerSupport provides monitoring, maintenance, security, and incident response for infrastructure you already control.

Explore server managementTalk to an engineer