Understanding CloudLinux Resource Usage in cPanel

If a website is temporarily slow, processes abort, or errors only occur under load, you should check the available hosting resources in addition to PHP errors and disk space.

CURIAWEB uses CloudLinux to isolate hosting accounts from one another and allocate resources in a controlled manner. In cPanel, under Metrics → Resource Usage understand whether your account has reached resource limits and which resources were particularly heavily used at a specific time.

In this guide, we will show you how to open the CloudLinux resource usage, correctly classify the most important metrics, and distinguish between a brief traffic spike and an actual resource issue.

Important: A high measurement or a single peak load does not automatically mean that something is wrong with your website. What matters is whether a limit is actually reached, how often that happens, and whether the timing coincides with a visible problem on the website.

What does CloudLinux do? #

On a shared hosting system, multiple hosting accounts use the same physical server infrastructure.

CloudLinux ensures, among other things, that the resources of individual accounts are isolated from one another. This prevents, for example, a heavily loaded website from consuming unlimited resources on the entire server.

For a single hosting account, various resources can be considered and limited separately.

Depending on the server configuration, this includes in particular:

• CPU performance
• physical memory
• Input/Output Performance
• simultaneous incoming processes
• Total number of processes

The CloudLinux display helps you identify, which resource was claimed at what time.

CloudLinux resources are not your storage space #

One of the most important distinctions is that between hosting storage and running system resources.

Area	Meaning
Storage space	Storage space for files, emails, databases, and other stored data
bandwidth	transmitted data
Physical Memory	RAM used by running processes
CPU	Processing power for running processes
I/O	Input/output data rate
Entry Processes	simultaneously processed incoming processes within the CloudLinux LVE context
Processes	Number of running processes of the account

If you want to know which files or emails are taking up your hosting storage, use instead Check disk space and bandwidth in cPanel.

1. Open Resource Usage in cPanel #

Log in to your CURIAWEB cPanel and open:

Metrics → Resource Usage

The CloudLinux interface provided there shows you information about the resource usage of your hosting account.

Depending on the current CloudLinux version and server configuration, the appearance and names of individual values may vary slightly.

2. Check the summary first #

Before analyzing individual charts, you should look at the summary or the current status.

CloudLinux can indicate there whether your account has reached resource limits within a considered time period.

This is much more informative for the diagnosis than simply noting that a chart once shows a high value.

Basic rule: Do not look for the highest peak in the chart first. First, check whether a limit was reached at all and at what time this happened.

3. Select the analysis period #

When dealing with sporadic issues, the considered time period is particularly important.

For example, if your website was slow or inaccessible yesterday at around 2:30 PM, you should examine the resource usage specifically for that exact time period.

A sensible diagnostic procedure is:

Identify website issue
        ↓
Note date and time
        ↓
Open resource utilization
        ↓
Select appropriate time period
        ↓
Compare limits and metrics

A resource event at a completely different time usually does not explain your current website issue.

Understanding CPU Usage #

The CPU provides computing power. PHP scripts, database operations, and other processes require CPU time to execute their tasks.

Increased CPU usage can be caused, for example, by:

• many simultaneous website visits
• computationally intensive PHP processes
• extensive database operations
• Imports and exports
• Backup or maintenance processes
• Cron jobs
• inefficient plugins or applications
• bot traffic

High CPU usage is initially just a metric. The decisive factor is whether the CPU limit applicable to the account is actually reached.

What happens when a CPU limit is reached? #

When an account fully utilizes its assigned CPU performance, CloudLinux can limit further CPU usage.

Simplified, this means:

Application requires more CPU power
        ↓
Account CPU limit is reached
        ↓
Further processing is throttled
        ↓
Processes may take longer

For visitors, this can manifest itself, for example, as a slower website.

Therefore, a CPU limit does not necessarily mean that a process is immediately terminated with a visible error message.

Short CPU spike or persistent issue? #

A short CPU spike can be completely normal for certain tasks.

For example, an import can require significantly more computing power for a short time than normal website operation.

A more critical pattern is like:

CPU limit regularly reached
→ Website slow at the same time
→ Same situation repeats itself
→ Cause is reproducible

Then you should investigate which process or application is causing the load.

Understand Physical Memory #

Physical Memory refers to the physical memory used by the processes of your hosting account within the CloudLinux environment.

This value is not the same as:

• your hosting storage space
• the size of your website
• the PHP-memory_limit

This is a particularly important distinction.

Distinguish between physical memory and PHP memory_limit #

The PHPmemory_limit limits the memory that a single PHP process may use according to its PHP configuration.

In contrast, the CloudLinux Physical Memory limit looks at the memory consumption of the hosting account's processes from a different level.

Simplified:

PHP memory_limit
→ PHP configuration of a PHP process

CloudLinux Physical Memory
→ Memory usage of the account processes within the LVE

A higher PHP-memory_limit therefore does not automatically increase the CloudLinux memory limit.

We explain how to manage PHP limits at Set PHP memory limit, upload size, and execution time.

Important: When CloudLinux reports a memory limit, you shouldn't simply increase the PHP memory limit. This can actually make a resource issue more apparent because individual PHP processes are allowed to consume more memory.

What can consume a lot of RAM? #

Increased memory consumption can be caused, for example, by multiple simultaneously running PHP processes, extensive applications, or particularly memory-intensive tasks.

Typical situations are:

• large imports
• Image processing
• extensive WordPress or WooCommerce processes
• multiple parallel PHP requests
• Cron jobs
• Backup or maintenance processes
• faulty or inefficient application code

Understand I/O #

I/O stands for Input/Output and simply describes the data rate at which processes can read or write data.

This affects file access, for example.

High I/O activity can occur, among other things, during the following tasks:

• large file operations
• Backups
• Extracting large archives
• extensive imports
• Cache generation
• certain data-intensive applications

What happens when an I/O limit is reached? #

If a process requires more I/O performance than is available for the account, data processing can be throttled accordingly.

This can cause file operations or dependent processes to take longer.

Therefore, an I/O limit is not the same thing as a full storage space.

Storage full
→ there is no space for additional data

I/O limit reached
→ the input/output data rate is limited

IOPS can be displayed separately #

Depending on the CloudLinux configuration, an additional value for IOPS displayed.

IOPS describes the number of input/output operations per second and is therefore not identical to the amount of data transferred per second.

Simplified:

I/O
→ how much data is transferred per unit of time

IOPS
→ how many individual input/output operations occur per unit of time

Therefore, many small file operations can produce a different resource profile than a few large file operations.

Understanding entry processes #

Entry Processes - often as EP – are among the CloudLinux values that are most frequently misunderstood.

They simply describe the number of incoming processes entering or being simultaneously processed within the CloudLinux LVE environment.

This may include dynamic web requests in particular.

Important: Entry processes do not match the number of your website visitors. A visitor is not automatically an entry process.

Why Visitors and Entry Processes Are Not the Same #

A visitor can trigger multiple requests one after another. At the same time, different requests can take vastly different amounts of time to process.

Therefore, for the EP limit, the Simultaneity of relevant processes crucial and not simply the number of visitors per day.

Therefore, a website with many fast, well-cached requests can behave differently than a website with few, but very slow, dynamic requests.

What happens when the entry process limit is reached? #

If too many corresponding processes have to be processed simultaneously and the EP limit is reached, additional requests cannot be processed normally.

In this context, visitors can, for example, encounter errors such as:

508 Resource Limit Is Reached

see.

We will cover the specific diagnosis and troubleshooting in the next article under Resource Limit Is Reached: Identify and Fix CloudLinux Limits.

Understand Number of Processes #

CloudLinux can additionally limit the total number of processes for an account. This value is often referred to as Number of Processes or rather NPROC referred to as.

This is not just about simultaneously incoming web requests.

Depending on the respective environment, different processes of the account can contribute to the process inventory.

That is why Entry Processes and Number of Processes are not the same.

Compare Entry Processes and Number of Processes #

Value	Simply put
Entry Processes (EP)	simultaneously occurring or processed incoming processes
Number of Processes (NPROC)	Total number of running processes of the account

Therefore, an account can have a process issue without EP and NPROC necessarily exhibiting the same behavior at the same time.

Faults are particularly important for diagnosis #

In the CloudLinux analysis, in addition to current or average values, so-called Faults or limit events be relevant.

A fault shows in simplified terms that a resource limit has been reached.

This is often more informative for the diagnosis than a chart whose line is merely close to the limit.

Practical Tip: If you want to know whether a resource limit was truly relevant, pay special attention to documented limit events and their timing.

100 % does not mean the same thing for every value #

Percentage displays must always be read in the context of the respective resource limit.

For example, a 100 % CPU reading in a hosting resource view does not automatically mean that the entire physical server is at 100 % capacity.

It can refer to the resource assigned to your account.

Therefore, do not use percentages as a statement about the overall server utilization.

Differentiate between account limit and server load #

When your hosting account reaches a CloudLinux limit, it does not automatically follow that the entire hosting server is overloaded.

CloudLinux serves to isolate the resources of individual accounts from each other.

Simplified:

Account reaches its own resource limit
≠
entire server is busy

This distinction is crucial when interpreting the values.

Averages can mask short peaks #

An average value over a longer period can look unremarkable, even though a short, sharp load peak occurred within that period.

If your website only had issues for a few minutes, you should therefore consider the most appropriate time frame possible and take limit events into account.

A single peak is not yet a diagnosis #

Assuming the CPU usage briefly spikes to a high value while:

• the website works normally
• no limits are documented
• no errors occur
• the value subsequently decreases again

That does not automatically require action.

A peak load can simply have been caused by a recently executed task.

Recurring limits are more relevant #

Much more interesting is a pattern like:

every day around 02:00 AM
→ CPU spikes significantly
→ I/O increases
→ limits are reached
→ website responds slowly at the same time

Such a recurring pattern suggests taking a closer look at the processes running at that time.

Compare cronjobs with resource events #

If resource issues occur regularly at the same time, also check scheduled cron jobs.

An import, export, backup, or synchronization process can lead to a recurring load pattern.

We explain how to investigate cron job issues at Cron job not working: Causes and solutions.

Multiple cron jobs at the same time #

When multiple resource-intensive cron jobs start at the exact same time, their demands can add up.

For example:

02:00 → Import
02:00 → Export
02:00 → Synchronization
02:00 → Maintenance process

If the respective applications are flexible in time, staggering the start times can be useful.

Do not change application-preset schedules without verification, however.

Backups can require resources #

Depending on the volume, backup and archiving processes can consume CPU, I/O, and other resources.

If a peak load occurs during a backup, the temporal connection is relevant for this reason.

However, that does not automatically mean that the backup is faulty.

Imports and exports can cause peak loads #

Large data imports and exports are typical examples of temporarily resource-intensive operations.

A WooCommerce product import, a large database operation, or the processing of many files can temporarily require significantly more resources than normal website operation.

WordPress plugins as a potential cause #

In WordPress, plugins can execute background tasks, database queries, or external connections.

If a resource issue begins immediately after installing or updating a plugin, this temporal correlation should be investigated.

This does not yet automatically prove the plugin is the cause.

You can find a systematic conflict diagnosis under Identify and resolve WordPress plugin and theme conflicts.

WooCommerce often requires more dynamic processing #

Online stores contain many areas that cannot simply be treated like static pages.

Shopping cart, checkout, customer account, orders, background tasks and various extensions can cause additional dynamic processing.

Therefore, a WooCommerce shop should not be compared with a simple information website based solely on the number of visitors.

Bots can consume resources #

Not only human visitors generate load.

Bots, crawlers, and automated scanners can send many requests to a website.

If unusual resource load occurs simultaneously with heavy traffic, access statistics or access logs may therefore also be relevant.

Many visitors do not automatically mean resource problems #

A high number of visitors alone says little about the required server resources.

Crucial factors include, among others:

• how many requests are made simultaneously
• how quickly PHP processes these
• how efficient database queries are
• what content can be cached
• which plugins or applications are involved

A well-optimized website can therefore handle significantly more inquiries than a technically inefficient website with a comparable application.

Caching can reduce dynamic load #

If content does not need to be completely regenerated by PHP and the database on every request, caching can significantly reduce dynamic server load.

CURIAWEB provides a corresponding tool in cPanel with AccelerateWP.

You can find more information at AccelerateWP in cPanel explained.

Caching does not solve every resource problem #

A cache helps primarily with requests that can be usefully cached.

For example, it does not automatically resolve:

• faulty cron jobs
• extremely complex backend processes
• badly programmed database operations
• certain WooCommerce background tasks
• memory leaks or faulty code

Therefore, do not activate additional cache systems indiscriminately if the actual cause is unknown.

Multiple cache plugins can be problematic #

More caching does not automatically mean more speed.

Multiple cache and optimization solutions working simultaneously can interfere with each other or create unnecessary complexity.

Therefore, use a controlled configuration that matches the hosting environment.

PHP version can affect resource usage #

PHP versions differ, among other things, in terms of performance and software compatibility.

An outdated PHP version or one that is unsuitable for the application can therefore also be indirectly relevant for resource analysis.

At CURIAWEB, you generally manage a domain's PHP version via the MultiPHP Manager.

Do not switch PHP just because a resource value is high. First, check your application's compatibility.

PHP Memory Limit is not a performance setting #

A common mistake when dealing with a slow website is simply the PHP-memory_limit to increase significantly.

The memory limit merely provides a PHP process with a maximum permitted memory framework.

It does not automatically make PHP faster and does not provide the hosting account with additional CPU performance.

Check error log in parallel #

If a website shows errors at the same time, you should also examine the error log in addition to the CloudLinux metrics.

Under Read cPanel Error Log and find website errors let's explain how you classify typical PHP and web server messages.

Resource issue or PHP error? #

Both problems can cause similar symptoms.

Observation	Important checkpoint
PHP Fatal Error	Error Log
Allowed memory size exhausted	PHP Memory Limit and Application
CloudLinux limit documented	Resource usage
Resource Limit Is Reached	CloudLinux Limits
Website occasionally slow	Compare timestamp with resources and logs
Storage full	Storage usage

Do not equate CPU limit with a slow database #

When an application requires a lot of CPU, an inefficient database query may be involved. However, the CPU value alone does not prove this.

Conversely, a slow application can be delayed by external APIs, file access, or other factors without the CPU constantly running at its limit.

The resource graphic shows you was is burdened – it does not automatically show what specific program code is the cause.

The CloudLinux display is not a process debugger #

CloudLinux helps you narrow down resource bottlenecks by time and resource type.

For example, the ad says:

CPU limit was reached at 2:32 PM

It does not automatically mean:

Plugin XYZ is to blame

For the actual root cause analysis, you need to combine the timestamp with website activities, cron jobs, logs, updates, or other technical information.

What happened immediately before the resource problem #

If the resource usage has only recently become noticeable, check changes such as:

• new plugin installed
• Plugin or theme updated
• new website imported
• Cron job set up
• Backup solution changed
• new marketing campaign launched
• Traffic has increased significantly
• WooCommerce extension activated
• PHP version changed

The temporal connection is an important clue, but not yet proof.

Targeted reproduction of the peak load after modification #

If a specific action might be responsible for the high load, you can observe the process closely—provided the action can be repeated safely.

For example:

Check resource usage
↓
Note time
↓
Execute affected action
↓
Check resource usage again

Do not execute payment, shipping, import, or other modifying processes multiple times if you do not know their behavior upon repetition.

Consider multiple websites in the same cPanel account #

When multiple domains or applications are operated within the same hosting account, they can share the account's resources.

High resource usage therefore does not necessarily have to come from the website where you first notice the problem.

Consider all applications and background processes of the account in question.

Old or forgotten installations can generate resources #

An inactive WordPress test installation can still:

• be called by bots
• Run WP-Cron
• Load plugins
• process automatic tasks

Therefore, if there are multiple installations in your hosting account, you should also consider older test systems.

Compare resource values after optimization #

Once you have found and fixed a specific cause, compare the resource usage under conditions that are as similar as possible.

Example:

Before:
CPU limit reached multiple times daily

Change:
fixed faulty background process

After:
no more CPU faults in the comparable period

This allows you to judge much better whether the measure actually helped.

Do not perform multiple optimizations at the same time #

If you simultaneously:

you change PHP
you change the cache
you deactivate plugins
you move cron jobs
you optimize the database

and the load subsequently decreases, you do not know which measure was responsible for it.

Therefore, proceed in a controlled and step-by-step manner with the diagnosis.

When is a resource limit actually relevant? #

A limit is particularly relevant when several factors come together:

• the limit is actually reached
• The event occurs repeatedly.
• the timing coincides with a website issue
• the behavior can be reproduced or assigned to a process

A single brief peak load without visible effects, on the other hand, should not be overestimated.

Typical resources and their significance #

Resource	Meaning	Inspect first in case of a limit
CPU	computing power	PHP processes, application, cron jobs, traffic
Physical Memory	Memory of the account processes	parallel/memory-intensive processes
I/O	Data rate during file operations	Backups, Archives, Imports, File Operations
IOPS	Number of I/O operations	many small file operations
Entry Processes	simultaneously occurring/processed processes	simultaneous dynamic requests
Number of Processes	Total number of running processes	Background processes, parallel tasks

Systematically analyze CloudLinux values #

1. Note the date and time of the website issue.
2. Open Metrics → Resource Usage.
3. Select a suitable time period.
4. Check if CloudLinux reports a reached resource limit.
5. Identify the affected resource.
6. Check faults or limit events.
7. Compare their timing with the website issue.
8. Check cron jobs, imports, backups, and other activities at this time.
9. Also check the error log for website errors.
10. Then specifically change only one possible cause.
11. Compare the resource usage again after the change.

What you should not do with high resource values #

Avoid, in particular, the following hasty decisions:

• Globally increase PHP memory limit drastically
• Change PHP version without compatibility check
• disable multiple plugins at the same time
• Delete files on suspicion
• install multiple caching plugins
• Remove cron jobs randomly
• interpret a single peak as permanent overload

Practical Tip: Resource analysis is a temporal diagnosis. The question is not only „Which value is high?“, but above all „Which limit was reached when, and what was happening at that exact moment?“

If the website is slow, but no limits are reached #

If CloudLinux shows no relevant limit events, you should not continue trying to force a resource issue.

A slow website can have numerous other causes.

This includes, for example:

• slow database queries
• external APIs
• large or poorly optimized images
• JavaScript in the browser
• Plugins or themes
• missing or inadequate caching
• DNS or network dependencies

CloudLinux is simply a potential cause that you were already able to narrow down better using the metrics.

If the website is not reachable at all #

When a website is completely unreachable, you should not rely exclusively on the CloudLinux display.

DNS, domain configuration, SSL, web server, PHP, application, and other layers can also be relevant.

We cover the complete diagnosis under Website unreachable: systematically diagnosing hosting errors.

When should you contact CURIAWEB support? #

If your hosting account regularly reaches resource limits and you cannot clearly identify the causing application or task, document the problem as precisely as possible.

Particularly helpful are:

• affected domain or application
• Date and time of the problem
• affected resource
• visible limit events or faults
• visible behavior of the website
• whether the problem occurs regularly or only once
• recent changes
• cron jobs, imports, or other tasks running at this time
• possibly relevant error log entries

The more precisely the time is known, the easier it is to associate a resource event with a specific activity.

Summary #

Under Metrics → Resource Usage can you see in the CURIAWEB cPanel how your hosting account uses the resources managed by CloudLinux.

Key metrics include CPU, physical memory, I/O, optionally IOPS, entry processes, and the total number of processes.

These values must not be confused with storage space or bandwidth. Likewise, CloudLinux Physical Memory is not the same as PHP-memory_limit.

For the diagnosis, not only high measured values are important. The decisive factor is in particular whether a resource limit was actually reached, when this happened, and whether the timing coincides with a visible website problem.

Entry Processes do not correspond to the number of your visitors. Even a CPU value of 100 % in the resource display does not automatically mean that the entire hosting server is fully utilized.

Brief load spikes can be normal during imports, backups, cron jobs, or other tasks. Recurring limit events combined with a slow or faulty website, on the other hand, should be investigated more closely.

Compare resource events with cron jobs, updates, traffic, error logs, and other activities at the same time. Then, change only one possible cause at a time and check whether the behavior improves.

The most important rule is: Do not look for the highest value, but connect the actual limit event with the timestamp and causing activity.