A fresh CloudLinux install gives every account the same defaults, and those defaults are deliberately conservative. This guide explains what each limit means, gives worked starting values for three package tiers, and shows how to apply them from the CloudLinux Manager and from lvectl. It ends with the call that matters most: raise the limit, or move the customer up.
What each limit means
SPEED is CPU, as a percentage of one core. 100% is one core; 200% is two. The account's processes are throttled at that level, never killed.
PMEM is the physical memory of all the account's processes added together. Exceed it and the allocation is refused: PHP reports an out-of-memory error or the process dies.
IO is disk throughput in KB/s, and IOPS is disk operations per second. Both throttle rather than fail.
NPROC is the number of processes the account may have at once. At the limit, fork fails.
EP (entry processes) is the number of requests that can be inside the account at the same time. The next one gets a 508 Resource Limit Is Reached.
VMEM, virtual memory, is the seventh limit; leave it unlimited. What each looks like when it is hit is described in LVE explained.
The defaults, and why you will change them
A new install sets SPEED 100%, PMEM 1G, IO 1024 KB/s, IOPS 1024, NPROC 100 and EP 20. CPU, memory and EP are fine for a small site. IO at 1 MB/s is not: a WordPress core update, a plugin's backup run or an image regeneration crawls at that speed and produces IO faults all day without anything being wrong. Plan to raise it before customers notice.
Starting values for three tiers
These are starting points for a busy shared server, in the ranges we use, scaled so that a bigger package really does get more. Adjust them once you have a week of statistics.
| Limit | Starter | Business | Agency |
|---|---|---|---|
| SPEED | 100% | 200% | 300% |
| PMEM | 1G | 2G | 3G |
| IO | 5120 KB/s (5 MB/s) | 10240 KB/s (10 MB/s) | 20480 KB/s (20 MB/s) |
| IOPS | 1024 | 2048 | 4096 |
| NPROC | 100 | 150 | 200 |
| EP | 20 | 30 | 40 |
The sum across all accounts is far more than the server has; that is normal. LVE limits are ceilings, not reservations, and a sixteen-core server can sell forty accounts at 200% because they do not peak together. The tiers are also meant to differ visibly: if Business and Starter both allow 100% CPU, a customer has no reason to upgrade.
Setting limits in CloudLinux Manager
In DirectAdmin, open Admin Level → Extra Features → CloudLinux Manager (cPanel and Plesk have the same screen under WHM or Tools & Settings). The Packages tab lists every hosting package on the server with its six limits; click a package, enter the values and save, and every account on that package gets them at once. The Users tab shows each account's current limits and lets you override a single user. Options holds the server-wide defaults, which apply to any account whose package has no limits of its own.
The command line is for scripting, bulk changes, and checking what is actually in force.
Setting limits with lvectl
Set the server-wide defaults to the Starter tier:
lvectl set default --speed=100% --pmem=1G --io=5120 --iops=1024 --nproc=100 --maxEntryProcs=20Attach the Business tier to a package. The package name is the one DirectAdmin shows in Reseller Level → Manage User Packages:
lvectl package-set business --speed=200% --pmem=2G --io=10240 --iops=2048 --nproc=150 --maxEntryProcs=30Override one user by name, or by LVE id (the numeric user id), keeping any parameters you do not mention:
lvectl set-user bob --speed=300% --pmem=3G
lvectl set 1001 --maxEntryProcs=40 --save-all-parametersPush the saved configuration into the running kernel and list what is now in force:
lvectl apply all
lvectl limitslvectl list shows the same per LVE id. There is no one-flag way to drop a user override from the command line; set the user back to the package values, or remove the override on the Users tab, which is quicker.
Units trip people up: --io is in KB/s, so 10 MB/s is --io=10240, and --pmem accepts M and G.
Package limits versus user overrides
Precedence is user override, then package, then default. Keep overrides rare. Every one is a hidden discount: an account paying for Starter but running with Agency limits, invisible in your billing system and forgotten once the engineer who set it leaves. If a customer regularly needs more than their package, the answer is a bigger package, and if a package's limits are wrong for everyone on it, change the package.
The exception is temporary: a customer doing a one-off migration or a large import can have their IO and PMEM raised for a day, with a note to put it back.
When to raise, and when to move the customer up
Faults tell you which limit is hit and how often; lveinfo --period=7d --by-fault=any lists accounts by fault type for the week, and the Statistics tab shows the same as graphs.
Raise the limit when the faults are a symptom of the limit being wrong, not of the site being wrong. IO faults during a nightly backup on an otherwise quiet account mean IO is too low. Occasional PMEM faults on a Business account running WooCommerce with a 512M PHP memory limit mean 2G is tight for that tier; consider raising the tier.
Fix the site when the faults come from wasted work. EP faults with a low CPU figure almost always mean slow requests, a missing cache, or bots on xmlrpc.php and wp-login.php; twenty entry processes is plenty for a healthy site. CPU faults on a site with no caching are the site's problem, and raising SPEED only lets it waste more.
Move the customer up when the site is healthy and still hits the limits. A well-cached shop with real traffic that sits at 100% CPU all day is not misbehaving; it has outgrown Starter, and the graphs in their panel make that an easy conversation.
On a VPSPioneer managed VPS we set the initial package limits when we convert a server to CloudLinux.