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

Source: https://srvscripts.com/guides/cloudlinux-lve-limits-explained/
Updated: 2026-10-06
Publisher: srvScripts (https://srvscripts.com/)

**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:

- **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.

- **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](/guides/apache-php-fpm-cpanel-php-fpm-tuning/)).

- **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.

- **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.

- **Leave VMEM at 0.** CloudLinux calls it deprecated, and it causes failures that are hard to explain.

- **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.

- **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](https://docs.cloudlinux.com/cloudlinuxos/limits/) · [CloudLinux docs: command-line tools (lveinfo)](https://docs.cloudlinux.com/cloudlinuxos/command-line_tools/) · [CloudLinux KB: default and recommended LVE values](https://cloudlinux.zendesk.com/hc/en-us/articles/9299899421084-LVE-limits-default-values-and-recommended-values) · [CloudLinux KB: how to change LVE limits](https://cloudlinux.zendesk.com/hc/en-us/articles/13417588570140-How-to-change-LVE-limits)

**Related:** [CloudLinux 10 cPanel: CageFS and LVE Limits, Upgrade Notes](/guides/cloudlinux-10-cpanel-cagefs-lve/) · [cPanel PHP-FPM Tuning: Sizing pm.max_children and OPcache](/guides/apache-php-fpm-cpanel-php-fpm-tuning/) · [High Load cPanel Server: Find the Culprit Fast (5 Tools)](/guides/high-load-cpanel-server/) · [Harden Shared cPanel Server: Secure CageFS and ModSecurity Setup](/guides/harden-shared-cpanel-server/) · [Best VPS for cPanel and DirectAdmin in 2026: What to Check](/guides/best-vps-for-cpanel-directadmin-server/)

**See also:** [“508 Resource Limit Is Reached”: Find and Fix the Limit](/guides/508-resource-limit-reached/) · [“Cannot Manage PHP Versions When CageFS Is Disabled”: PHP Selector Fix](/guides/cloudlinux-php-selector-cagefs-error/)

## Frequently asked questions

### What does EP mean in CloudLinux?

EP is entry processes: the number of concurrent entries into the account’s LVE, mostly PHP/CGI requests plus SSH and cron. When it is reached, the web server returns 508 Resource Limit Is Reached.

### What is the difference between EP and NPROC?

EP limits concurrent entries (requests). NPROC limits all processes and threads inside the LVE, including those started by the requests. NPROC should always be higher than EP.

### Does SPEED 100% mean the whole server CPU?

No. 100% is one CPU core. 200% is two cores.

### Should I set a VMEM limit?

No. CloudLinux says VMEM limits are deprecated and recommends setting them to 0. Use PMEM to limit memory.

### How do I see which limit a site is hitting?

Run lveinfo -d –period=1d –user=bob, or lveinfo with –by-fault=any for all accounts, and look at the fault columns (CPUf, EPf, PMemF, NprocF, IOf, IOPSf).