"Frustrated With Slow Laravel VPS? Fix This Common Memory Leak Now!"

If your Laravel VPS keeps getting slower every few hours,
there’s a good chance you’re not dealing with “bad hosting”…

You’re dealing with a silent memory leak.

I ran into this on an Ubuntu VPS using aaPanel. At first, everything looked fine — fast response, low CPU usage. But after a few hours:

• RAM usage kept climbing
• PHP-FPM started choking
• Requests became painfully slow
• Eventually… 502 / timeout

No obvious error. Just a dying server.

Here’s what actually happened — and how I fixed it.

---

The Real Problem: Long-Running Laravel Processes

In my case, the issue came from this:

php artisan queue:work

Looks harmless, right?

But here’s the catch:

• It runs continuously
• It does NOT reset memory automatically
• Bad jobs or large payloads = memory keeps growing

After ~6–8 hours:
👉 RAM usage hit 100%
👉 Server slowed to a crawl

---

How I Confirmed It Was a Memory Leak

I checked memory usage:

htop

Then watched the PHP process:

ps aux | grep php

What I saw:

• One php artisan queue:work process
• Memory usage kept increasing over time
• Never released

That’s your leak.

---

The Fix (This Actually Works)

1. Restart Queue Workers Regularly

Quick fix:

php artisan queue:restart

But that’s manual. Not enough.

---

2. Set Memory Limits on Workers (IMPORTANT)

Run this instead:

php artisan queue:work --memory=128 --sleep=3 --tries=3

What this does:

• Worker auto-restarts when memory hits 128MB
• Prevents runaway memory usage

---

3. Use Supervisor (Best Practice)

If you’re not using Supervisor yet, you’re asking for trouble.

Install it:

apt install supervisor

Example config:

[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/your-app/artisan queue:work --memory=128 --sleep=3 --tries=3
autostart=true
autorestart=true
numprocs=1
redirect_stderr=true
stdout_logfile=/var/www/your-app/storage/logs/worker.log

Then:

supervisorctl reread
supervisorctl update
supervisorctl start laravel-worker:*

Now your worker:

• Auto restarts
• Memory stays stable
• No more silent crashes

---

Bonus Fix: PHP-FPM Memory Tuning

Even if queue is fixed, PHP-FPM can still choke.

Edit:

nano /etc/php/8.1/fpm/php.ini

Adjust:

memory_limit = 256M

Restart:

systemctl restart php8.1-fpm

---

Another Hidden Cause: Large Eloquent Queries

I also found this in one job:

User::all();

On a big table? That’s a memory killer.

Fix it:

User::chunk(100, function ($users) {
    foreach ($users as $user) {
        // process
    }
});

Or:

User::cursor();

👉 This alone reduced memory usage dramatically.

---

What About "Uncaught TypeError"?

I saw this too during deployment.

Usually caused by:

• PHP version mismatch (8.1 vs 8.2)
• Cached config
• Broken dependency injection

Fix it fast:

php artisan config:clear
php artisan cache:clear
php artisan route:clear
composer dump-autoload

If still broken:
👉 check storage/logs/laravel.log

---

My Stack (For Context)

This setup is what I used:

• Ubuntu VPS
• aaPanel
• Laravel 8
• MySQL
• Filament admin panel

aaPanel made deployment easy, but it does NOT manage long-running processes properly by default.

That’s on you.

---

Final Result (After Fix)

Before:

• RAM always climbing
• Server slow after a few hours
• Random downtime

After:

• Stable memory usage
• No slowdowns
• Queue runs clean for days

---

Takeaway (Most Devs Miss This)

Laravel isn’t “slow”.

But:
👉 bad queue handling = memory leak = slow VPS

If you’re running:

php artisan queue:work

Without limits or Supervisor…

You’re just waiting for your server to crash.

---

Quick Checklist

• Use --memory flag on queue worker
• Use Supervisor (NOT manual run)
• Avoid Model::all() on large data
• Monitor with htop
• Clear cache after deploy

---

If your VPS slows down over time instead of instantly…

Don’t upgrade the server yet.

👉 Fix the leak first.