cPanel Resource Usage: What Your Account Limits Actually Mean

Shared hosting works because every account on a server gets a fair share of it. On our servers that share is enforced by CloudLinux, which gives each account its own set of limits. Most of the time nobody notices they are there. When a site does reach one, the symptoms can look like a fault with the site itself, so it is worth knowing what each limit measures and where to check whether you have hit it.

Where to look

In cPanel, open Resource Usage in the Metrics section. It shows how much of each resource your account has used over time, and how many times each limit was reached. That history is the useful part: a slowdown last Tuesday afternoon can be matched against what the account was doing at that moment.

The limits

CPU. The share of processor time the account can use, where 100% is one full CPU core. Reaching it does not produce an error. Pages simply take longer, because the work waits its turn rather than being refused.

Physical memory. The total memory used by all of the account’s processes at once. Reaching this one is more abrupt. A process that asks for memory the account does not have is stopped, which usually shows up as a 500 or 503 error, or a blank page, on whichever request pushed the total over.

Entry processes. How many things can be entering the account at the same moment: each web request that runs PHP, plus cron jobs and SSH sessions. This is not a limit on visitors. A page that runs in a tenth of a second frees its slot almost immediately, so a limit of twenty can serve far more than twenty people. When every slot is busy, the next request receives a 508 Resource Limit Is Reached error.

Number of processes. The total number of processes the account can run at once, including those that are not handling a web request, such as cron jobs and anything started over SSH.

I/O and IOPS. How fast the account can read from and write to disk, measured as a data rate and as operations per second. Like CPU, reaching these slows things down rather than causing errors. Backups, large uploads and scripts that write cache or log files heavily are the usual causes.

What a fault is

Each time a limit is reached, it is counted as a fault against that resource. A handful of faults in a month is normal, and often just a burst of traffic or one heavy task in the admin area. What matters is the pattern. Faults at the same time every day point to a scheduled job. Faults that rise and fall with traffic point to pages that do too much work for each request.

Finding the cause

The limits are rarely the real problem. They are where an inefficiency becomes visible.

1. Match the time. Note when the faults happened and look at the access log for the same period. A flood of requests to one address, often a search page, a login page or xmlrpc.php, is usually bots rather than customers. We covered how to tell the two apart in why your visitor numbers suddenly exploded.
2. Check scheduled work. Cron jobs that overlap, because the previous run has not finished when the next one starts, are a common cause of faults at regular times. See why WordPress cron jobs misbehave for one very common example.
3. Look at caching. A page served from a cache costs almost nothing. A page built from scratch for every visitor costs the full amount every time, and that multiplies under load.
4. Look for slow requests. A report or export that takes thirty seconds holds an entry process and its memory for the whole thirty seconds.

Our beginner’s guide to website speed covers the measurements worth taking before changing anything.

When a bigger plan is the answer

Sometimes a site has simply outgrown its plan: steady, genuine traffic, faults that follow it closely, and caching already in place. In that case more resources are the right fix, and moving to a larger plan provides them without any change to the site. If you are not sure which situation you are in, open a ticket. We can see the same history you can, and it is usually quick to tell the two apart.