When your shared hosting server slows to a crawl, finding the culprit account feels like searching for a needle in a haystack. CloudLinux LVE (Lightweight Virtual Environment) technology gives you X-ray vision into exactly which accounts are consuming CPU, memory, and I/O resources. This guide walks complete beginners through every step of diagnosing high server load by account using CloudLinux LVE Manager.
What Is CloudLinux and Why Does It Matter?
CloudLinux is a specialized Linux distribution built specifically for shared hosting environments. Unlike standard Linux distributions, CloudLinux isolates each hosting account into its own lightweight container called an LVE. Think of LVEs as invisible boundaries that prevent one account from monopolizing server resources and affecting others.
Without CloudLinux, a single poorly optimized WordPress site or a runaway PHP script can consume all available CPU and memory, bringing down every website on the server. With CloudLinux, each account gets a defined resource allocation, and the system tracks exactly how much each account uses.
Key Terminology You Need to Know
Before diving into diagnostics, let's define the essential terms:
LVE (Lightweight Virtual Environment): A container that isolates an individual hosting account and limits its resource consumption.
CPU: Processing power allocated to an account, measured in cores or percentage. When an account hits its CPU limit, processes slow down rather than crash.
PMEM (Physical Memory): The actual RAM an account can use. When exceeded, processes may be killed or swapped to disk.
VMEM (Virtual Memory): Total memory including swap space. This limit is typically higher than PMEM.
EP (Entry Processes): The number of simultaneous processes an account can run. Each PHP request, cron job, or SSH session counts as an entry process.
IOPS (Input/Output Operations Per Second): Disk read/write operations. High IOPS usage often indicates database-heavy applications or file system stress.
Faults: Occur when an account tries to exceed its allocated resources. A fault doesn't mean something broke, just that the limit was enforced.
Prerequisites: What You Need
Before you start diagnosing server load, verify you have:
- Root or sudo access to your server
- CloudLinux OS installed (check with
cat /etc/redhat-releaseorhostnamectl) - LVE Manager installed (typically comes with CloudLinux)
- WHM/cPanel access (optional but recommended for easier navigation)
If CloudLinux isn't installed, you'll need to convert your existing CentOS or AlmaLinux server or provision a fresh CloudLinux server. This guide assumes CloudLinux is already running.
Accessing LVE Manager
LVE Manager is your primary tool for diagnosing resource usage. You can access it through multiple interfaces.
Via WHM (Easiest for Beginners)
- Log into WHM as root
- Search for "LVE Manager" in the left sidebar search box
- Click on "LVE Manager" under the CloudLinux section
- You'll see the main dashboard with current statistics
Via Command Line
For SSH access, CloudLinux provides several command-line tools:
# View current resource usage by account
lveps
# Detailed statistics for all users
lvetop
# Historical statistics
lveinfo --period 1d --by-usage=cpu
The lvetop command works like the standard top command but shows LVE-specific resource usage. Press q to quit.
Understanding the LVE Manager Dashboard
When you first open LVE Manager in WHM, you'll see several tabs:
Current Usage: Real-time snapshot of what accounts are using right now
Statistics: Historical data showing patterns over time
Users: Individual account details and resource allocation
Packages: Default limits assigned to hosting packages
Options: Global LVE settings and configurations
For diagnosing high load, you'll primarily use Current Usage and Statistics.
Step-by-Step: Identifying the High-Load Account
Step 1: Check Current Usage
- Open LVE Manager and click the Current Usage tab
- Look at the sortable columns: CPU, PMEM, IOPS, EP, and VMEM
- Click the CPU column header to sort by CPU usage (highest first)
- Note which accounts show high percentages or frequent faults
An account consistently at or near its limit will show a percentage close to 100%. The "Faults" column shows how many times the account hit its ceiling.
Step 2: Examine Historical Patterns
- Switch to the Statistics tab
- Set the time period dropdown to Last 24 hours or Last 7 days
- Select the metric you want to analyze (CPU, Memory, IOPS, etc.)
- Click Show to generate the report
This view reveals whether high usage is constant or occurs at specific times. A spike every night at midnight might indicate a cron job, while constant 100% usage suggests an ongoing issue.
Step 3: Drill Down into Specific Accounts
Once you've identified a suspect account:
- Click on the username in the statistics list
- Review the detailed graph showing resource usage over time
- Note when faults occur and what resource is being limited
- Check the "Top Processes" section to see what commands are running
The Top Processes view shows exactly which scripts or applications are consuming resources within that account.
Common High-Load Scenarios and What They Mean
Scenario 1: High CPU with High EP
What it looks like: CPU at 100%, Entry Processes at or near limit, many faults.
What it means: The account is receiving more traffic or requests than its resources can handle, or inefficient code is processing each request slowly.
Where to look: Check for traffic spikes, poorly optimized WordPress plugins, or missing caching.
Scenario 2: High IOPS with Moderate CPU
What it looks like: IOPS constantly hitting limits, CPU usage moderate, PMEM normal.
What it means: Heavy database operations, file uploads/downloads, or a site scanning the filesystem excessively.
Where to look: Database queries without indexes, backup scripts, or WP plugins that scan files.
Scenario 3: High PMEM with Low CPU
What it looks like: Physical memory maxed out, CPU usage low or sporadic.
What it means: Memory leaks in application code, large data structures held in memory, or insufficient memory allocation for the workload.
Where to look: PHP memory_limit settings, caching plugins that store too much in memory, or long-running processes.
Scenario 4: Everything Maxed Out
What it looks like: All metrics showing faults and 100% usage.
What it means: Either the account genuinely needs more resources, or it's under attack (brute force, DDoS, malware).
Where to look: Access logs for suspicious patterns, malware scaners, and whether the site is legitimate high-traffic or compromised.
Using Command-Line Tools for Deeper Diagnosis
While the GUI is beginner-friendly, command-line tools offer more flexibility.
The lveps Command
# Show current usage for all accounts
lveps
# Show only accounts hitting limits
lveps --threshold=90
# Monitor in real-time (updates every 2 seconds)
watch -n 2 lveps
The output shows columns for CPU, MEM (memory), IO (IOPS), and other metrics, with the account username in the first column.
The lvetop Command
lvetop
This interactive tool updates continuously and shows: - ID: The LVE ID (typically matches the user ID) - CPU: Current CPU usage percentage - MEM: Current memory usage - IO: Current I/O usage - Other metrics in real-time
Press c to sort by CPU, m for memory, or i for I/O while lvetop is running.
The lveinfo Command for Historical Data
# Show top CPU users from the last 24 hours
lveinfo --period 1d --by-usage=cpu --limit=10
# Show accounts with the most faults
lveinfo --period 1d --by-fault=any --limit=10
# Get detailed info for specific account
lveinfo --user=username --period 1d
The --period flag accepts values like 1h (1 hour), 1d (1 day), 1w (1 week), or 1m (1 month).
What to Do After Identifying the Problem Account
Finding the high-load account is only half the battle. Here's your action checklist:
1. Notify the Account Owner
Send a clear email explaining: - Which resources are being exceeded - When the issue occurs - Potential causes (if obvious) - What they should investigate
Most users don't intentionally abuse resources and will appreciate the heads-up.
2. Review the Account's Content
Log into the account (with permission or under your TOS) and check:
- Error logs in cPanel or /home/username/logs/
- Recently modified files (possible hack)
- Cron jobs that might be running too frequently
- Database size and table optimization needs
3. Adjust LVE Limits if Legitimate
If the usage is legitimate (popular site, growing business):
- Go to LVE Manager → Users
- Find the account and click Edit
- Increase the appropriate limits (CPU, memory, IOPS, EP)
- Click Save
Alternatively, upgrade the account to a hosting package with higher default limits.
4. Implement Temporary Restrictions
If the account is compromised or violating TOS:
- Reduce limits temporarily to protect other users
- Suspend the account if necessary
- Run malware scans using tools like Imunify360 or ClamAV
5. Enable Resource Monitoring Alerts
Prevent future surprises by configuring alerts:
- In LVE Manager, go to Options
- Configure Faults notification thresholds
- Enter admin email addresses
- Set appropriate fault count thresholds
You'll receive emails when accounts consistently exceed limits.
Optimizing LVE Limits for Your Server
Default LVE limits might not suit your server's hardware or customer base. Here's how to adjust them intelligently.
Understanding Package Limits
- Go to LVE Manager → Packages
- You'll see limits for each cPanel package
- Click Edit next to any package to adjust defaults
When setting limits, consider: - Total server resources divided by expected simultaneous active accounts (not total accounts) - Buffer capacity of at least 20-30% to handle traffic spikes - Resource type most critical for your customer base (CPU for dynamic sites, IOPS for database-heavy apps)
The Formula for Safe Limits
A rough starting point:
- CPU: (Total server cores × 0.7) / (Expected concurrent active sites)
- PMEM: (Total RAM × 0.8) / (Expected concurrent active sites)
- EP: 20-50 for typical sites, 100+ for high-traffic applications
- IOPS: 1024 minimum, 2048 for database-heavy sites
These are starting points; monitor and adjust based on real usage patterns.
Troubleshooting Common LVE Manager Issues
LVE Manager Not Showing Data
# Verify LVE is running
systemctl status lvestats
# Restart statistics collection
systemctl restart lvestats
# Check for errors
tail -f /var/log/lve-stats.log
Faults Showing but No Performance Issues
Brief, occasional faults are normal and don't always indicate problems. Only sustained faults (hundreds per hour) require action.
Command-Line Tools Not Found
Ensure CloudLinux packages are installed:
yum install lve-stats lve-utils
Conclusion
CloudLinux LVE Manager transforms server resource diagnosis from guesswork into precise measurement. By following the steps in this guide—checking current usage, reviewing historical patterns, drilling down into specific accounts, and taking appropriate action—you can quickly identify which accounts are causing high server load and resolve issues before they affect all your customers.
Start with the Current Usage tab for immediate problems, use Statistics for pattern analysis, and leverage command-line tools like lveps and lvetop for real-time monitoring. Remember that faults are informational, not failures; they show the system is working correctly by enforcing limits. With practice, diagnosing resource usage becomes routine maintenance rather than emergency firefighting.
The key to success is regular monitoring combined with automated alerts. Check your LVE statistics weekly, configure fault notifications, and address issues proactively. Your server performance—and your customers' experience—will improve dramatically.