Understanding and Checking CloudLinux LVE Limits in Shared Hosting

What Limits an LVE in Shared Hosting

With shared hosting, multiple customers share a server's resources. CloudLinux can monitor the usage of a customer account with a Lightweight Virtualized Environment, or LVE for short. The provider sets the limits. These limits are intended to prevent an account from using unlimited resources; conversely, your own website may also reach these limits.

A limit describes an upper bound and does not automatically constitute a guaranteed service. For example, a CPU limit does not mean that you have exclusive use of a processor core or that a specific response time is guaranteed. How fast an application runs also depends on its task, the hardware, and other components.

An LVE doesn't turn your hosting package into your own server either. The provider continues to operate the shared environment and determines its configuration. As a customer, you can only verify the applicable settings and their consequences to the extent that your plan and the hosting control panel provide the relevant information.

This should be distinguished from CageFS: This refers to the isolation of the file system view, while LVE limits restrict resource usage. Both features can complement each other, but they are not the same. The provider can confirm which components are actually active in your plan.

You can find a more in-depth explanation of the components in the article on Process Isolation with CloudLinux SecureLVE. However, the configuration of your own package is crucial for specific troubleshooting: The interface and level of detail in the resource display may vary depending on the panel and activation settings.

Who are these limits for?

What matters is not only the amount of a limit, but also its Scope of application. For example, if you run a blog and a store under the same hosting account, both can draw on the same resource budget in an account-level configuration. An import in the store can then use up capacity that the blog also needs at the same time.

That doesn't mean that every slow page is caused by another project in the account. However, it does explain why, when a critical event occurs, you shouldn't just look at the domain that's currently affected. Scheduled tasks and other websites in the same account may also be relevant during the period in question.

CloudLinux documents with Isolates It also offers the option to set limits at the website level. Whether this feature is used and how it is configured in a particular plan cannot be determined from the term “CloudLinux” alone. Therefore, even a separate analysis does not replace a review of the specific plan terms and conditions.

Before comparing plans, ask the provider as specific a question as possible: Do SPEED, PMEM, IO, IOPS, EP, and NPROC apply per hosting account or per website? If multiple projects share a budget, it’s also important to know which domains and tasks are assigned to that budget. This way, you’ll avoid accidentally allocating a listed value to each individual website.

If the panel displays only a single aggregate statistic, this will initially help narrow down the time frame, but it may not necessarily help identify a specific application. In that case, please contact Support to find out what breakdowns are available and whether the load can be assigned to a specific project or task.

Distinguishing Between CPU, Memory, and Access Limits

The various shared hosting limits restrict different types of activity. SPEED refers to the CPU budget: If it is exhausted, computationally intensive processes are throttled and requests may take longer to process. A CPU limit in hosting is therefore only one possible explanation for slow pages; it is not synonymous with all LVE limits.

PMEM limits the LVE's physical memory. When memory is in short supply, cache can be released first; if that is not enough, processes may be terminated. This should be distinguished from the obsolete VMEM value for virtual memory. Similarly, the PHP-memory_limit should not be equated with the LVE's entire PMEM budget.

When it comes to file access, IO and IOPS measure different things: IO refers to data throughput, while IOPS refers to the number of read and write operations per second. Therefore, many small files can impose a different limit than a few large files. IO does not refer to the speed of your Internet connection in this context.

EP counts entries into the LVE and is not a general limit on the number of concurrent visitors. How entries are counted depends, among other things, on the web server and the process model. NPROC In contrast, it limits the number of processes and threads. Once this limit is reached, no additional processes can be created temporarily; EP and NPROC are therefore not interchangeable.

Storage space and inodes are related but separate plan specifications. A full file quota or an exhausted inode limit does not automatically indicate a CPU, PMEM, or EP issue. Which of these values you see in the control panel depends on the provider and the interface they offer.

An Overview of LVE Limits and Their Consequences

Not all LVE limits work the same way: Some slow down ongoing work, while others prevent new processes from starting or may terminate existing processes. The table helps you match a displayed resource with its behavior and an appropriate audit trail. Your provider determines the specific threshold values.

At PMEM Limit It's not just the memory used by individual application processes that counts. Shared memory and the file cache may also be included; whether the cache is counted depends on the configuration. When processes are terminated, HTTP errors are possible, but they are not necessarily the visible result.

The two file access limits describe different quantities: IO limits data throughput, while IOPS limits the number of operations. Many small files can therefore place a heavy load on IOPS, whereas large files can generate high throughput. Here, IO does not refer to network bandwidth; according to CloudLinux, accesses from the file cache do not count toward the IO limit.

Calculate the CPU limit using an example

Suppose your package had a SPEED Limit of 150 percent. Since 100 percent is mathematically equivalent to one processor core, this results in a CPU budget equivalent to one and a half cores. This is an illustrative calculation, not a measurement. The actual value of your package may differ; the provider’s specifications are authoritative.

This example describes an upper limit on usable CPU time, not a reservation of an exclusive core. Nor does it mean that every single process can use one and a half cores at the same time. How the budget is distributed among running jobs depends, among other things, on how many processes actually require computing time in parallel.

A 150 percent figure does not imply either a guaranteed response time or a specific number of concurrent visitors that can be served. A simple request may require little computational effort, whereas a dynamic request may require significantly more. In addition, there may be wait times for file access or database operations, which a higher CPU budget does not automatically eliminate.

Even identical percentage values on different servers do not constitute a direct speed comparison: processor cores can vary in performance. When evaluating your CPU limit, it is therefore more important to determine whether usage repeatedly reaches the limit during a specific issue and whether corresponding threshold events are visible. Even then, you should investigate other possible causes.

How to Read Resource Reports Correctly

If your provider has enabled a resource view, start by narrowing down the incident as precisely as possible. Note the domain, date, time, and time zone, as well as the displayed HTTP status, if applicable. Also describe what was slow or failed. Without this information, it’s difficult to attribute a spike in the statistics to a specific problem.

Next, select the same time period in the display and compare the usage, set limit, and any displayed values for CPU, PMEM, IO, IOPS, EP, and NPROC. Faults. Not every interface displays all values in the same way. If you're missing any statistics or it's unclear which account they refer to, check with the provider.

Pay attention to the Temporal resolution: A low hourly average can mask a brief spike during which a limit was reached. If available, select a shorter time period or a more detailed display. Compare the spike with the recorded error time, rather than concluding—based solely on a daily or hourly average—that there was no bottleneck.

Faults indicate boundary events, but they do not directly represent the number of affected visitors or failed page views. A fault occurring at the right time is an indication, but not yet conclusive proof of the cause. Therefore, also check whether an import, a backup, a scheduled task, or a change to the application took place at the same time.

The interface and its functions depend on the panel and the activation status; therefore, there is no universal menu path. For technical background information on administration, see the article on CloudLinux LVE Manager and Resource Management Additional information. However, certain administrative configuration steps require the appropriate permissions and are not automatically available for your customer account.

Classifying Slow Pages and Errors

If your CMS is slow when editing or loading dynamic pages, first compare the affected time period with the CPU monitor. If usage repeatedly reaches the SPEED limit and corresponding faults are visible, a CPU throttling plausible. The temporal coincidence makes it a clue, but does not yet prove what caused the load.

For example, check whether any scheduled tasks are running at the same time or whether a change to extensions coincides with the problem. Database operations, network issues, or a slow-responding external interface can also cause pages to load slowly. High CPU usage alone therefore does not necessarily mean that the wrong plan was chosen, nor does it necessarily mean that a specific extension is to blame.

If errors occur when multiple dynamic requests arrive simultaneously, a concurrent EP Fault help. Long-running requests keep connections occupied for longer; at the same time, a single visitor can trigger multiple requests. EP is therefore not a visitor count. In Apache, an HTTP 508 error is a possible consequence of exceeding the EP limit, but the status code alone does not confirm the cause.

If the display shows PMEM faults during an import, the LVE memory limit may be the cause. In addition to the import, other PHP processes running simultaneously may be consuming memory; without the appropriate process data, it remains unclear which task was the deciding factor. An HTTP 500 or 503 error can also have other causes and is not, in and of itself, proof of insufficient memory.

The PHP value memory_limit This alone does not answer the question: It does not describe the total memory usage of all tasks in the LVE. Therefore, compare the import time with PMEM usage and faults, and note which other tasks were running in parallel before you change a setting or the tariff.

Check the background load and involve support

If a backup or file import is running slowly, consider IO and IOPS Separately. IO refers to the data throughput during hard drive access, while IOPS refers to the number of read and write operations per second. Many small files can therefore impose a different limit than the transfer of a few large files; IO is not the same as Internet bandwidth.

A backup can use both CPU and memory at the same time. Therefore, in addition to IO and IOPS, check SPEED and PMEM for the same time period instead of determining the cause based solely on duration. According to CloudLinux, accesses served from the file cache do not count toward the IO limit; thus, the displayed IO usage does not reflect every file access equally.

If a scheduled task can be rescheduled, compare its regular execution during a less busy period with a similar period in the past. When doing so, take into account the scope and any concurrent tasks: a smaller import is not a direct comparison to a full backup. Additional production stress tests or file deletions are not necessary for this assessment.

The Database load may play a role, even if the displayed web CPU usage is low. Its assignment to the account and any separate MySQL limits depend on the configuration. Ask your provider which database metrics you can view in the control panel and whether database activity is counted toward the LVE or subject to separate limits.

When submitting a support request, please include the domain, the time (with time zone), the observed HTTP status, and the affected process. Also include any limits, usage metrics, and faults visible during the same time period, as well as any known imports or backups. Please provide the assignment of threshold events and, if available, an analysis of process snapshots; this will allow us to investigate the issue more thoroughly.

Optimize, upgrade, or switch servers?

Start with the Optimization an identified task, if its resource requirements can be reduced in a verifiable manner. Check cache settings, extensions, and background jobs scheduled to run in parallel, for example. Then compare similar time periods, paying attention to both user issues and the affected resource metrics. Making a single change at a time makes it easier to identify what has actually changed.

An upgrade is an option when recurring, sustained peaks reach their allocated limits despite adequate optimization. First, ask for the specific values for SPEED, PMEM, IO, IOPS, EP, and NPROC. Don’t just compare package names: A higher CPU limit will not resolve an independently existing EP limit or a shortage of LVE memory.

To the Rate Comparison This also applies to the scope of service. Let the provider know how many websites your account contains, and ask whether they share a common resource budget or if there are limits per website. CloudLinux offers a solution for the latter with "Isolates"; however, the product name alone does not indicate that your plan uses this feature.

A VPS or managed server can offer more flexibility, but it’s not an automatic solution for every slow website. The key factors are the available resources, the actual load, and the operating model: With a VPS, you’ll need to clarify, in particular, which administrative tasks you’ll handle yourself; with a managed server, you’ll need to clarify which tasks the provider will handle.

If the cause remains unclear, it makes more sense to follow up with the collected timestamps and fault codes than to make a change based on suspicion. Even below an LVE limit, the application, network, or database can slow things down. Before making a decision, confirm which statistics and support are available in the respective offering.