How to fix "Allowed memory size exhausted" in PHP and WordPress on your own server

1. Find the error and what caused it

The message is in the Nginx error log (or the site's own log):

sudo grep "Allowed memory size" /var/log/nginx/error.log | tail -n 5

In our test, it looked like this:

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 209719296 bytes) in /var/www/wordpress/wp-content/mu-plugins/hog.php on line 5

• 134217728 bytes is the limit: 128 MB, the default for websites.
• The file at the end shows where PHP was when it ran out. In WordPress, the folder name after plugins/ or themes/ usually names the culprit. It isn't always the cause, though: it can be the last small step of a page that was already too big.

WordPress shows visitors "There has been a critical error on this website" with status 500. It also emails the admin address, often with a link to a recovery mode where you can turn off the plugin that failed.

2. Is the limit too low, or is something wrong?

128 MB is enough for most WordPress, Drupal and Laravel pages. If a normal page needs more, raising the limit often only hides a problem:

• A plugin or theme that loads far too much, for example every product or every log entry at once.
• An import, export or image resize that should run in a background job (see queue workers or a real cron for WordPress).
• A bug that loops forever. Then no limit is big enough.

If it's one heavy admin task, like a big import, raising the limit is fine. If it's the home page, find out why first: turn off plugins one by one (rename the folder in wp-content/plugins), or measure with memory_get_peak_usage().

3. The terminal and the website have different limits

This catches many people. On Debian and Ubuntu, PHP on the command line has no memory limit. Websites get 128 MB. In our test:

$ php -r 'echo ini_get("memory_limit");'
-1
$ php-fpm8.4 -i | grep ^memory_limit
memory_limit => 128M => 128M

So a script that used 200 MB worked when we ran it with php script.php, and gave a 500 error as a web page. Always check the website's value with php-fpm8.4 -i, not php -i. And don't edit /etc/php/8.4/cli/php.ini to fix a website: it does nothing for the site.

4. Raise the limit for all sites

Put it in a small file of its own, in the PHP-FPM folder:

echo "memory_limit = 256M" | sudo tee /etc/php/8.4/fpm/conf.d/99-memory.ini
sudo php-fpm8.4 -t && sudo systemctl reload php8.4-fpm
php-fpm8.4 -i | grep ^memory_limit

In our test, a reload was enough. The page that needed 200 MB worked right after. The last line should show 256M.

Never use -1 (no limit) for websites. Then one bad page can take all the server's memory. Linux then starts killing programs, often the database, and every site goes down. See out-of-memory errors.

5. Or raise it for one site

If each site has its own PHP-FPM pool, set it in that site's pool file:

php_admin_value[memory_limit] = 256M

Then sudo php-fpm8.4 -t && sudo systemctl reload php8.4-fpm. A value set with php_admin_value is final: the site's code can't change it. That matters for WordPress (next step).

6. WordPress's own memory settings

WordPress has two settings for wp-config.php:

• WP_MEMORY_LIMIT: for normal pages. WordPress raises PHP's limit to this value, but never lowers it.
• WP_MAX_MEMORY_LIMIT: for the admin area. It's 256M by default. In our test, the dashboard ran with 256 MB while the site's pages had 128 MB, without us setting anything.

Adding this to wp-config.php, above /* That's all, stop editing! */, fixed our test page:

define( 'WP_MEMORY_LIMIT', '256M' );

But it only works if PHP lets WordPress change the limit. When the pool set php_admin_value[memory_limit] = 128M, the same line did nothing: the page failed again, and the admin area also dropped to 128 MB. If your WordPress setting seems to be ignored, look for php_admin_value in the pool files:

sudo grep -R memory_limit /etc/php/8.4/fpm/

7. Check that the memory is really there

The limit is per page, and many pages run at the same time. The worst case is the limit times the number of PHP workers (pm.max_children). With 256 MB and 10 workers, that's up to 2.5 GB. Most pages use far less than the limit, but a busy moment with heavy pages can still use up the server's memory. Check how much you have with free -m, and see our PHP-FPM guide to set the number of workers.

Quick list

• Find the cause: grep "Allowed memory size" /var/log/nginx/error.log. The file path shows which plugin or script.
• Works in the terminal, not on the site: the command line has no limit; check with php-fpm8.4 -i.
• All sites: memory_limit = 256M in /etc/php/8.4/fpm/conf.d/99-memory.ini, then reload.
• One site: php_admin_value[memory_limit] in its pool file.
• WordPress: WP_MEMORY_LIMIT works only if the pool doesn't set php_admin_value[memory_limit].
• Never use -1 for websites.

Official sources

• PHP core settings (php.net) (memory_limit)
• memory_get_peak_usage() (php.net)
• Editing wp-config.php (WordPress.org) (WP_MEMORY_LIMIT, WP_MAX_MEMORY_LIMIT)

Next steps: if uploads fail instead, see fixing upload limits. If Nginx shows 502 or 504, see fixing 502 and 504 errors.

ServerNest is being built to let you set PHP limits like this for each site from one simple dashboard. Join early access to try it first.

← Back to the security blog