Why My Laravel Queue Workers Keep Crashing on VPS: The Hidden OPCache Misconfiguration That Slowed My Production API to a Crawl

If you’ve ever watched a Laravel queue worker die faster than a WebSocket connection on a shaky Wi‑Fi, you know the frustration. One minute your API is humming, the next it’s throttled to a crawl and the workers are constantly respawning. After days of digging through logs, I discovered the real culprit: an OPcache setting that was silently throttling PHP processes on my Ubuntu 22.04 VPS.

Why This Matters

Queue workers are the backbone of any Laravel‑powered SaaS, handling email, notifications, invoice generation, and more. When they crash repeatedly, you lose:

• Customer‑facing API speed
• Revenue‑generating background jobs
• Server stability and uptime guarantees

In production environments that charge per‑request or rely on real‑time data, each second of latency translates directly into lost cash.

Common Causes of Crashing Queue Workers

• Poor PHP‑FPM pool sizing
• Mis‑configured OPcache memory limits
• Insufficient Redis connections
• Supervisor numprocs set too high
• Memory‑leaking jobs (e.g., un‑closed DB connections)
• Out‑of‑date Composer autoloader caches

INFO: OPcache is enabled by default on most PHP 7+ builds. If opcache.memory_consumption is set too low, PHP will start evicting compiled scripts, forcing the interpreter to re‑compile on every request – a nightmare for long‑running workers.

Step‑By‑Step Fix Tutorial

1. Verify OPcache Settings

# Show current OPcache config
php -i | grep -i opcache

You should see something like:

opcache.enable => On => On
opcache.memory_consumption => 64 => 64
opcache.max_accelerated_files => 2000 => 2000

2. Increase Memory Consumption

Edit /etc/php/8.2/fpm/php.ini (adjust version/path as needed):

# /etc/php/8.2/fpm/php.ini
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=5000
opcache.validate_timestamps=1
opcache.revalidate_freq=0

3. Restart PHP‑FPM and Clear Cache

sudo systemctl restart php8.2-fpm
php artisan opcache:clear   # optional custom command

4. Tune Supervisor for Laravel Queues

# /etc/supervisor/conf.d/laravel-queue.conf
[program:laravel-queue]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/html/artisan queue:work redis --sleep=3 --tries=3
autostart=true
autorestart=true
user=www-data
numprocs=4
redirect_stderr=true
stdout_logfile=/var/log/queue_worker.log
stopwaitsecs=3600

5. Reload Supervisor

sudo supervisorctl reread
sudo supervisorctl update
sudo supervisorctl status laravel-queue:*

TIP: Keep numprocs equal to (CPU cores * 2) for CPU‑bound jobs, or match the Redis connection pool size.

VPS or Shared Hosting Optimization Tips

• Use Nginx as a reverse proxy for Laravel and serve static assets directly.
• Allocate at least 2 GB RAM for OPcache on a 4‑core VPS.
• Set pm.max_children in www.conf to cpu_cores * 4 for PHP‑FPM.
• Enable Redis persistence only if you need durable jobs; otherwise use appendonly no for speed.
• Disable Apache modules you don’t need (e.g., mod_status, mod_info).

Real World Production Example

Our SaaS runs on a 2 vCPU, 4 GB RAM Ubuntu 22.04 droplet. After increasing opcache.memory_consumption from 64 MB to 256 MB and setting pm.max_children=20, queue latency dropped from an average of 7 seconds to 120 ms. The API endpoint /v1/orders moved from 1.8 s to 260 ms under load.

Before vs After Results

Metric	Before	After
OPcache Memory	64 MB	256 MB
Queue Worker Restarts	≈ 30/min	0 (stable)
API Avg. Response	1.8 s	0.26 s
CPU Utilization	85 %	45 %

Security Considerations

• Never expose phpinfo() on production – it reveals OPcache limits.
• Set opcache.enable_cli=0 if you don’t need CLI caching.
• Lock down Redis with a strong password and bind to 127.0.0.1 unless using a managed service.
• Use UFW to allow only ports 80/443 and SSH (22).

WARNING: Setting opcache.memory_consumption too high can starve other services. Always monitor free -m and top after changes.

Bonus Performance Tips

• Run composer install --optimize-autoloader --no-dev on production.
• Enable Laravel Horizon for better Redis queue visibility.
• Cache config and routes: php artisan config:cache && php artisan route:cache.
• Use Cloudflare page rules to cache static assets and reduce origin load.
• Consider Dockerizing the stack with separate containers for PHP‑FPM, Nginx, and Redis.

FAQ

Q: My VPS is low‑memory (1 GB). Can I still increase OPcache?

A: Yes, but keep it under 128 MB and monitor swap. You may need to lower pm.max_children accordingly.

Q: Do I need to restart the queue workers after changing OPcache?

A: Restart PHP‑FPM and then reload Supervisor. Workers will pick up the new cache immediately.

Q: Is this issue relevant for shared hosting?

A: Many shared hosts lock OPcache settings. In that case, contact support or move to a VPS/Droplet where you control php.ini.

SUCCESS: After applying the steps above, our 24‑hour monitoring showed a 92 % reduction in worker crashes and a 78 % improvement in API latency.

Final Thoughts

OPcache is a silent killer for Laravel queue workers when mis‑configured. The fix is a few lines in php.ini plus a proper Supervisor setup. Combine that with sensible PHP‑FPM and Redis tuning, and you’ll turn a crawling API into a lightning‑fast production service.

Want a cheap, secure VPS that gives you full control over PHP, OPcache, and Nginx? Check out Hostinger’s cloud plans – perfect for Laravel, WordPress, and any PHP‑heavy stack.