The WHM Statistics tab under CloudLinux LVE Manager is the single most useful page on the server when something is wrong and you don't yet know who to blame. It maps every limit hit — physical memory, virtual memory, entry processes, process count, IO — to a user and a time window, and the CLI equivalents narrow that further to the script.
The hard part is reading it. The column names are abbreviated, the units are inconsistent across versions, and the "fault" concept is subtler than "your limit was breached". This guide is what the columns mean, the CLI to drill in further, and the mitigation that buys you time before the customer ticket lands.
Open the page
In WHM: CloudLinux LVE Manager → Statistics. The default view shows the last 24 hours, aggregated per user, sorted by total faults descending.
If you've never tuned defaults, do that first — CloudLinux LVE tuning covers sensible per-account starting limits before you investigate spikes against them.
What each fault column means
A fault is one event where a user hit a limit and the kernel intervened. Not every fault is bad — bursting briefly into a limit and being throttled is the system working as designed. The signal is the rate of faults and which column they accumulate in.
| Column | Name | What triggered it | Customer impact |
|---|---|---|---|
| CPU | CPU usage % | Sustained CPU above the LVE CPU cap | Slow response, requests queue |
| EP | Entry processes peak | Concurrent dynamic requests (php-fpm, cgi) | New requests get 508s |
| EPf | Entry process fault | A request was refused because EP cap was hit | Visible 508 to the visitor |
| PMem | Physical memory peak (MB) | Resident memory the user's processes hold | None on its own |
| PMemF | Physical memory fault | OOM kill inside the user's LVE | Process killed, request 500s |
| VMem | Virtual memory peak (MB) | Address space committed | None on its own |
| VMemF | Virtual memory fault | malloc refused; usually a runaway script | Hard 500 |
| NProc | Process count peak | Total processes in the LVE | None on its own |
| NProcF | Process count fault | fork() refused | New PHP workers fail to spawn |
| IO | Disk IO peak (KB/s) | Bytes/sec read+write | Slow IO for that user |
| IOPS | IO ops/sec | Filesystem operations | Slow IO for that user |
The "F" suffix is the actionable one. A high EP peak with zero EPf means the user got close to the wall but you never hit it — leave it alone. A non-zero PMemF is an OOM kill that produced a 500 response to a real visitor — investigate.
Drill in from the CLI
The WHM page aggregates to the user. To find the script and the minute, drop to the CLI:
lveinfo --period=1d --user=username --by-fault
This lists the user's faults in the last day grouped by column. Add --by=PMemF (or the column of interest) to filter to one type. For a live view during an active incident:
lvetop
lvetop is top for LVEs — refreshes every second, shows current CPU/EP/PMem against caps in colour, highlights users currently faulting. Press u to filter to one user, s to change the sort column.
For a more detailed live view that includes the offending processes per LVE:
cloudlinux-top
cloudlinux-top adds the top processes inside each LVE, so you can see whether the load is from php-fpm: user-pool, a mysqld (which lives outside the LVE but is shown for context), or a cron job. This is usually enough to identify the script.
Map fault times to the offending script
Cross-reference the fault timestamps from lveinfo with two sources:
grep "lve.*username" /var/log/messages | grep -i fault
lveps -p
/var/log/messages contains kernel-emitted LVE fault lines with the PID. lveps -p shows the running processes per LVE with their PIDs and command lines — pipe it through grep username to scope. Match the PID from /var/log/messages against the command from lveps -p and you have the offending script.
For PHP-FPM users, the script is in the FPM access log:
tail -200 /var/log/php-fpm/username.access.log | awk '$NF > 1000'
That prints requests that took more than 1 second. The script path is in the last column. Combined with the fault timestamps, it's usually a single endpoint — a misconfigured WP-Cron, an unindexed search query, a runaway export script.
Mitigate in the moment
You usually need to stop the bleeding before you write to the customer. Temporarily raise the limit that's faulting, then notify:
lvectl set username --pmem=2G --vmem=4G
lvectl set is in-memory only — it survives until the next lvectl apply all. For a persistent change, edit the user's row in WHM LVE Manager or:
lvectl set username --pmem=2G --save
The --save flag writes to /etc/container/ve.cfg. Raise limits as a stopgap; the real fix is the customer's code or a paid upgrade to a tier with higher defaults. If the user is consistently above their plan's limits, send the upsell — that's what the data is for.
For database-side spikes that don't show in LVE columns but break the same way, check MySQL Governor — see MySQL Governor modes for the equivalent investigation path on the database side.
When the offender isn't a user
Some faults look like an LVE problem but trace to a system-wide event: a cron job in /etc/cron.d/ running as root and dragging IO, a dnf-automatic transaction holding RAM, or a backup agent walking every home. lvetop will show several users faulting simultaneously with no one user dominating — that's the tell. Check top and iotop -aoP for non-LVE processes before blaming a tenant.
What does PMemF mean in CloudLinux LVE Statistics?+
What is the difference between EP and EPf in LVE Manager?+
How do I find which PHP script is causing LVE faults?+
Can I temporarily raise an LVE limit without a restart?+
Why does lvetop show several users faulting at once?+
Next steps
- Set sensible defaults so you investigate less with CloudLinux LVE tuning.
- Investigate database-side spikes with MySQL Governor modes.
- Buy or renew at CloudLinux licence.