The Error
Your app just died with this in the logs:
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 65536 bytes) in /var/www/html/app/vendor/something/heavy.php on line 342
134217728 bytes = 128MB. PHP hit its memory cap and refused to allocate more. The process is dead. Users are seeing a blank page or 500 error.
Quick Triage
First, confirm the actual memory limit PHP is running with:
php -r "echo ini_get('memory_limit');"
Or drop this in a temporary PHP file accessible via browser:
<?php echo ini_get('memory_limit');
You'll see 128M, 256M, or whatever the current cap is. If you see -1, memory is unlimited — the error is coming from somewhere else (check open_basedir or OS-level limits instead).
Also check which php.ini is actually being loaded — there are often multiple:
php --ini
For PHP-FPM specifically:
php-fpm8.1 --ini
Solution 1: Increase Limit in php.ini (Permanent Fix)
Start here. This change sticks — it persists across restarts and applies globally to everything PHP runs on the server. Find and edit your active php.ini:
; Find the memory_limit line and change it:
memory_limit = 512M
After saving, restart PHP-FPM or Apache:
# PHP-FPM
sudo systemctl restart php8.1-fpm
# Apache with mod_php
sudo systemctl restart apache2
Verify the change took effect:
php -r "echo ini_get('memory_limit');"
Solution 2: Set It Per-Project (When You Can't Touch php.ini)
On shared hosting or locked-down servers, you often don't have access to php.ini. A few workarounds:
In .htaccess (Apache only)
php_value memory_limit 512M
In your PHP script (top of file)
<?php
ini_set('memory_limit', '512M');
This works on most hosts. Some disable ini_set for security, or run suhosin to block runtime changes entirely. If neither option works, you'll need to contact your host.
WordPress-specific
Add to wp-config.php before the line / That's all, stop editing! /:
define('WP_MEMORY_LIMIT', '512M');
define('WP_MAX_MEMORY_LIMIT', '512M'); // For admin area
Solution 3: PHP-FPM Pool Config
Running PHP-FPM? The pool config can override php.ini entirely. Check your pool file (usually at /etc/php/8.1/fpm/pool.d/www.conf):
; Add or update this line in your pool config:
php_admin_value[memory_limit] = 512M
Then restart:
sudo systemctl restart php8.1-fpm
The php_admin_value directive takes precedence over php.ini and cannot be overridden by ini_set() in application code — useful when you want to lock the limit per-site.
Verify the Fix
Don't assume the restart worked. Confirm it:
# CLI
php -r "echo ini_get('memory_limit') . PHP_EOL;"
# If it's a web app, hit a test endpoint
curl -s https://yourapp.com/phpinfo.php | grep memory_limit
Check your error logs to confirm the fatal error stopped appearing:
sudo tail -f /var/log/php8.1-fpm.log
sudo tail -f /var/log/nginx/error.log
What If the Error Comes Back?
Raising the limit once is normal. Doing it every few months is a different story — something in your code is pulling more data into memory than it needs to. A few likely culprits:
- Large dataset queries: Loading thousands of Eloquent/Doctrine objects at once. Use chunking:
User::chunk(200, fn($users) => ...) - Image processing: GD and Imagick are memory-hungry. Processing a 20MP image can consume 300MB+. Resize before processing, or offload to a queue worker with a higher limit.
- Composer autoload bloat: Too many packages loading at once. Profile with
memory_get_peak_usage(true). - Recursive functions or infinite loops: These silently chew through memory. Add depth counters or switch to iterative approaches.
Quick memory profiling:
<?php
// Add checkpoints throughout your code
echo memory_get_usage(true) / 1024 / 1024 . ' MB' . PHP_EOL;
// At the end:
echo 'Peak: ' . memory_get_peak_usage(true) / 1024 / 1024 . ' MB' . PHP_EOL;
How Much Memory Should You Set?
Depends on your stack. Here's what works in practice:
- General web apps: 256M is reasonable
- WordPress with plugins: 256M–512M
- Laravel/Symfony with heavy operations: 256M–512M
- Image processing / data imports: 512M–1024M for CLI workers
- Never set
-1on production web processes — a runaway script will take down the server
Set a firm limit and let it crash loudly when something goes wrong. Silent memory consumption is worse than a visible error.
Why 128MB Isn't Enough Anymore
That default was baked into PHP back in the 5.2 era, when most apps were a handful of scripts and a MySQL query or two. Things changed. A fresh Laravel 11 app with a few standard packages can consume 60–80MB just on bootstrap — before handling any real request.
Raising the limit once is the right call. But if you're bumping it repeatedly, the app is loading data it doesn't need: full table results hydrated into objects, unused packages being autoloaded, images processed inline instead of queued.
For CLI scripts and queue workers, set a higher limit in their specific pool or script. Don't inflate the global web limit just to accommodate a nightly import job.