# CloudLinux and LVE limits explained
Source: https://docs.webgee.com/en/performance/understanding-cloudlinux-and-lve-limits-enhancing-server-stability-and-performan



Every WebGee shared and reseller account runs inside its own **Lightweight
Virtual Environment (LVE)** — a CloudLinux container with fixed resource limits.

## Why the limits exist [#why-the-limits-exist]

On shared hosting without isolation, the most common cause of downtime is one
account consuming everything. A runaway script, a plugin in a loop, or a site
under attack would slow the server for everyone on it.

LVE contains that. An account that exceeds its limits is throttled or has
processes killed; every other account continues unaffected. The limits are not
there to restrict you so much as to guarantee that someone else's problem never
becomes yours.

## The limits and what they do [#the-limits-and-what-they-do]

| Limit                      | Symptom when reached                                |
| -------------------------- | --------------------------------------------------- |
| **CPU**                    | The site slows down. Requests still complete        |
| **I/O**                    | The site slows down, especially anything disk-heavy |
| **Entry processes (EP)**   | **503 error** — requests are killed outright        |
| **Physical memory (PMEM)** | **503 error**, or the process is killed             |

The distinction matters when diagnosing. CPU and I/O limits degrade; EP and
memory limits break. A site that has become sluggish is hitting a different
limit from one returning 503s.

## Where to see it [#where-to-see-it]

**cPanel → Resource Usage** shows which limits were reached and when. When an
account hits a limit, a snapshot records which processes were responsible —
that snapshot is what tells you the cause rather than just the symptom.

## What to do about it [#what-to-do-about-it]

Almost always the answer is at application level, not the plan:

1. **Cache.** A cached page consumes almost nothing.
2. **Audit plugins.** Disable all, re-enable one at a time watching Resource
   Usage.
3. **Fix cron schedules.** Heavy jobs on short intervals are a frequent cause.
4. **Check for malware.** A compromised site consumes resources doing someone
   else's work — see
   [Scan your site for malware](/en/security-ssl/malware-scanner-how-to-scan-your-sites-for-malware).

If usage is genuinely legitimate, the limits can be raised. Open a ticket with
your Resource Usage figures.

## Related [#related]

* [What entry processes are](/en/performance/entry-processes-ep-what-is-an-entry-process)
* [Fix a 503 Resource Limit Reached error](/en/performance/understanding-and-resolving-the-503-error-resource-limit-reached)
* [You received a resource usage alert](/en/performance/i-have-received-an-email-about-lve-resource-usage)