LVE limits explained: CPU, memory and entry processes per account

An LVE limit is a ceiling on four things: processor time, memory, concurrent processes and input/output. Each hosting account gets its own. Knowing which of the four you are hitting is the difference between fixing a site in ten minutes and moving it to hardware it did not need.

The four numbers that matter

• CPU (SPEED): expressed as a percentage of a core, or of several. Hitting it does not produce an error. Requests simply queue and the site feels sluggish under load while staying fine when idle.
• Physical memory (PMEM): the real memory your processes may hold. Exceeding it kills a process, so the visible symptom is an abrupt 500 error rather than slowness.
• Entry processes (EP): how many requests may be in flight at once. This is the one most people misread. It is not visitors and it is not connections; it is dynamic requests being executed at this instant.
• Input/output (IO and IOPS): disk throughput and operations per second. Backups, large imports and unindexed database queries live here.

Why entry processes trips people up

A limit of, say, twenty entry processes sounds tiny next to a traffic figure of twenty thousand visits a month. The two are not comparable. If a page is generated in 200 milliseconds, one entry process can serve roughly five requests per second on its own. The number only becomes a constraint when requests are slow, because slow requests occupy the slot for longer.

This is why entry process errors and slow pages are usually the same problem seen from two angles. Fix the slow query and the queue disappears without changing any limit.

What each symptom usually means

1. Site is fast alone, slow under traffic: look at CPU first, then entry processes.
2. Random 500 errors, no pattern in traffic: look at memory. Something is spiking past the ceiling and being killed.
3. Site stalls during a backup or an import: look at IO and IOPS.
4. Errors only on one site out of many: the limit is per account, so this is that site's own workload, not the server.

How this shapes a multi-site network

Because limits apply per account rather than per site, the way you group sites decides how they compete. Twenty small brochure sites in one account share one ceiling between them. The same twenty split across several accounts each get their own. Neither is automatically right, but the choice is yours to make deliberately rather than by accident.

A practical rule: keep the sites that spike together apart. If three of your sites publish on the same schedule and get crawled at the same time, they will queue against one another if they sit in the same account.

When the ceiling is the real answer

Limits exist because the hardware is shared, and raising them for one account lowers what is available to the rest. If a site sits at its ceiling routinely rather than occasionally, it has outgrown shared hosting. That is not a failure of the plan; it is the plan doing its job and telling you something. The next step is a KVM VPS where the resources are reserved, or a whole machine if the workload justifies it.

Before you conclude that, though, check the cheap causes: an uncached WordPress front page, a plugin polling on every request, a cron job running every minute, a missing database index. Those produce identical symptoms and cost nothing to fix. The component reference at docs.cloudlinux.com describes what each limit governs.

Caching removes most CPU pressure on a content site before any limit is touched, which is covered in Speed and Caching. If you are working out how many accounts a network needs in the first place, start with Sizing and Selection.