CloudLinux LVE tuning without angry customers

CloudLinux's killer feature is LVE — Lightweight Virtual Environment — which puts hard CPU, memory, IO, and process limits around each cPanel user. Set the limits too loose and one runaway WordPress site can drag the whole server down. Set them too tight and your customers get 508 errors during their busiest hour.

This guide is the middle path: a set of defaults that hold up under real shared-hosting load, a workflow for tuning individual heavy users, and the three mistakes that fill your support inbox.

What LVE actually limits

A single LVE caps eight things per cPanel user. Six of them matter day-to-day:

• CPU — percentage of one core, summed across all the user's processes. 100 means one full core; 200 means two.
• EP (entry processes) — the number of concurrent requests that can be entering PHP, CGI, or SSH for this user. This is the limit your customers will hit first.
• PMEM — resident memory, in bytes. The OOM killer triggers here, not at VMEM.
• NPROC — total process count for the user (Apache children, PHP-FPM workers, cron jobs, sshd sessions).
• IO — disk throughput in KB/s, read and write combined.
• IOPS — disk operations per second.

VMEM exists but is effectively deprecated — leave it at 0 (unlimited). Inodes are tracked separately under lvectl's inode limits, which we cover further down.

When a limit is hit, CloudLinux throttles rather than killing — except PMEM, which is a hard ceiling. CPU throttling slows the user's processes; EP throttling returns HTTP 508 to the browser.

Step 1 — Look at the actual data first

Don't guess at limits. Run lveinfo and see what your users are already doing:

lveinfo --period=7d --by-fault=any --order=desc --limit=20

This shows the top 20 users hitting any limit fault over the last week. The output columns to focus on:

• aCPU — average CPU used (out of 100 per core)
• mPMem — peak resident memory
• lEP / fEP — current and faulting EP counts
• lIO — current IO throughput

If your top user is sitting at 30% average CPU with no EP faults, your defaults are probably fine and you have a few specific accounts to tune. If half your users are faulting EP daily, your defaults are too low.

Step 2 — Set defaults that match real WordPress load

For a general-purpose shared-hosting plan running WordPress, WooCommerce, and the usual PHP CMSs, these defaults survive real traffic without being wasteful:

lvectl set default \
  --cpu=100 \
  --ep=20 \
  --pmem=1G \
  --vmem=0 \
  --nproc=100 \
  --io=4096 \
  --iops=1024

What each value buys you:

• CPU 100 — one full core. Bursting briefly to 100% is normal during WordPress page generation; sustained 100% is the noisy-neighbour you want to find with lveinfo.
• EP 20 — twenty concurrent PHP requests. This is the most-tuned setting in the whole list. Less than 10 and any plugin update with a slow database query takes the site down; more than 40 on a small VPS lets one user exhaust your PHP-FPM pool.
• PMEM 1G — generous for WordPress, tight for a Magento store or anything running Composer at runtime.
• IO 4096 / IOPS 1024 — high enough that legitimate cache-warming and backups complete, low enough that a SELECT * on a 5M-row table doesn't saturate the disk.

Apply, then re-check faults after 24 hours:

lveinfo --period=24h --by-fault=ep --order=desc

If a handful of users are EP-faulting, tune them individually rather than raising the default for everyone.

Step 3 — Tune individual heavy users

When one customer legitimately needs more headroom — they're running WooCommerce with 2,000 SKUs, or a busy forum — give them more rather than the whole server.

Look up the user ID:

# UID for cPanel user "acmewp"
id -u acmewp

Set a per-user override:

lvectl set 1234 --cpu=200 --ep=40 --pmem=2G

The per-user setting overrides the default for that UID only. To revert them to defaults:

lvectl remove 1234

If you want this to be a paid upgrade rather than a one-off favour, the standard hosting move is a "Boost" add-on package — create a custom package in WHM with no quota changes, and run lvectl set from a script when the add-on is purchased.

Step 4 — Inode and database limits

LVE also enforces inode and MySQL limits, which are configured separately.

For inodes (file count), edit /etc/container/ve.cfg and add per-user or default entries, then apply:

lvectl apply all

For MySQL Governor (the database equivalent of LVE — caps CPU and IO per database user):

# Switch to abusers mode — only restrict users above the limit
dbctl set --mode=abusers

# Set a default CPU cap of 30% of one core
dbctl set --cpu=30 --io=4096

# Tune one heavy user
dbctl set --username=acmewp_db --cpu=80

MySQL Governor is the single biggest win for shared hosting — bad queries normally take out the entire MySQL service. With Governor in abusers mode, only the abusing account slows down.

Step 5 — Make faults visible to you, not just the customer

By default the customer sees a 508 page and you find out via a support ticket. Enable notifications so you find out first:

# Enable LVE faults notifications in lve-stats
service lvestats restart

# In /etc/sysconfig/lvestats2.cfg
notify_admin = root@yourcompany.com
notify_user = 1   # email the customer too

This emails when limits are sustained for more than 5 minutes (the default grace period). Tune the grace period in the same file if you find the emails are too noisy on brief spikes.

Common mistakes

1. Raising the default to fix one abuser. Find them with lveinfo and tune their LVE alone. Defaults are a baseline, not a workaround.
2. Tuning blind without lve-stats. Without 7 days of historical data you're guessing. Install lve-stats on day one and look at the data before changing anything.
3. Ignoring MySQL Governor. LVE caps PHP but not MySQL. A single bad query on an un-Governed server will tank everyone — Governor is what makes the LVE story complete.
4. Setting PMEM below 512M. Modern WordPress with WooCommerce or LiteSpeed Cache plugin needs 256–384M routinely. 512M is the floor; 1G is the comfortable default.

FAQ

Next steps

• If you're new to CloudLinux, the CloudLinux activation and cPanel integration guide covers the install side of this story
• For the database half of the resource-limiting story, see MySQL Governor: BAD queries to abusers mode
• Volume operators should look at bulk LVE management via CageFS templates and consider activating a CloudLinux license if you haven't already