CloudLinux uses Lightweight Virtual Environment (LVE) containers to wrap each cPanel account in its own resource fence. CPU, memory, I/O, and process limits are enforced per user, so a single WordPress site running a bad plugin can't starve everyone else on the node. When you see high load averages but top shows no obvious offender, the real hog is probably hitting its LVE cap and the kernel is throttling it—hard.
In traditional shared hosting without CloudLinux, one account running an infinite loop or a poorly optimized query can consume every CPU cycle. LVE prevents that by assigning each account a slice of server resources. Once the slice is exhausted, the account is throttled or processes are killed, depending on which limit was breached. The trade-off: you need new tools to see what's actually happening inside those containers.
How LVE resource limits work
Every cPanel user on a CloudLinux server runs inside an LVE identified by the UID. The administrator sets limits for CPU (measured in percent × core count), physical memory (PMEM), virtual memory (VMEM), entry processes (EP), number of processes (NPROC), and I/O speed. A two-core server with a 100% CPU limit means the account can use one full core; 200% means two cores.
When an account exceeds a limit, CloudLinux records a fault. Faults are not errors in the traditional sense—they're counters that tell you how many times a resource ceiling was hit. A process hitting the CPU limit gets throttled to keep it under the cap. A process exceeding the PMEM limit may be killed outright or forced to swap, depending on configuration. NPROC and EP faults occur when the account tries to spawn more processes than allowed; new forks are rejected until existing ones exit.
I've seen servers with load averages above 20 where top showed nothing above 5% CPU. The invisible load was queued processes inside LVE containers waiting for their turn. Standard tools don't show that contention.
Check current LVE statistics with lvetop
lvetop is the real-time equivalent of top, but it displays LVE containers instead of individual processes. Run it as root:
lvetop
You'll see a live table with columns for each resource type and current usage. The ID column maps to the user UID (run id username to confirm). The EP column shows entry processes—active Apache/PHP requests, cron jobs, SSH sessions. PNO is the total process count, TNO is thread count. CPU and MEM are self-explanatory.
Press f inside lvetop to add the faults column. Faults appear as small numbers next to each resource. A steadily climbing CPU fault counter means the account is being throttled continuously. High aCPU (average CPU over the last few seconds) combined with high faults confirms the account is trying to use more than it's allowed.
If you see an account pegged at 100% CPU usage with thousands of faults, that's your bottleneck. Exit lvetop with q and investigate that specific user.
Inspect historical data with lveps
Real-time snapshots are useful, but you need history to catch intermittent spikes. CloudLinux logs LVE statistics every few seconds. The lveps command queries that log:
lveps --period 1h --user username
This dumps the last hour of resource usage for username. You'll see columns for timestamp, CPU percentage, memory in bytes, I/O operations, and faults. Pipe it through grep or awk to filter high-CPU samples:
lveps --period 6h --user username | awk '$3 > 80'
That shows every sample where CPU exceeded 80%. Compare the timestamps to your web server or application logs to correlate spikes with specific requests or cron jobs.
For a bird's-eye view of all accounts, omit the --user flag:
lveps --period 1h --order-by cpu
The --order-by flag sorts by the resource you care about. Common values are cpu, mem, io. This is the quickest way to identify which accounts have been hammering resources over the past few hours.
Find the exact process inside the LVE
Once you know which account is causing load, you need to know what inside that account is responsible. The account might have a dozen WordPress sites, several cron jobs, and an IMAP session. lve-read-snapshot captures a frozen snapshot of every process running inside a specific LVE at the moment you invoke it:
lve-read-snapshot --id $(id -u username)
Replace username with the cPanel user. The output lists every PID, command line, CPU time, and memory usage for processes in that container. Look for long-running PHP scripts, mysql queries, or cron jobs with high CPU seconds.
Another approach: switch to the user and run ps from inside the LVE context:
su - username -s /bin/bash -c "ps aux --sort=-%cpu | head -20"
This shows the top CPU consumers as seen by that user. Combine it with strace or lsof if you need to see what files or sockets a suspect process is touching.
Correlate LVE faults with access logs
Web requests are the most common cause of CPU and entry-process faults. A single POST request to a poorly optimized WordPress admin-ajax.php endpoint can spin for minutes. When you see sustained EP faults, grab the account's Apache access log:
tail -f /home/username/access-logs/example.com
Watch for repeated requests to the same URI or high response times (if using a custom log format that includes %D for microseconds). Cross-reference the timestamps with your lveps output. If the fault spikes align with bursts of POST requests to /wp-admin/admin-ajax.php, you've found your script.
For bulk analysis, use awk to count requests per endpoint over the last hour:
awk '{print $7}' /home/username/access-logs/example.com | sort | uniq -c | sort -rn | head -20
Column 7 is the request URI in the standard combined log format. High request counts to dynamic endpoints are red flags.
Check CloudLinux-specific logs
CloudLinux writes fault events to /var/log/messages when an account is heavily throttled or killed. Grep for the username:
grep username /var/log/messages | grep -i lve
You'll see kernel messages like LVE: user username reached PMEM limit or LVE: user username hit CPU limit. These are useful for confirming that the issue is resource exhaustion rather than a configuration error or a bug in the application.
The /var/lve/info file contains a snapshot of current LVE usage in a machine-readable format. It's updated every few seconds. You can parse it with a script if you want to integrate LVE monitoring into your own alerting system.
So what if the limits are too low?
Sometimes the account is legitimately busy and the LVE limits are too conservative. Compare the account's usage to the server's total capacity. If the server has 8 cores and 32 GB of RAM, a single account capped at 100% CPU (one core) and 1 GB RAM is reasonable for shared hosting. But if this is a reseller with 50 active sites, those limits might choke normal traffic.
You can adjust limits per user with lvectl:
lvectl set username --cpu=200 --pmem=2G --io=2048
That raises the CPU limit to two cores, physical memory to 2 GB, and I/O to 2048 KB/s. Be careful: if you raise limits too high for too many accounts, you're back to the Wild West of unprotected shared hosting. The whole point of LVE is isolation.
A better approach is to move resource-heavy accounts to a VPS or dedicated environment where they have guaranteed resources and you're not risking the stability of 200 other sites.
Common culprits and quick fixes
In support tickets I handled, the usual culprit was one of these:
- WP-Cron running every page load instead of being offloaded to a real cron job. Add
define('DISABLE_WP_CRON', true);towp-config.phpand set up a system cron that hitswp-cron.phpevery 5 minutes. - Brute-force login attempts hammering
wp-login.phporxmlrpc.php. Install a plugin like Limit Login Attempts or blockxmlrpc.phpat the web server level if not needed. - Backup plugins running during peak hours. Schedule backups for 3 AM, not 3 PM. Use incremental backups if possible.
- Unoptimized database queries. Enable the slow query log in MySQL and check
/var/lib/mysql/slow.log. Add indexes or rewrite the queries. - External API calls with no timeout. A plugin that phones home to a third-party service can hang indefinitely if that service is slow. Set short timeouts in
wp_remote_getorcurlcalls. - Large image uploads without server-side resizing. A 12 MB photo uploaded to WordPress will be resized by PHP, which is CPU and memory intensive. Use a CDN or image optimization plugin that resizes on upload.
Once you identify the script or plugin, disable it temporarily and watch lvetop to confirm the load drops. Then either optimize it, replace it, or adjust the account's limits.
Automate LVE monitoring
Manual checks are fine for one-off investigations, but you want alerts before a customer complains. CloudLinux includes a tool called lve-stats that can export data to various formats. You can configure it to send SNMP traps or write to a database, then build dashboards in Grafana or Zabbix.
A simple cron job that emails you when any account exceeds 90% of its CPU limit for more than 5 minutes:
*/5 * * * * /usr/sbin/lveps --period 5m --order-by cpu | awk '$3 > 90 {print $1}' | mail -s "LVE CPU alert" [email protected]
Adjust the threshold and columns to match your priorities. The key is early detection—by the time load average hits 30, half your customers are already seeing slow page loads.
How do I see which cPanel user corresponds to an LVE ID?
Run id -nu <LVE_ID> to convert the numeric ID to a username. The LVE ID is the same as the Unix UID.
Can LVE limits cause 503 errors?
Yes. If the entry-process limit is hit, new Apache requests are rejected and the visitor sees a 503 or timeout. Check your web server error log for "Resource temporarily unavailable" messages.
What's the difference between PMEM and VMEM?
PMEM is physical memory (RAM). VMEM is virtual memory (RAM plus swap). Hitting the PMEM limit can trigger OOM kills. Hitting VMEM usually just prevents new allocations.
Do LVE limits apply to SSH sessions?
Yes. Any process owned by the user runs inside the LVE, including SSH, SFTP, and cron jobs. If an account is throttled, even their SSH session will feel sluggish.
How do I disable LVE for a specific account?
You can't disable it entirely without removing CloudLinux, but you can set limits so high they're effectively unlimited. Use lvectl set username --cpu=9999 --pmem=unlimited. Not recommended for shared hosting.
What to check first
Start with lvetop to see current load, then pull historical data with lveps to identify the time window when load spiked. Use lve-read-snapshot or ps to find the exact process inside the guilty account. Cross-reference timestamps with Apache access logs or application logs to pinpoint the request or script. If the account is legitimately busy and the limits are too tight, raise them—but consider whether the account has outgrown shared hosting. CloudLinux LVE is a safety net, not a magic bullet. It isolates bad neighbors, but it doesn't fix bad code.