Turkey (Turkish)
Germany (German)
Worldwide (English)
EPSimultaneous web login processes
Halkali merkez neighborhood fatih st ozgur apt no 46 , Kucukcekmece , Istanbul , 34303 , TR
508 error, indicates that the CloudLinux LVE layer of the cPanel account has reached one of the CPU, physical memory, Entry Processes, NPROC, IO, or IOPS limits. This guide finds which limit was reached and only resolves the real load cause instead of increasing the limit.
508 Resource Limit Is Reached
The website is temporarily unable to service your request
CloudLinux LVE fault detected
EPf: 24 PMf: 3 NprocF: 0CloudLinux runs each hosting account in an isolated resource area called LVE. When the account exceeds the defined limit, requests may be slowed down or a 508 page may be displayed to protect other customers.
Entry Processes, simultaneous dynamic requests entering through Apache or LiteSpeed account, refer to concurrent dynamic requests entering through the account. Slow PHP code or bot traffic can cause each request to remain open for a long time and exceed the EP limit.
PMEM is the account's processes' physical memory. While PHP memory_limit restricts a single PHP request, CloudLinux PMEM encompasses the total physical memory used by all processes on the same account.
NPROC can cover web requests in addition to cron, SSH, PHP, Node.js, and other processes. In a healthy configuration, the NPROC value should be high enough from EP; only equating the two limits can lead to premature process termination.
CPU, IO, and IOPS limits often slow down requests instead of terminating them directly. Slowed down requests can secondarily cause EP or NPROC fault.
Increasing the limit may be necessary; however, abnormal bot traffic, wp-cron storm, poorly written query or malware present, increasing the limit only allows the problem to consume more resources.
Search for the phrase you see in the email, browser, or SSH log. Each card includes meaning, probable cause, and safe initial action.
Meaning: Your account has reached one of the resource limits defined by CloudLinux.
Possible cause: EP, PMEM, NPROC, CPU, IO, or IOPS consumption.
Meaning: Simultaneous dynamic web request count has reached EP limit
Possible cause: Bot traffic, slow PHP, remote API, database wait or low EP limit
Meaning: Your account's total physical RAM usage has reached the PMEM limit.
Possible cause: Too many PHP processes, high memory_limit, extension leak, or large import.
Meaning: Your account's total process/thread count has reached the NPROC limit.
Possible cause: Cron proliferation, stuck PHP processes, shell/node processes, or low NPROC.
Meaning: Account is continuously consuming the defined CPU capacity.
Possible cause: Heavy PHP, bad query, crawler bot, cron or malware.
Meaning: Indicates that your account has reached its second-level disk read/write bandwidth limit.
Possible cause: Backup for large imports, cache writes, email operations, or heavy database file access.
Meaning: The disk operation per second limit has been reached.
Possible cause: Many small files, session/cache, antivirus scans or email queues.
Meaning: Old or custom setups may show virtual memory limit reached.
Possible cause: Processes using high virtual address space or old LVE settings.
Meaning: CPU/IO throttling is occurring but may not produce a fault threshold.
Possible cause: Account is working for a long time in the limit or there is a database/global server delay.
Meaning: Periodic traffic or scheduled task resources are consuming the same time frame.
Possible cause: wp-cron, backup, XML import, bot wave or campaign traffic.
No records matching this expression were found.
Commands are for root access. Collect only status and logs first; Do not change the permanent setting without seeing the reason.
lveinfo --period=1h --by-fault=any --display-username --show-allIt collectively shows which user has which limit fault.
lveinfo --user=USERNAME --period=24h --display-username --show-allUSERNAME account's last 24 hours resource usage and fault values are displayed.
lvetopMonitors CPU, memory, EP, process, and IO usage in real-time.
lvectl list-user USERNAME
cloudlinux-limits get --username USERNAME 2>/dev/nullShows the current LVE limits applied to your account.
ps -u USERNAME -o pid,ppid,%cpu,%mem,rss,etime,cmd --sort=-%cpu | head -n 40Lists user processes based on CPU, RAM, and long running time.
awk '{print $1}' /usr/local/apache/domlogs/ALANADI | sort | uniq -c | sort -nr | head
awk '{print $7}' /usr/local/apache/domlogs/ALANADI | sort | uniq -c | sort -nr | headFinds the IP addresses and URLs with the most requests.
crontab -u USERNAME -l
journalctl --since '2 hours ago' | grep -Ei 'CROND.*USERNAME' | tail -n 100Identifies cron jobs running during peak hours.
ps -u USERNAME -f
find /home/USERNAME/public_html -type f -mtime -2 -name '*.php' -ls 2>/dev/null | head -n 100Shows unexpected processes and recently changed PHP files.
The correct solution is not to randomly increase the limit by looking at the error page; it is to match the fault type, time and load with the URL or process.
Find which of the EPf, PMf, NprocF, CPUf or IOf columns is increasing. Date-time information is required for subsequent log matching.
lveinfo --user=USERNAME --period=24h --display-username --show-allFind the process, IP, and URL that created the load while the error continued with iis, ps, and domain access logs.
lvetop
ps -u USERNAME -o pid,ppid,%cpu,%mem,rss,etime,cmd --sort=-%cpu | headOptimize or schedule reasons such as WordPress cron, security scan, XML import, slow query, remote API, or intense bot URL.
wp cron event list --path=/home/USERNAME/public_html 2>/dev/null | headBlock repeated bot or attack requests with Cloudflare, WAF, ModSecurity or application rate limit. Do not affect the real visitor with a bulk IP block.
awk '{print $1}' /usr/local/apache/domlogs/ALANADI | sort | uniq -c | sort -nr | headAfter optimization, if the actual workload exceeds the current package, increase limits based on RAM and server capacity, either at the package or user level.
lvectl set-user USERNAME --speed=200% --pmem=2G --nproc=150 --maxEntryProcs=40 --save-all-parametersFollow that new fault is not occurring, the source curve is normalizing and the 508 page is not repeating.
lveinfo --user=USERNAME --period=24h --display-username --show-allRequests may be waiting for a resource without consuming CPU. Remote API, database lock, long HTTP request, or PHP session lock are checked.
ps -u USERNAME -o pid,stat,wchan:24,etime,cmd | head -n 50Is it a single heavy process or multiple small PHP processes consuming memory? Note that memory_limit and LVE PMEM are not the same limit.
ps -u USERNAME -o pid,rss,%mem,etime,cmd --sort=-rss | head -n 30Cron, shell, Node.js, or stuck PHP processes can fill the total count. The NPROC value should be reasonably high compared to EP.
ps -u USERNAME --no-headers | wc -l
pstree -ap USERNAME | head -n 80Determine the most intense IP and URL addresses and apply targeted rate limiting on Cloudflare/WAF. Do not mistakenly block verified search engines like Googlebot.
grep "$(date '+%d/%b/%Y')" /usr/local/apache/domlogs/ALANADI | awk '{print $1,$7}' | sort | uniq -c | sort -nr | headBreak up bulk product process into smaller chunks, use real cron, do not run WP-Cron on every visit, and optimize query/cache structure.
wp cron event list --path=/home/USERNAME/public_html --fields=hook,next_run_gmt,recurrence | head -n 50indicates that the cPanel account has accessed at least one of the CPU, PMEM, EP, NPROC, IO, or IOPS resources defined by CloudLinux.
The Faults area in WHM LVE Manager or the EPf, PMf, NprocF, and other fault columns in the lveinfo output via SSH are checked.
The number of dynamic requests to the web server account at the same time from the web server is.
No. PHP's memory_limit is the upper limit for the physical memory that a single PHP process can use. CloudLinux PMEM, on the other hand, covers the total physical memory usage of all processes belonging to an account.
If real traffic exceeds the package, it can be resolved. If it's a bot, malware or slow code, it only allows the problem to consume more resources and is temporary.
There is no single universal number. It should be determined based on the application structure of your account and usually should be high enough to be greater than EP value; total server capacity should also be taken into account.
Googlebot may encounter a 508 response repeatedly, which can negatively affect crawling and user experience. The error should not recur during peak hours.
If shared package limits are exceeded after optimization, a VPS/VDS is reasonable. First, measure fault tolerance and application performance.
By analyzing cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim and security layers together, we fix the root cause of the failure instead of just removing the service.