Detect LiteSpeed WebServer Slot Full — NOC Engineer

Introduction

One day I got a WhatsApp message from a hosting client — not a formal email, but a direct WhatsApp. At 3 PM, a time when server load is usually still stable. The message was short: “Hey, my website is really slow. It was fine this morning.”

I checked the monitoring — load average was still at 3, CPU under 40%. The clients website was accessible from my browser. But the complaints kept coming. Two other clients reported the same thing.

This is the type of problem that keeps you most curious: no errors in the logs, no crashes, but users are experiencing slowness. And usually, if its not the server resources that are exhausted, its a webserver slot issue.

As a NOC engineer who has handled shared hosting for years, I can tell you: slot problems are one of the most frequent issues that arise but the least understood by new admins. Because unlike Apache where slots are relatively static, LiteSpeed has a slightly different slot mechanism — and if you dont know how to detect it, you can spend hours without finding the root cause.

Symptoms — Whats Happening?

LiteSpeed webserver slot-full symptoms are distinctive:

• Websites on several domains are slow, but other sites are normal
• Server load isnt extremely high, but something is stuck
• Sometimes you see 503 Service Temporarily Unavailable or 502 Bad Gateway in the browser
• The LiteSpeed error log has entries like this:

[NOTICE] No request delivery process has been triggered, and no lscuid was found for UID 99
[LSCACHE] Cache is not enabled for this request, no handler found

The most obvious sign: one or two domains suddenly consume a lot of requests, and the slots available for other domains run out. LiteSpeed does use a slot system — each VHost has a simultaneous connection limit. If one VHost consumes too many slots, other domains on the same server suffer. (This concept is similar to the Apache slot issue I discussed previously — also read: Fix Apache Slot Full 503)

One time I spent 2 hours checking resources, checking logs, restarting PHP-FPM — only to find out it wasnt PHP that was the problem. It was one domain consuming 80% of the servers slots. As soon as I throttled that domain, all other websites immediately returned to normal.

Root Cause — Why Do Slots Run Out?

LiteSpeed Enterprise divides slots per VirtualHost. By default, each VHost gets a slot allocation based on MaxConnections in the config. But several situations cause slots to run out quickly:

1. Aggressive bots/crawlers — Googlebot, Ahrefs, SEMrush — if one domain has many pages and the crawler is active, it can consume hundreds of slots in seconds
2. Websites with many AJAX/API calls — e-commerce applications or apps that frequently fetch data via API
3. Unoptimized WordPress plugins — there are plugins that make 10+ requests at once per visit
4. Small-scale attacks/DDoS — not large-scale attacks, but enough to exhaust slots for one domain
5. MaxConnections configured too low — LiteSpeed defaults sometimes arent enough for servers with many tenants

How to Detect the Offending Domain — rtreport Analysis Script

The file /tmp/lshttpd/.rtreport is a real-time report from LiteSpeed. This file records per-VirtualHost request statistics periodically. From here we can see which domain is consuming the most requests.

Step 1: View Top 15 Domains by Request Count

Run the following script:

grep REQ_RATE [APVH_ /tmp/lshttpd/.rtreport 
  | awk -F[][] {print $2} 
  | awk {print $1} 
  | sort | uniq 
  | while read domain; do
    grep "REQ_RATE [$domain" /tmp/lshttpd/.rtreport 
      | tail -n1 
      | awk -v d="$domain" 
        {for(i=1;i<=NF;i++) if($i=="TOT_REQS:") print $(i+1) "t" d}
  done 
  | sort -nr 
  | head -n 15

Dont panic when you see the numbers. Heres an example of what we typically see on a normal server:

48372   APVH_example.com:80
12845   APVH_client-bajakan.net:80
 8723   APVH_blog-klien.co.id:80
 6541   APVH_toko-online.id:80
 3290   APVH_portfolio-personal.me:80
 2100   APVH_landingpage-baru.com:80
 1800   APVH_web-static.org:80
 1200   APVH_cpanel.subdomain.com:80
  890   APVH_api-mobile.app:80
  450   APVH_testing-staging.dev:80
  230   APVH_www:80
  120   APVH_localhost:80
   80   APVH_ancient-site.com:80
   30   APVH_parked-domain.info:80
    5   APVH_default:80

How to read it:

• The first number is total requests — all requests that came into that domain since logging started
• The domain at the top with a large gap from the rest is most likely the cause of the problem
• In the example above, example.com consumed 48 thousand requests — nearly 4x the second domain. This is the domain that needs deeper investigation
• Note domains with small numbers — they are the victims. Their slots were taken by the larger domain

Step 2: Check Detailed Stats for the Suspicious Domain

After identifying the domain consuming many requests, check its detailed statistics:

grep "REQ_RATE [APVH_example.com:80]" /tmp/lshttpd/.rtreport | tail -n5

Example output:

REQ_RATE [APVH_example.com:80] TIME: [19/Jul/2026:14:32:01 +0700]
  REQ_RATE: REQ_PER_SEC: 245  TOT_REQS: 48372
  TOT_BYTES_OUT: 1.2GB  TOT_BYTES_IN: 234MB
  AVG_RESP_SIZE: 26.3KB

REQ_RATE [APVH_example.com:80] TIME: [19/Jul/2026:14:33:01 +0700]
  REQ_RATE: REQ_PER_SEC: 261  TOT_REQS: 48633
  TOT_BYTES_OUT: 1.2GB  TOT_BYTES_IN: 236MB
  AVG_RESP_SIZE: 25.9KB

What to look for:

• REQ_PER_SEC — If consistently above 200, this is either a very active domain or being heavily crawled
• TOT_BYTES_OUT — If the output is very large, there are static files being frequently accessed (could be hotlinking)
• AVG_RESP_SIZE — If too small, there are many small requests hitting rapidly (could be API flood or AJAX storm)

Step 3: Check Real-Time Connections per VHost

Besides rtreport, we can also check the slots currently in active use:

# Check from LiteSpeed WebAdmin (port 7080)
curl -s http://127.0.0.1:7080/status 2>/dev/null | head -20

Or check from the process list to see how many active connections per domain:

# View all active LiteSpeed connections
netstat -tnp | grep lshttpd | awk {print $5} | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

This output shows which IP has the most connections. If there are only one or two IPs, its likely a bot or crawler — not regular users. If server load is high and slots are still normal but the site is still slow, it could be a database issue — also read: Troubleshoot High Database Load in MariaDB.

Solution — Fixing Full Slots in LiteSpeed

Solution 1: Add Slots for VHosts That Need Them

Edit the VHost config — usually at /usr/local/lsws/conf/vhosts/ or via WHM:

# /usr/local/lsws/conf/vhosts/EXAMPLE_com.conf
virtualHost {
  ...
  tuning {
    maxConnections         100
    maxSSLConnections      100
    connTimeout            300
    keepAliveTimeout       5
  }
}

Increase maxConnections for domains that genuinely need more connections. Restart LiteSpeed safely:

/usr/local/lsws/bin/lswsctrl graceful

Solution 2: Limit Overly Aggressive Crawlers

Is one domain consuming many requests due to an active crawler? Add rules:

# Limit crawl rate for specific bots via .htaccess
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (AhrefsBot|SEMrushBot|MJ12bot) [NC]
RewriteRule .* - [R=429,L]

Or be more subtle — use robots.txt on the problematic domain. The important thing is dont just block Googlebot because that can hurt the clients SEO ranking.

Solution 3: Optimize WordPress Plugins

Many slots consumed because of plugins? Check with WP-CLI:

# Via WP-CLI — see the number of hooks per page load
wp eval global $wp_actions; echo "Total hooks: " . $wp_actions . "n";

If the number is above 500, some plugin is too active. Deactivate them one by one while checking slot usage. From my experience, plugins that most often cause problems: uncached WooCommerce, analytics plugins that fire on every request, and social share plugins that load JS on every page. If the problem isnt plugins but disk space, also read: Detect Deleted Files on Linux with lsof +L1

Solution 4: Enable LSCache

Good caching means fewer PHP requests, fewer slots consumed:

# Enable LSCache via config
virtualHost {
  ...
  module cache {
    enable 1
  }
}

Or via WHM → LiteSpeed Web Server → Cache Manager → Enable. For WordPress, also make sure to install the LSCache plugin in WordPress.

Pro Tips & Warnings

• Check slots every 30 minutes routinely — not just when there are complaints. Set up a cron job to log rtreport so theres historical data when problems arise
• Dont blindly increase slots without investigation — if one domain is consuming 40k requests, adding slots without fixing that domain only delays the problem to the next day
• LiteSpeed Enterprise vs OpenLiteSpeed — the rtreport feature is on LiteSpeed Enterprise. OpenLiteSpeed has a similar feature but the file names and paths are different
• Use lswsctrl status to check if LiteSpeed is still running before restarting without checking current conditions
• Monitor regularly — slots can change over time. A website thats fine now could suddenly spike in requests due to a marketing campaign or viral content

FAQ

Q: What is the default MaxConnections in LiteSpeed?

The default is 100 per VHost for HTTP and 100 for HTTPS. But this can vary by license — LiteSpeed Enterprise has several tiers with different limits. For shared hosting, its typically set to 50-150 depending on server specifications.

Q: Do I have to restart LiteSpeed every time I change the config?

For VHost config changes, use lswsctrl graceful — this reloads config without dropping active connections. Only use lswsctrl restart for major changes or when theres no other option. A restart will drop all active connections, so avoid it during peak hours.

Q: Whats the difference between LiteSpeed rtreport and Apache server-status?

Apache server-status shows a single snapshot when accessed. LiteSpeed rtreport is a log file that continuously updates with per-VHost statistics. The advantage of rtreport: we can see history and trends, not just current conditions. But this file can grow large on servers with many VHosts — it usually rotates automatically every few hours.

Q: How do I know when slots have returned to normal?

Re-run the detection script above. If the gap between the most active domain and others isnt too large — say max 3x the average — and there are no user complaints, the slots are likely stable. What matters more: check if user complaints have disappeared.

Conclusion

LiteSpeed webserver slot problems are tricky because theyre not always accompanied by obvious errors. But with the /tmp/lshttpd/.rtreport file and the right detection scripts, you can quickly identify which domain is causing the problem.

The lesson from my experience: never blindly increase slots without investigation. Its better to fix the problematic domain — optimize plugins, limit crawlers, or even suspend it if its genuinely abuse — than to keep adding slots without limit. Because on shared hosting, one domain can affect hundreds of others.

So the next time you get a “slow website” complaint — dont immediately check PHP or MySQL first. Start with slots. That might just be the answer.

Author: NOC Engineer — written based on experience handling LiteSpeed slots on shared hosting production.