Shared hosting has one structural weakness: hundreds of accounts use the same CPU, memory and disks, and without a referee the busiest one wins. The result is a site that is fast at 09:00 and unreachable at 14:00 for reasons that have nothing to do with it. CloudLinux is the referee. This post is written for the person with a hosting account, not the server administrator: what the system does, what you see when you reach a limit, how to read your own usage, and how to stay comfortably inside it.
The problem it solves
On a plain Linux server a hosting package limits disk space, traffic and the number of domains. None of those measure what an account is doing this second. A looping plugin, a bot crawling a search page, or an import script can take every CPU core, and every other site queues behind it.
CloudLinux replaces the kernel with one that puts each account in its own container, called an LVE, with a ceiling on what it can use at any moment. The account that misbehaves slows down. The others do not notice. What the product is and which editions exist is in what is CloudLinux OS; the rest of this post is about living with it.
The limits, from the customer's side
Each account has six limits that matter. The mechanics are in LVE explained; this is what each one feels like.
| Limit | What it caps | What you see at the limit |
|---|---|---|
| CPU (SPEED) | Processor time, as a percentage of one core | Pages get slower. No error. |
| Memory (PMEM) | RAM used by all your processes together | A heavy request fails: blank page, 500, or "Out of memory" in the error log |
| IO | Disk throughput | Backups, imports and uploads take longer. No error. |
| IOPS | Disk operations per second | Same as IO |
| Entry processes (EP) | Requests being processed at the same moment | 508 Resource Limit Is Reached |
| Processes (NPROC) | Total processes, including cron and SSH | fork: Resource temporarily unavailable, or a 500 |
Two points people get wrong. First, the limits apply to the account, not to each site: three domains in one account share one allowance. Second, entry processes are not "visitors". An entry process is a request being executed right now, so a site whose pages take 200 ms serves a great many visitors on a small EP limit, and a site whose pages take six seconds fills it with a handful.
What a 508 means
The page says "Resource Limit Is Reached" and the status code is 508. It means the account already had its maximum number of requests in progress when another arrived, and the server refused the new one. The server is not failing, and other accounts are not affected, which is the point.
It is nearly always one of three things:
- Requests are slow, so they pile up. An uncached WordPress page, a plugin waiting on a remote API, a slow database query.
- Something is sending many requests at once: a crawler, or a password-guessing bot on
wp-login.phporxmlrpc.php. - The site really is busy, and has outgrown the plan.
Check in that order. The third is the rarest.
Reading your resource usage
CloudLinux adds a Resource Usage page to the control panel. In DirectAdmin it is under Advanced Features; cPanel has the same page. It shows:
- A summary telling you whether the account hit any limit in the last 24 hours.
- Current usage: graphs of CPU, memory, IO, entry processes and processes against their limits, with a selectable time frame.
- Faults: a count of how many times each limit was reached. A fault is one moment where the limit applied, not a period of downtime.
- Snapshots, where the host has enabled them: the processes and database queries that were running at the moment of a fault. This is the most useful screen in the panel, because it names the script.
A line that touches the limit briefly during a backup is normal. A line that sits flat against it for hours is a problem, and the shape tells you which kind. Flat CPU with low entry processes is one heavy job, usually a cron task or an import. Entry processes at the ceiling with modest CPU is slow requests or bots.
Tip: note the time of the fault, then look at the same minute in your access log. In DirectAdmin the log is available under Site Summary / Statistics / Logs. Twenty requests in one second from one IP address is a bot; twenty requests for admin-ajax.php is a plugin.
On the other side of the ticket, your host sees the same numbers through these commands:
# live view, one line per account
lveps
# accounts that hit any limit in the last day
lveinfo --period=1d --by-fault=any
# the limits in force for each account
lvectl listThese need root, so they are not something you run on a shared account.
CageFS and PHP Selector
CageFS gives each account its own view of the filesystem: you see your own files and a private copy of the system directories, not other users' home directories, their processes or the server's configuration. A compromised site on the same server cannot read your wp-config.php. Details are in what CageFS does.
You can see it from an SSH session, if your plan has one:
ls /home # only your own home directory
ps aux # only your own processesPHP Selector lets each account choose its PHP version and extensions without affecting anyone else. On our web hosting plans, versions 7.4 to 8.5 are selectable per site.
Tip: moving from PHP 7.4 to a current PHP 8 release is the cheapest performance gain there is, and faster requests mean fewer entry processes in use. Test on a copy of the site first.
MySQL Governor does for the shared database server what LVE does for PHP: it tracks database CPU and IO per account and restricts the account that exceeds its share, so one unindexed query in a loop does not slow everyone's queries.
Staying within the limits
Most accounts that hit limits are doing unnecessary work. In rough order of effect:
Cache pages. A cached page is served in milliseconds and frees its entry process almost immediately. For WordPress this is the single biggest change.
Move WP-Cron to a real cron job. By default WordPress triggers its scheduler from page views, adding a second PHP request to many visits. Disable that in wp-config.php:
define('DISABLE_WP_CRON', true);and add a cron job in the panel that runs every ten minutes. The PHP path varies by server, so check with your host if php alone does not work:
*/10 * * * * php /home/username/domains/example.com/public_html/wp-cron.php >/dev/null 2>&1Cron syntax is covered in scheduling tasks with cron.
Block XML-RPC if you do not use it. It is the favourite target for password-guessing bots, and each attempt takes an entry process. In .htaccess:
<Files "xmlrpc.php">
Require all denied
</Files>Leave it open if you use the WordPress mobile app or Jetpack.
Schedule heavy jobs at night. Backups, imports and image regeneration use CPU, memory and IO together. Run them when visitors are not competing for the same allowance.
Tip: a backup plugin that writes archives into the account uses your IO limit and your disk quota. If the host already takes daily backups, one extra off-site copy a week is usually enough.
When the limit is the right size and the site is not
If the site is cached, free of bots, on a current PHP version, and still sits at its limits every day, the site needs more than the plan provides. The answer is a larger plan or a VPS, where the resources are yours alone. Shared, VPS and dedicated compared explains where that line falls.
That is the value of CloudLinux for a customer. Without it, a slow afternoon could be you or any of several hundred neighbours. With it, the limit is written down, and if your site is slow the cause is inside your own account, where you can fix it.