Stop Worker Crashes: Fixing Laravel Queue Memory Leaks in Production

The Silent Killer of Background Jobs

When you deploy a B2B SaaS platform at Smart Tech Devs, your Laravel queues handle the heaviest lifting—processing CSV imports, generating PDF reports, and sending thousands of emails. To process these efficiently, we use the php artisan queue:work command. This runs the worker as a daemon process, meaning the PHP script boots up once and stays alive in memory to process job after job without the overhead of rebooting the framework.

However, this speed comes with a dangerous architectural trade-off: Memory Leaks. Because the PHP process never dies, static variables, singleton instances, and Eloquent model caches slowly accumulate in RAM. Over a few hours (or days), your worker hits the PHP memory limit (usually 128MB or 256MB) and violently crashes with a Allowed memory size exhausted fatal error.

The Enterprise Solution: Graceful Restarts

While you should absolutely profile your code to fix severe leaks, minor memory accumulation in a long-running PHP daemon is almost inevitable. The standard DevOps solution is not to endlessly increase your server's RAM, but to architect Graceful Restarts.

Instead of letting the worker run until it explodes, we instruct Laravel to automatically kill the worker process safely after it hits a specific threshold. Because we use a process monitor like Supervisor on our Ubuntu VPS, the moment the worker dies, Supervisor instantly spawns a fresh, clean process with zero memory bloat.

Configuring Supervisor for Scalability

In Laravel, we control these thresholds using two powerful flags: --max-jobs and --max-time.


# /etc/supervisor/conf.d/laravel-worker.conf

[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
# The command tells the worker to die after 1,000 jobs OR 1 hour (3600 seconds)
command=php /var/www/smarttechdevs.com/artisan queue:work --max-jobs=1000 --max-time=3600 --tries=3 --timeout=90
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true
user=forge
numprocs=8 # Run 8 parallel workers
redirect_stderr=true
stdout_logfile=/var/www/smarttechdevs.com/storage/logs/worker.log
stopwaitsecs=3600

Why This Architecture Wins

Let’s break down why this specific command (--max-jobs=1000 --max-time=3600) is the gold standard for backend stability:

Predictable Memory: By forcing the PHP process to restart after 1,000 jobs, you guarantee the garbage collector flushes the RAM entirely. The worker never lives long enough to hit the fatal memory limit.
Safety First: Unlike a hard crash, Laravel waits for the current job to finish successfully before exiting. No data is lost or corrupted mid-process.
Zero Downtime: Supervisor detects the exit code and spins up the replacement worker in milliseconds. Your queue throughput remains massive, but your infrastructure stays perfectly healthy.

Conclusion

A reliable SaaS backend shouldn't require developers to wake up at 3 AM to restart failed queue workers. By acknowledging the reality of PHP memory management and architecting graceful restarts via Supervisor, you build a self-healing infrastructure capable of processing millions of background jobs effortlessly.

推荐订阅源