Why Your Shared Hosting Site Is Slow: LVE Limits, 503 Errors and PHP X-Ray

Your site has gone sluggish, or visitors are seeing a 503 Resource Limit Reached error. The instinct is to blame the server or reach for a bigger plan. On shared hosting the cause is usually inside your application, and you can find it yourself in a few minutes with tools already in cPanel.

Your account runs in its own container

Every WebGee shared and reseller account runs inside its own Lightweight Virtual Environment (LVE), a CloudLinux container with fixed resource limits. If one account runs a runaway script or comes under attack, it is throttled or has processes killed, and every other account carries on unaffected. The limits exist so someone else's problem never becomes yours.

Unless your plan states otherwise, each account has:

• CPU: 1 core
• Memory: 1 GB
• Entry processes: 30 concurrent

Read the full explanation in CloudLinux and LVE limits explained.

Match the symptom to the limit

Each limit behaves differently when you reach it, and that tells you where to look:

• CPU: the site slows down, but requests still complete.
• I/O: the site slows down, especially anything disk-heavy.
• Entry processes (EP): a 503 error, because requests are killed outright.
• Physical memory (PMEM): a 503 error, or the process is killed.

CPU and I/O limits degrade your site; entry process and memory limits break it. A sluggish site is hitting a different limit from one returning 503s.

Why slow sites run out of entry processes

An entry process is a request currently being handled inside your account. The limit is how many can run at the same moment, not per hour and not per visitor. A PHP request usually finishes in a fraction of a second, and its slot is free again as soon as it does.

The catch is that the longer each request takes, the fewer visitors it takes to hit the limit. A page taking 5 seconds holds its slot 25 times longer than one taking 200 ms. Once requests start queuing, pages get slower still and hold their slots even longer. That feedback loop is why sites tend to fail suddenly rather than gradually.

Requests above the limit are terminated by the kernel with SIGKILL, and the visitor sees the 503. The usual triggers are long-running work:

• A cron job that takes minutes and runs every minute
• WP-Cron firing on page loads
• A plugin making a slow external API call on every request
• A database query with no index

More detail is in What entry processes are.

Find out which limit you hit

Start in cPanel → Resource Usage. It shows which limit was reached, when, and what was running at the time.

1. In cPanel, open Resource Usage.
2. Select the period covering the slowness, the 503s or the alert email.
3. Check which limit was reached: CPU, I/O, entry processes or memory.
4. Open the snapshot for that moment. It lists the processes responsible.

The snapshot is what turns a symptom into a cause. If the faults cluster at a particular time, check cPanel → Cron Jobs next, because a heavy job on a short schedule is a common culprit.

See You received a resource usage alert and Fix a 503 Resource Limit Reached error for the full walkthrough.

Trace slow requests with PHP X-Ray

Resource Usage tells you which limit; PHP X-Ray tells you where the time goes inside a request. It traces real requests and breaks each one down, so you stop guessing whether the problem is a plugin, a database query or an external call. It is available on shared, reseller and Premium hosting.

1. In cPanel, open X-Ray.
2. Select the domain or subdomain to trace.
3. Enter your own IP address, set the requests to collect to 10–20, and choose a timeframe long enough to reproduce the slowness.
4. Start the trace, then visit the slow page a few times in your browser.
5. Open the collected trace once the Collected Requests column fills.

Look for these, roughly in order of how often they are the culprit:

• One slow database query repeated many times, usually a plugin querying inside a loop. Object caching often fixes this outright.
• A slow external HTTP call, such as a plugin contacting a licence server or an API. The page cannot finish until it returns.
• One plugin dominating total time. Disable it and trace again to confirm.

Step-by-step screenshots are in Find what is making your site slow.

Do not mistake PHP memory_limit for your account limit

memory_limit caps how much memory a single PHP script may allocate. You change it under cPanel → Select PHP Version → Options (see Change your PHP version and settings). Raising it is reasonable for large imports, image processing on big uploads, a WooCommerce store with a large catalogue, or an application that documents a higher requirement.

It does not raise your account's memory limit. That is set by your plan and is what produces 503 errors. Setting memory_limit above your account's allocation achieves nothing, because the script is killed at the account limit regardless.

A normal WordPress page load fits comfortably in 128–256 MB. If your homepage needs 1 GB, something is loading far more than it should: a plugin querying without limits, an unbounded loop, or image processing on every request rather than once at upload. Trace it with X-Ray before raising anything.

To check the value actually applied, create a PHP file containing <?php echo ini_get('memory_limit');, load it, then delete it. On Bolt-Cache the PHP Selector is ignored and the value comes from .user.ini. More in Understanding PHP memory limits.

Bring usage back down

Fix the application first. These steps, in this order, resolve most cases:

1. Enable caching. A cached page never reaches PHP, so it never becomes an entry process. Start with LiteSpeed Cache, then add Redis object caching for logged-in traffic and the admin area.
2. Audit your plugins. Disable them all, wait a couple of minutes, then re-enable them one at a time while watching Resource Usage.
3. Fix your cron jobs. WP-Cron runs on page load, which is the wrong behaviour under load. Replace WP-Cron with a real cron job, and lengthen the interval on any other heavy job.
4. Check for abnormal traffic. Bots and scrapers consume the same resources as customers.
5. Scan for malware. A compromised site burns resources doing someone else's work. Scan your site for malware.

Catch problems before your visitors do

Site Quality Monitoring in cPanel checks one domain for uptime every hour and runs a full health and performance scan weekly, looking for broken links, missing metadata, slow pages and mixed content. It is off until you create a project:

1. In cPanel, select Site Quality Monitoring.
2. Choose the Monitored domain and enter a notification Email Address.
3. Tick the consent box and select Create Project.

Use an address not hosted on the account being monitored, or a downtime alert may never reach you. Monitoring sees what a visitor sees, so it cannot tell you why a page is slow. If it reports intermittent downtime, check Resource Usage, because the cause is often resource limits rather than an outage.

Setup details are in Site Quality Monitoring.

When an upgrade is the right answer

Upgrade only after you diagnose. An upgrade raises the ceiling without addressing what is consuming resources, so a runaway plugin simply consumes more. If the Resource Usage snapshot shows legitimate traffic doing legitimate work, the limits can be raised, which is what the Elastic Cloud plans are for. Open a ticket with your Resource Usage figures and WebGee will advise.