CloudLinux LVE Limits Explained: SPEED, PMEM, EP, NPROC, IO

Short answer: CloudLinux puts each hosting account in its own LVE with seven limits. SPEED caps CPU (100% = one core) and PMEM caps physical memory. EP caps concurrent entry processes, mostly PHP requests. NPROC caps all processes and threads, and IO and IOPS cap disk throughput and operations. VMEM is deprecated and should be 0. A “fault” means the account hit a limit. Read faults with lveinfo and change limits in CloudLinux Manager or with lvectl set-user.

Commands checked against the official CloudLinux documentation and knowledge base (linked below) on 6 October 2026; not yet run on our lab servers. Our cPanel lab is on plain AlmaLinux without CloudLinux, so there is no sample output on this page.

How LVE limits work

LVE (Lightweight Virtual Environment) is CloudLinux’s kernel-level container for one hosting account. Everything that account runs counts against the same limits: PHP requests through the web server, cron jobs and SSH sessions. When the account reaches a limit, CloudLinux slows it down, refuses new processes or kills processes inside that LVE only. The other accounts on the server keep running, which is the reason to use CloudLinux on shared hosting.

Limits come from three places, from most to least specific: limits set on the user, limits set on the user’s hosting package, and the server default. On cPanel, the CloudLinux Manager plugin in WHM manages all three.

Each LVE limit at a glance

Defaults and behaviour below are taken from the CloudLinux limits documentation:

Limit	What it caps	Unit	Default	When the account hits it	Fault column
SPEED	CPU time, relative to one core	% of a core, or Hz/MHz/GHz	100%	The site responds more slowly (CPU is throttled)	CPUf
PMEM	Physical memory (RSS), including shared memory and disk cache	KB (set as MB/GB)	1024 MB	Disk cache is freed first, then processes in the LVE are killed. Usually 500 or 503 errors.	PMemF
VMEM	Virtual memory (VSZ)	KB	0 (off)	Processes fail, usually 500/503. Deprecated: keep it at 0.	VMemF
EP	Entry processes: concurrent PHP/CGI requests plus SSH and cron entries	count	20	The web server returns 508 Resource Limit Is Reached	EPf
NPROC	All processes and threads in the LVE	count	100	No new process can start. Apache may return 500 or 503.	NprocF
IO	Disk read + write throughput (cache hits and network are not counted)	KB/s	1024 KB/s	Processes are throttled (put to sleep)	IOf
IOPS	Disk read/write operations per second	ops/s	1024	Operations wait until the current second ends	IOPSf

Two details people often miss:

• SPEED is per core. 100% is one full core and 200% is two. On a 32-core server, 100% is about 3% of the machine. You can also set it in MHz/GHz so the limit stays the same speed on different CPUs.
• EP counts entries, not every process. A PHP request entering the LVE counts as one entry process. Processes started inside the LVE (for example a PHP script calling exec()) count towards NPROC, not EP.

What “faults” mean

A fault is one event where the account tried to go over a limit. CloudLinux counts them per limit, which is how you tell which limit is the problem:

• EPf rising: too many concurrent dynamic requests. Visitors see 508 errors.
• PMemF rising: processes were killed for memory. Visitors see 500/503, and PHP logs show workers dying.
• NprocF rising: process table full for that account (often cron jobs piling up, or a runaway script).
• CPUf / IOf / IOPSf rising: the site was slowed down, not broken. Look at these when customers say “slow”, not “down”.

A few faults at peak hours are normal and show the limits are working. Hundreds per hour on one account means either the limit is too low for a legitimate site, or something abnormal (a bot, a cron loop, an exploit) is running.

Read current usage and faults

lveinfo reads the history collected by lve-stats. The documented options include --period (minutes m, hours h, days d), -u/--user, -d/--display-username, --by-fault, --by-usage, -o/--order-by, -l/--limit and --show-columns.

# which accounts hit any limit in the last 2 hours (fault columns only)
lveinfo -d --period=2h --by-fault=any --show-columns="ID,CPUf,EPf,PMemF,NprocF,IOf,IOPSf"

# history for one account
lveinfo --period=1d --user=bob

# only accounts with entry-process faults
lveinfo -d --period=1d --by-fault=ep

--by-fault accepts these aliases (not case sensitive): cpu/mcpu, vmem/mem, ep/mep, pmem, nproc, io, iops and any/any_faults.

For live data, lvetop shows LVE usage in real time, like top per account, and cat /proc/lve/list shows the kernel’s raw view. In WHM, CloudLinux Manager shows the same data per user with graphs. That is often the fastest way to show a customer what happened.

Change limits for a user, a package or the server

The CloudLinux knowledge base recommends CloudLinux Manager (WHM: Users tab, then the edit/pencil icon on the user) as the main method. Use the Packages tab to change limits for everyone on a hosting plan. From the command line, use lvectl:

# give one user 2 GB of physical memory
lvectl set-user bob --pmem=2048m

# raise entry processes for one user to 40 and save
lvectl set-user bob --maxEntryProcs 40 save

# show the limits currently configured
lvectl list

# re-apply configured limits to all LVEs
lvectl apply all

The first two examples are taken from the CloudLinux and cPanel knowledge-base articles linked below. lvectl also has set (server default), package-set, set-reseller and set-reseller-default. Run lvectl --help on your server for the full option list before you script changes, because options differ between CloudLinux releases.

Prefer package limits over per-user limits. One-off user overrides are easy to forget, and they silently keep a customer on special limits after they downgrade their plan.

Inode limits are separate from LVE: CloudLinux applies them as disk quotas on /home. In WHM they are in the same CloudLinux Manager Users and Packages tabs.

How to choose limits

CloudLinux publishes two starting profiles in its knowledge base:

Limit	Typical hosting account	High-end hosting account
SPEED	100%	200%
PMEM	512 MB	1 GB
VMEM	0	0
IO	1024 KB/s	4096 KB/s
IOPS	1024	1024
NPROC	100	100
EP	20	40

Then adjust using what you know about the server and the plans:

1. Start with the hardware. Add up SPEED across the busiest accounts at the same time, and compare with your cores. Do the same for PMEM against your RAM. You can oversell, because not all sites peak together, but know by how much.
2. Match EP to PHP. EP is the ceiling on concurrent PHP requests. If PHP-FPM allows more children per account than EP, those extra workers never get used, and visitors get 508 instead. Size them together (see cPanel PHP-FPM tuning).
3. Keep NPROC well above EP. NPROC counts every process and thread, including the EP ones, cron jobs, SSH sessions and helper processes. If NPROC equals EP, a few cron jobs can push the site into 500 errors.
4. Give PMEM enough for EP × memory per PHP request. A WooCommerce site with 20 entry processes at 128 MB each needs more than 512 MB at peak.
5. Leave VMEM at 0. CloudLinux calls it deprecated, and it causes failures that are hard to explain.
6. Raise IO/IOPS for accounts that run backups or large imports, or schedule those jobs off-peak. Throttled IO looks like a slow site, not an error.
7. Review faults monthly. If one plan shows constant EP or PMEM faults across many accounts, the plan is too tight. If one account shows faults, look at that account first.

Common mistakes

• Raising limits for an account that is under a bot attack or running a hacked script. Faults are a symptom: check the access log first.
• Setting SPEED as if it were a share of the whole server (100% is one core, not “the whole CPU”).
• Editing limits per user, then wondering why the package change did nothing (user settings override package settings).
• Expecting LVE limits alone to control a heavy database. Queries run inside the MariaDB/MySQL server process. CloudLinux handles that side with a separate component, MySQL Governor, which has its own settings.

Official documentation: CloudLinux docs: Limits · CloudLinux docs: command-line tools (lveinfo) · CloudLinux KB: default and recommended LVE values · CloudLinux KB: how to change LVE limits

Related: CloudLinux 10 cPanel: CageFS and LVE Limits, Upgrade Notes · cPanel PHP-FPM Tuning: Sizing pm.max_children and OPcache · High Load cPanel Server: Find the Culprit Fast (5 Tools) · Harden Shared cPanel Server: Secure CageFS and ModSecurity Setup · Best VPS for cPanel and DirectAdmin in 2026: What to Check

See also: “508 Resource Limit Is Reached”: Find and Fix the Limit · “Cannot Manage PHP Versions When CageFS Is Disabled”: PHP Selector Fix

Frequently asked questions