Tired of your LiteSpeed server crashing under load due to hidden process limits? A senior DevOps engineer breaks down why it happens and provides three real-world solutions, from a quick fix to a permanent architectural change.

From the Trenches: Taming Your LiteSpeed Server’s Hidden Limits

I remember a 3 AM call from a frantic project manager. Our biggest e-commerce client, `ecom-web-prod-02`, was buckling during a flash sale. The site was throwing 503 errors, but every monitoring tool we had showed a server that was barely breaking a sweat. CPU was low, memory was fine, I/O was a joke. It made no sense. After an hour of digging through logs and pulling my hair out, I finally found it: a cryptic “fork: retry: Resource temporarily unavailable” error buried deep in the system logs. The server wasn’t out of memory; it was out of processes for the user running the web server. We were hitting a ghost wall, and it’s a wall I see junior engineers run into all the time.

So, What’s Actually Breaking? The “Why” Behind the Crash

This problem isn’t really about LiteSpeed or even PHP’s `memory_limit`. It’s a classic case of a turf war between your application server and the underlying Linux operating system. Here’s the breakdown:

• Most default LiteSpeed or cPanel/Plesk setups run all the website processes as a single, unprivileged user, often nobody or a specific account user.
• To protect itself, Linux imposes a limit on the number of processes any single user can create. This is called nproc (number of processes). On many systems, the default can be surprisingly low, like 1024.
• When traffic spikes, LiteSpeed’s PHP handler (LSAPI) tries to spin up dozens or hundreds of new child processes to handle the requests.
• If the number of new PHP processes plus all the other processes already running as that user exceeds the OS-level nproc limit, Linux simply says “Nope.” It refuses to create a new process, your PHP script never runs, and the user gets a generic server error.

Your server metrics look fine because you aren’t out of RAM or CPU; you’re just being blocked by a kernel-level safety net you probably didn’t even know was there.

Fixing It: From a Band-Aid to a Real Solution

We’ve got a few ways to tackle this, ranging from the “get me back online now” hack to the “let’s architect this properly” solution. Choose wisely.

Solution 1: The Quick Fix (The “Sledgehammer”)

The fastest way to solve this is to globally increase the process limit for the user in question. You do this by editing the /etc/security/limits.conf file. It’s a blunt instrument, but it works in a pinch.

You’ll add a line at the bottom of this file. If your web server runs as the user nobody, it would look like this:

# /etc/security/limits.conf

# ... other system limits ...

# Increase process limit for the web server user
nobody          hard    nproc   16384
nobody          soft    nproc   16384

Why it’s “hacky”: This change is global. It affects the nobody user everywhere, not just for the LiteSpeed service. If other services use this user, they also get the higher limit. It can also sometimes be ignored by services started via `systemd` depending on the system configuration, and it feels like a relic from a pre-systemd era. But hey, when the site is down at 3 AM, you do what you have to do.

Pro Tip: After applying this fix (and relogging in or restarting the service), you can verify the limit for a running process by finding its PID (ps aux | grep litespeed) and then checking its specific limits with cat /proc/PID/limits.

Solution 2: The Permanent Fix (The “Surgical Strike”)

The modern, correct way to handle service-specific limits is with a systemd override. This targets only the LiteSpeed service, leaving the rest of the system untouched. It’s clean, self-contained, and the standard for modern Linux administration.

First, create a directory for the override file:

sudo mkdir -p /etc/systemd/system/lsws.service.d/

Next, create a new configuration file inside that directory. Let’s call it limits.conf.

sudo nano /etc/systemd/system/lsws.service.d/limits.conf

Inside this file, add the following content:

[Service]
LimitNOFILE=65535
LimitNPROC=16384

Here, LimitNOFILE increases the open file limit (another common bottleneck) and LimitNPROC directly sets the process limit for the service. After saving the file, you just need to tell `systemd` to reload its configuration and restart LiteSpeed:

sudo systemctl daemon-reload
sudo systemctl restart lsws

This is the solution I implement 99% of the time. It’s idempotent, easy to manage with automation tools like Ansible, and follows the principle of least privilege by only modifying the service that needs it.

Solution 3: The ‘Nuclear’ Option (The “Architect’s Approach”)

Sometimes, hitting these limits is a symptom of a larger architectural problem. If you’re running dozens of high-traffic sites on a single server under a single user, you’re living on borrowed time. The real, forward-thinking solution is to stop treating your server like a shared apartment complex and start giving each application its own house.

Isolate your workloads.

This means containerization. By packaging each website into its own Docker container, you solve this problem at its root:

• Resource Isolation: Each container gets its own dedicated CPU, RAM, and process limits (via cgroups). One site getting hammered with traffic can’t steal all the available processes from another.
• No More Shared Users: The nproc limit inside a container is separate from the host’s limits. The problem of a shared nobody user vanishes entirely.
• Scalability: Need to handle a flash sale? You don’t tweak a global config file; you simply scale up the number of containers for that specific site using an orchestrator like Kubernetes or Docker Swarm.

This is obviously not a “quick fix.” It’s a strategic shift in how you deploy and manage your applications. But if you’re consistently fighting with shared server limits, it’s a sign that your infrastructure has outgrown its initial design. It’s time to stop patching the old monolith and start building a more resilient, scalable system.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions