Load average- Spiking up in WHM

Hatrix Hoster

• August 31, 2025 17:02

Load average- Spiking up in WHM 

I see that my freshly installed with with around 300 users is spiking up.
When I checked under the Process manager within the whm , I found no any particular process or cpanel account utilizing very high cpu usage continuously.

 I have cloudlinux, litespeed server with immunify360. and immunifr360 proactive defence is on. Is it the real issue?
then how can I confirm that how can I see it.

I doubt it is due to some attack or anything else because sometime it went upto 10-11 also

while normally it is in the range of 3-5. 

• 

  Rubfy

  • August 31, 2025 17:07

  Short answer: “Load average” can spike even when no single process shows high CPU in WHM. With CloudLinux + LiteSpeed, spikes often come from:

  short-lived lsphp workers (hard to catch in Process Manager),

  LVE throttling (SPEED/IO/EP faults queue work), or

  IO wait (disk/backup, malware scans, MySQL).

  Here’s how to confirm which one it is.

  1) Baseline
  nproc          # how many CPU cores
  uptime         # compare load to core count
  top -d1        # check %us/%sy/%wa/%st – high %wa => IO wait

  2) Catch short-lived PHP (LiteSpeed lsphp)
  ps -eLo pid,user,pcpu,pmem,comm --sort=-pcpu | head
  # or, if available:
  pidstat -dl 1 5     # best to see bursts over a few seconds (from sysstat)

  3) CloudLinux LVE — see if accounts are throttling

  WHM » CloudLinux LVE Manager » Current/Historical Usage → look for SPEED/IO/EP faults during spikes.
  CLI:

  lveinfo --period 1h --display-username --by-fault
  lveinfo --period 1h --sort=avgcpu --limit=20 --display-username

  
  If you see many SPEED or EP faults, raise limits a bit for noisy tenants or optimize their apps.

  4) IO wait vs database
  iostat -xm 1 5     # high await/%util => disk bottleneck
  mysqladmin pr -i1 -r 5    # see long queries if MySQL is the culprit

  5) LiteSpeed real-time

  Check Real-Time Stats (requests, concurrency, top URLs) to spot floods or a single hot endpoint.

  6) Imunify360 sanity check

  Proactive Defense rarely “creates” load, but you can test for 10 minutes:

  Switch to Log Only, note the load, then switch back.

  Tail logs to see activity:

  tail -f /var/log/imunify360/defence.log

  7) Quick HTTP/attack triage
  netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head
  # check for a few IPs creating hundreds of connections

  
  What to do next

  If LVE faults: raise limits for affected users (CPU/IO/EP) or tune their caches.

  If IO wait: check backups/antivirus schedules, enable/verify LSCache/OPcache, consider faster storage.

  If specific endpoint flood: rate-limit or block at LiteSpeed/WAF; cache where possible.

  If you share: (a) top line with %wa, (b) lveinfo --by-fault output for the spike window, and (c) iostat -xm 1 5, dá pra apontar exatamente a causa.

  0

Please sign in to leave a comment.