How to Fix Allowed Memory Size Exhausted in WordPress

The message Fatal error: Allowed memory size of 134217728 bytes exhausted means one PHP request tried to use more memory than PHP allows. The number is the limit in bytes: 134217728 is 128 MB, the common default. The page usually goes blank or shows the error where content should be. The fix has two parts that are easy to mix up. Raising the limit is the quick fix, and it lets the page work. Finding what used the memory is the real fix, because a page that needs more and more memory will fail again on the next bigger job.

This guide shows how to read the error, which setting controls the limit, how to raise it safely, and how to find the plugin or task that uses the memory.

Step 1: Read the exact error and where it was logged#

The message is written to the PHP error log, not always to the browser. Find the log and read the newest lines:

sudo grep -h "Allowed memory size" /var/log/php8.4-fpm.log /var/www/example/wp-content/debug.log 2>/dev/null | tail -10

Check the file path named in the message. A line that ends with in /var/www/example/wp-content/plugins/some-plugin/file.php on line 123 tells you which plugin or theme file ran out of memory. That is the first suspect. If the line names only WordPress core files, such as wp-includes/, the cause is usually a large query, a large image, or an import.

If there is no log line at all, enable WordPress’s debug log for a short time. Add these lines to wp-config.php above the line /* That's all, stop editing! */:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

The log is written to wp-content/debug.log. Turn debugging off again when you have the answer, because the log can grow large and it may contain paths you do not want public. Make sure the file is not reachable from the browser; the protection rules are in how to secure WordPress on cPanel hosting.

Step 2: Understand the two limits#

Three settings can be involved, and only one of them is the hard limit:

• PHP’s memory_limit is the hard limit for every PHP request on that runtime. Its default is 128M. This is the setting that produces the error.
• WP_MEMORY_LIMIT is a WordPress constant that asks PHP to raise the limit for normal front-end requests. WordPress’s developer documentation gives 40 MB as the default for single sites and 64 MB for multisite. WordPress can only raise the limit up to what PHP and the host allow.
• WP_MAX_MEMORY_LIMIT applies to requests in the administration area, such as updates and imports. It has its own default and is set separately.

Setting WP_MEMORY_LIMIT to 512M on a server whose PHP memory_limit is 128M does nothing useful, because PHP refuses the higher value. The host limit is the real ceiling, so check that first.

Step 3: Check the limit the web request actually gets#

WordPress shows the effective limits in the health check. Open Tools → Site Health → Info → Server and look for PHP memory limit. That value is what the web request gets, which can differ from the command line.

From the server, check the PHP-FPM setting, both the global file and any pool that overrides it:

sudo grep -nE "^\s*memory_limit" /etc/php/8.4/fpm/php.ini
sudo grep -rn "memory_limit" /etc/php/8.4/fpm/pool.d/

A line in a pool file, written as php_admin_value[memory_limit], overrides php.ini for that site. If the pool line is present, change it there, not in the global file.

Step 4: Raise the limit, the safe way#

For a single site on its own PHP pool, the cleanest fix is to set the limit for that pool. A value of 256M is a reasonable starting point for WooCommerce, page builders and image-heavy sites:

php_admin_value[memory_limit] = 256M

Use the global php.ini only when every site on the server needs more memory. Then restart PHP-FPM:

sudo nginx -t && sudo systemctl reload nginx
sudo systemctl restart php8.4-fpm

Check the result the web request gets, not the command line. Create a temporary phpinfo file, read the value, then delete the file at once:

echo "<?php phpinfo();" | sudo tee /var/www/example/phpinfo-check.php
curl -s https://example.com/phpinfo-check.php | grep -i "memory_limit" | head -2
sudo rm /var/www/example/phpinfo-check.php

Expected: the new value shows in the response. Remove the file immediately, because phpinfo() reveals the server’s configuration to anyone who finds it.

On WordPress, once PHP allows the higher limit, WP_MEMORY_LIMIT can request a value up to that ceiling. Set it in wp-config.php only if you want a value different from PHP’s:

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

Place these lines above /* That's all, stop editing! */. The admin limit is higher because updates and imports legitimately need more memory.

Step 5: Find what used the memory#

A higher limit is a short-term fix if one request is growing without bound. To find the cause, measure the memory each request uses. The Query Monitor plugin shows the peak memory per page, and the slowest and largest database queries, from inside WordPress. Install it on a staging copy or on a test account, not on a live site that serves visitors, then remove it when you are done.

Work through the likely causes in this order:

• A plugin that loads everything at once. Deactivate plugins one at a time, reloading the failing page after each one. The one that stops the error is your suspect. Replace it, or ask its author about the memory use.
• Large images. Uploading a very large photo and generating thumbnails can use a lot of memory. Resize images before upload, and check whether a plugin is generating many sizes.
• A bulk operation in one request. Imports, exports, and bulk edits can load every item into memory at once. Run them in batches, or from the command line with WP-CLI, which has no web time limit.
• A bad query. A query that returns thousands of rows into a list is a common cause, and it is a code problem, not a server problem.
• A cron job or a background task that loops forever. Check the scheduled events with wp cron event list from the server.

Step 6: Use WP-CLI for heavy tasks#

Commands run from the command line use the CLI’s own PHP settings, and they do not have the web server’s time limit. For long jobs, this is the safer place to run them. Run them as the site’s user, from the WordPress directory:

sudo -u www-data wp --path=/var/www/example plugin list --status=active
sudo -u www-data wp --path=/var/www/example cron event list

The command-line PHP can have a different memory limit from the web runtime. Check it with php -i | grep memory_limit, and set it for the CLI in /etc/php/8.4/cli/php.ini if a job needs more.

Common mistakes#

• Setting WP_MEMORY_LIMIT above the PHP limit and expecting it to work. WordPress cannot go past the host’s ceiling.
• Editing the CLI php.ini and testing in the browser. The web workers read the FPM file, so the browser sees no change.
• Forgetting to restart PHP-FPM. The value applies only after the service restarts.
• Raising the limit to unlimited. A request can then take all the memory on the server, which slows every other site.
• Leaving debug logging or phpinfo files on the server. Both reveal details to anyone who finds them.

Frequently asked questions#

What is a safe memory limit for WordPress?#

For most sites, 256M is a reasonable upper value for web requests, and most small blogs run well at 128M to 256M. A higher value is a sign to look for the cause in Step 5.

Why does the error only happen in the admin area?#

Admin pages load more code, and updates and imports handle more data. Check WP_MAX_MEMORY_LIMIT, and check the bulk operation that runs there.

Why does it still fail after I raised the limit?#

Either the change is not in the file that the web workers read, or the PHP-FPM service was not restarted, or the pool file has a lower value. Step 3 shows which value applies.

Is this the same as a 500 error?#

Often it appears as a 500 error page with no detail. The log line in Step 1 is the proof that memory was the cause.

Read the error to find the file and the request, check the limit that the web request actually gets, raise it for the pool that needs it, and then find the plugin or task that uses the memory. The raised limit keeps the site working; the fix for the cause keeps it working under growth.