cPanel Resource Graphs: Units and Fault Counters

Read a cPanel resource graph by identifying its quantity, unit and observation interval first. CPU percentage, physical memory, disk throughput and LVE entries use different scales; a fault count is not automatically a failed HTTP request count. This reference explains the fields before they are used to compare a shared plan with a VPS or dedicated server. Its numerical tables are explicitly hypothetical, not screenshots, DCHost plan allocations or customer measurements.

Measurement Scope: cPanel Interface and CloudLinux LVE

CloudLinux LVE applies account-level resource controls where installed. cPanel provides the interface for the relevant integration; the presence of cPanel alone does not establish which LVE version, features or limits apply. Several sites and background jobs can share one account allocation.

Record the account, web server, PHP handler, LVE version and actual limits. Controls can reduce one account’s effect on others, but different limits behave differently: CPU/IO throttling, memory reclamation or process termination, and entry/process refusal are distinct outcomes. Resource controls do not promise uninterrupted service or exclusive physical cores.

The detailed cPanel resource-limit overview is a related overview. Here the primary task is to interpret units, averages, maxima and fault fields without treating them as a complete diagnosis.

Where to See Your Limits and Usage in cPanel

If the CloudLinux Resource Usage client plugin is enabled, open the available usage view. Names, metrics and history depend on the integration; ask the provider for missing fields. Look for:

• Account scope, time range, time zone and aggregation interval
• Usage, actual limit, available average/maximum and resource-specific faults
• The chart legend and CPU normalization setting
• Any snapshot and its capture time; capture can lag the fault

A generic 100% rule is unsuitable for every metric. CPU can use a per-core or normalized scale; memory, IO and entry counts use their own units. Read the legend rather than inferring meaning from color. Missing data, an unavailable fault field and an actual zero fault count are different states. A brief spike can still affect a critical operation.

CPU / SPEED: Per-Core Scale and Normalized Percentage

Modern CloudLinux SPEED is relative to one core’s capacity. 100% corresponds to one core, 150% to one and a half; this is a limit, not an exclusive physical-core assignment. With a raw SPEED limit of 200%, usage of 100% is 50% of that allowance. A normalized display may show the same usage as 50% and reserve 100% for the full plan limit.

The CPU line does not name the responsible application path. Correlate it with work such as:

• Dynamic PHP pages, AJAX or API execution
• Cron, image conversion, compression or imports
• Verified cache HIT/MISS behavior for eligible content
• Separate database CPU measurements and the configured MySQL Governor/LVE attribution

CPU limiting slows work; it is not a direct rule for HTTP 508. Under Apache’s request-entry model, longer requests may contribute to a separate EP fault. Compare the actual limit, relevant fault and request log in the same interval before assigning a cause.

What a CPU Plateau Does and Does Not Establish

These are investigation paths, not observed DCHost cases:

• A dynamic route may consume CPU, wait on a query or wait on an external service; duration alone is not CPU time.
• A background job can overlap foreground requests; record its real start/end and processed volume.
• Search and report costs need actual query plans and application measurements.
• A login-request spike can include legitimate clients or abuse; route, timing and outcomes need examination.

A plateau at a confirmed CPU limit supports investigating limiting during that interval. It does not prove which plugin caused it, whether the whole server is saturated, or whether a VPS will provide exclusive CPU. Those require additional evidence and explicit plan terms.

Annotate the CPU Graph with Application Evidence

Record changes and outcomes instead of assuming a fixed improvement percentage:

• Public-page cache: Verify eligible HITs, invalidation and exclusion of cart, checkout, account and private/session responses. LiteSpeed page caching requires an enabled compatible LSCache service or appropriate QUIC.cloud service.
• PHP version: Use an application-compatible branch with security support; compare resource use for the same completed work.
• Queries: Measure plans, duration and result correctness. The MySQL query optimization guide provides implementation context.
• Scheduled work: Confirm the replacement scheduler runs required tasks before disabling page-triggered WP-Cron; cron still consumes resources.
• Filtering: Compare origin work before/after and test legitimate users, callbacks and API clients.

Carry the confirmed CPU scale, allocation, workload and user impact into a plan comparison. Required capacity and application efficiency can be addressed together; a chart does not require finishing every tuning idea before restoring a failing critical operation.

IO and IOPS: Data Rate, Operation Rate and Accounting Scope

CloudLinux IO limits combined disk read/write throughput, documented in KB/s and sometimes displayed in larger units. IOPS limits the number of read/write operations per second. Neither is disk capacity, network bandwidth or the storage device’s maximum performance. Confirm the source unit before substituting KB/KiB or MB/MiB labels.

When correlating disk activity, keep these boundaries visible:

• CloudLinux disk IO excludes disk-cache accesses.
• Backups, logs, uploads and conversion may involve real disk access, cache hits and temporary files.
• Database and LVE IO charts can differ; MySQL Governor mode and attribution must be known.
• File-cache refreshes generate their own work; fewer retained files do not necessarily mean a lower IO rate.

At the IO limit, processes are throttled rather than killed; at the IOPS limit, operations wait until the current second expires. An account IO plateau does not establish a full disk or device saturation. Server-wide iowait and the account’s IO limit are different measurements; do not infer one from the other.

Add Task Timing to the Disk Graph

Use the following as hypotheses to check against logs:

• Backup start/end, archive creation and overlapping work
• Actual log write rate and processing, not only final log-file size
• Image upload/conversion timing and repeated regeneration
• Cache fill/purge cycles and their read/write cost

If task scheduling changes, preserve the evidence needed to interpret a lower graph:

• Verify required backup coverage, deadlines and an isolated restore. An offsite destination can still require local reads, compression and temporary archives.
• Retain required security/audit records while limiting unnecessary verbose output at its source.
• Compare image output quality and client support as well as conversion load.
• Use supported expiry for cache/session files after checking active use and dependencies; do not delete them blindly.

A storage label such as NVMe does not remove an account IO limit. The NVMe VPS hosting guide discusses device and server metrics; keep that layer distinct from per-account limits when comparing plans.

Physical Memory Limits: Account RAM vs PHP memory_limit

Physical Memory and PHP’s memory_limit describe separate scopes:

• PMEM: Physical memory used by processes inside LVE plus shared memory; disk page-cache inclusion in displayed statistics depends on version/settings. It is not automatically the entire database server’s RAM.
• PHP memory_limit: Script allocation limit, separate from aggregate account physical memory and not a preallocated amount per worker or a strict operating-system RSS cap.

A PHP memory_limit such as 512M is a configuration example, not a memory recommendation. Multiplying it by worker count does not give exact PMEM: actual allocation, shared pages, handler behavior and other account processes matter. Raising the PHP limit does not raise the account allowance.

What Happens When You Hit the Physical Memory Limit?

Under PMEM pressure CloudLinux first reclaims eligible disk cache. If that is insufficient, it can kill some processes in LVE and increment fPMEM. High usage alone does not prove that a process was killed. Distinguish these records:

• A PMEM fault and possible 500/503 outcome
• PHP’s own “Allowed memory size exhausted” error
• A separate NPROC failure to create a process
• An application/proxy failure with no established resource cause

Record the actual memory workload and concurrent work:

• Peak script allocation and account PMEM, rather than only configured memory_limit
• Large datasets, imports or reports with measured allocation
• Other tasks sharing the account during the same window; EP is not a worker count

Use measured requirements when reviewing PHP settings. The PHP memory and execution-time settings guide explains the separate configuration choices; a universally suitable memory value cannot be inferred from a site category.

If necessary work repeatedly encounters a confirmed PMEM limit, document the capacity gap and operational needs. The VPS memory and OOM guide covers server-level memory behavior; those measurements are not interchangeable with a shared account’s LVE graph.

EP and NPROC: Entries Versus Processes and Threads

EP counts entries into LVE, not every process created inside it. Apache mod_hostinglimits commonly counts dynamic CGI/PHP request entry, and integrated SSH/cron activity can count too. EP is not visitors, all connections or PHP workers. LiteSpeed differs: a workgroup lsphp master can fork children without increasing EP for every child/request.

For a hypothetical Apache example, assume an EP limit of 20 and 20 entries currently occupied. If another dynamic request cannot enter LVE, mod_hostinglimits can return 508; an automatic waiting queue is not implied. The value 20 is an illustration, not a recommended allocation or visitor capacity. NPROC instead limits all processes and threads inside LVE; at that limit new processes cannot be created and 500/503 may result.

Inode usage is another separate quantity: it concerns filesystem objects, including files and directories, rather than disk bytes or operations per second. Confirm quota scope with the provider. It is not an EP/NPROC fault or necessarily presented with the same historical statistics.

Read Entry Counts in the Actual Handler Context

Under Apache’s entry model, overlapping long requests can occupy entries longer. Investigate these paths with the actual handler and counters:

• A slow external API call inside your PHP code (payment provider, shipping calculator, remote CRM).
• Complex, uncached pages that hit the database heavily and take several seconds per request.
• Dozens of concurrent AJAX calls from a single front-end page.
• Search bots crawling many dynamic URLs at once.

The paths above are possible explanations, not measurements. A verified public-page cache may avoid dynamic work, but personalized responses must remain separate. Apache and LiteSpeed EP counts need not move identically under the same load, and worker/pool limits are separate controls.

Evidence to Attach to an EP Observation

Keep the following alongside the graph:

• Actual web server, PHP handler, EP/NPROC limits and fault fields
• Dynamic request duration, relevant route and external wait
• Cache location, verified HIT/MISS and private-response exclusions
• Rate-limit/WAF outcomes for legitimate clients; robots.txt is a voluntary crawler instruction and does not enforce throttling

Match the incident time with access logs and available snapshots. The guide to diagnosing CPU, IO and MySQL slowdowns shows how to investigate time-specific slowdowns; EP occupancy alone does not identify the failing URL.

Read Average, Maximum, Limit and Fault Together

Use each quantity for its own question. The following interpretations need additional logs:

• CPU near its known limit: Investigate CPU limiting and application work; it does not identify a particular query or plugin.
• IO near its limit: Investigate account disk throttling; do not infer device saturation or a specific task.
• PMEM near its limit: Check accounting settings and fPMEM; the line alone does not establish process termination.
• EP near its limit: Check actual entry refusal, handler and overlapping work; low CPU does not rule out external waits or a separate NPROC/worker constraint.

Select the same incident window, time zone and aggregation interval for every record. A long-period average can hide brief peaks; compare averages with averages and available maxima with the same kind of maximum. A short spike can still affect checkout or another critical operation.

Faults describe resource-limit violations for the relevant field and period. They are not a universal count of failed requests or affected users. A PMEM fault is different from EP refusal, and missing fault data is not zero. No daily threshold makes a fault count automatically acceptable; correlate it with the actual operation and error log. Snapshots may be delayed and are not an exact replay of the failure.

Hypothetical Reading Table: One Five-Minute Interval

This is not a real dashboard or measurement. It assumes raw per-core SPEED, memory displayed in MiB and disk throughput in MB/s for the same five-minute window. A maximum is included only as an assumed available field; interfaces vary. “Not supplied” does not mean zero.

The CPU average is 30% of its allowance and the maximum is 100%: 60÷200 and 200÷200. EP averages 5 but reaches 20; that does not mean 20 visitors. Do not add two PMEM and three EP faults and call them five failed customer requests. Match event times, handler and user outcomes first. The table does not identify a particular plugin, backup job or attack.

Turn the Graph into an Evidence Record

Record the following before making a diagnosis or capacity recommendation:

1. Account, sites sharing it, CloudLinux version, web server and PHP handler
2. Metric unit, CPU scale, configured limit, interval and time zone
3. Average, available maximum, fault type/count and missing fields
4. Matching route/job, completed work, latency and errors; redact credentials and personal data

If necessary user operations are failing, mitigation and deeper investigation can proceed together. A high graph does not establish the right service category, while a low average does not clear every hosting dependency.

When comparing options, retain the same workload evidence:

• Larger shared plan: Confirm which allocation or permission increases and whether it addresses the observed constraint.
• VPS: Check CPU sharing, memory, disk and network terms plus management duties; exclusive vCPU is not automatic.
• Dedicated server or colocation: Document capacity, operations and recovery responsibilities; these still have physical and configured limits.

For the separate symptom-to-change workflow, use the Resource Limit Reached diagnosis and fix guide. It connects the evidence record to a targeted application or capacity change and a comparable outcome check.

Questions the Resource Graph Cannot Answer Alone

Several sites sharing one allocation can affect each other. Separating a store, database or background workload is an architectural option only after its dependencies, required capacity and operational cost are understood. Graph height alone does not prove that a separate server is the right answer.

Visible headroom in LVE does not rule out DNS, network, storage latency, database limits, worker configuration or external services. The graph covers the stated metric and interval; it does not certify the entire request path.

Ask the provider to explain normalization, units, aggregation, missing data, PMEM cache accounting, database/LVE attribution and snapshot delay. Correlate those answers with HTTP outcomes and application logs; do not treat unverified provider experience as measurement evidence.

Keep Units and Evidence Boundaries in the Final Record

SPEED describes processor capacity usage, IO/IOPS different disk rates, PMEM physical-memory accounting, EP LVE entries and NPROC processes/threads. A chart does not directly state visitor capacity, the responsible plugin or the required product. Units, interval, limit and fault type must travel with every interpretation.

Leave an actionable record of what was observed, what remains unknown and which log could resolve it. The cPanel resource-limit overview provides further context. Use the diagnosis guide when moving from the measured symptom to a change, and verify required operations as well as resource graphs afterward.