Why 'Allowed Memory Size Exhausted' Keeps Crashing Your WordPress Site — And How I Actually Fix It

A client messaged me last month: "My site keeps crashing. I've already increased the memory limit to 512MB and it's still happening." That sentence tells me everything I need to know. The problem isn't the limit — it's whatever is eating the memory in the first place.

The "Fatal error: Allowed memory size of X bytes exhausted" message is one of the most common WordPress errors. And the advice you'll find online is almost always the same: increase WP_MEMORY_LIMIT in wp-config.php, move on. That works until it doesn't. If a plugin is leaking memory or loading an entire database table into a PHP array, raising the ceiling just delays the next crash.

Here's how I actually diagnose and fix this error when clients bring it to me.

Read the error message — it tells you where to look

The full error looks something like this:

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 4194304 bytes) in /var/www/html/wp-content/plugins/some-plugin/includes/class-data-loader.php on line 142

Most people focus on the byte count. I focus on the file path. That path — plugins/some-plugin/includes/class-data-loader.php — points directly at the code that was trying to allocate memory when the limit was hit. It's not always the culprit (sometimes it's just the final straw), but 8 times out of 10, it leads you to the actual problem.

If you can't see the error because the site is showing a white screen, check the PHP error log:

tail -100 /var/log/php-fpm/error.log

Or if the host uses per-site logs:

tail -100 /var/www/html/wp-content/debug.log

For the debug log to work, you need these lines in wp-config.php:

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

Keep WP_DEBUG_DISPLAY set to false on a live site — you don't want visitors seeing PHP errors.

The quick fix and why it's often wrong

Yes, you can increase the memory limit:

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

And for admin-side operations like plugin updates, image processing, and WooCommerce imports:

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

These are WordPress-level constants. They request memory from PHP, but they can't exceed the actual PHP memory_limit set in php.ini or your PHP-FPM pool config. If your host's PHP limit is 128MB, setting WP_MEMORY_LIMIT to 256MB does nothing.

Check what PHP actually allows:

php -i | grep memory_limit

Or from within WordPress, go to Tools > Site Health > Info > Server and look for the PHP memory limit value.

Here's the thing: if a vanilla WordPress install with a lightweight theme uses around 40-50MB per request, and your site is blowing through 256MB, something is very wrong. Raising the limit to 512MB or 1GB doesn't fix the problem. It gives the problem more room to grow, and it means each PHP-FPM worker now reserves more RAM — which means fewer workers can run simultaneously, which means your site handles fewer concurrent visitors.

How I find what's actually eating the memory

Step 1: Check the error log path

As I mentioned above, the file path in the error message is your first clue. If it points to a specific plugin, that's where I start investigating.

Step 2: Install Query Monitor

Query Monitor is the single most useful debugging plugin for WordPress. Once activated, it shows you the peak memory usage for every page load, broken down by component. Look at the "Environment" panel — it shows current memory usage vs. the limit. If a page is using 180MB out of 256MB, you're one heavy operation away from a crash.

The "Queries" panel also helps — a plugin running hundreds of database queries per page load is usually the same one gobbling memory by loading all those results into PHP arrays.

Step 3: Isolate with a binary search

If the site is completely down and you can't install Query Monitor, I use the plugin-deactivation method — but not one by one. That takes forever if you have 30 plugins. Instead, I rename half the plugin folders at once via SSH:

cd /var/www/html/wp-content/plugins
mkdir ../plugins-disabled
mv plugin-a plugin-b plugin-c plugin-d ../plugins-disabled/

If the site comes back, the problem is in the batch you moved. Move half of them back, test again. You can usually find the culprit in 3-4 rounds instead of 30. Move the disabled plugins back once you've identified the problem:

mv ../plugins-disabled/* ./

Step 4: Check peak memory from the server side

If you want to know exactly how much memory WordPress is using on each request without installing a plugin, add this to your theme's functions.php or a must-use plugin:

add_action('shutdown', function () {
    $peak = memory_get_peak_usage(true);
    $limit = ini_get('memory_limit');
    error_log(sprintf(
        'Memory: %s MB peak / %s limit — %s',
        round($peak / 1048576, 1),
        $limit,
        $_SERVER['REQUEST_URI'] ?? 'cli'
    ));
});

This logs a line to your PHP error log on every request. After a few minutes of traffic, you can see exactly which URLs are memory-heavy. I often find that the frontend uses 60MB but a specific WooCommerce admin page uses 340MB.

The usual suspects

After diagnosing hundreds of these, the same culprits keep showing up.

Page builders editing complex pages

Elementor, Divi, and WPBakery load large PHP libraries on every request. Elementor alone adds roughly 40-80MB of overhead per page load. When you're editing a complex page with dozens of widgets, memory usage can spike well above 256MB. This is normal during editing — set WP_MAX_MEMORY_LIMIT to 512M for admin operations if you use a page builder. But if the frontend is also hitting these numbers, something else is wrong.

Backup plugins running during peak hours

UpdraftPlus, BlogVault, and similar backup plugins can consume enormous amounts of memory when compressing and uploading database dumps and file archives. If your backup runs at the same time as a traffic spike, the combined memory usage can overwhelm the server. Schedule backups for your lowest-traffic hours, usually 3-5 AM.

WooCommerce product imports and exports

Importing a CSV with 10,000 products loads a lot of data into memory. WooCommerce's built-in importer tries to batch this, but some third-party import plugins load the entire CSV into a PHP array first. I had a client whose 50,000-row product CSV was consuming 800MB on import. The fix was switching to WP-CLI with wp wc product import which handles memory more efficiently, or splitting the CSV into smaller chunks.

Plugins that load entire database tables

I've seen plugins that run SELECT * on the entire wp_posts or wp_postmeta table and store the results in a PHP array. On a WooCommerce store with 100,000 orders, that's catastrophic. These are harder to spot without reading the code, but the error log path usually points you right at the offending query.

Multiple caching or optimisation plugins conflicting

Running two object caching plugins, or a caching plugin alongside a performance plugin that also tries to cache, creates duplicate in-memory data structures. I regularly see sites running LiteSpeed Cache alongside WP Super Cache alongside W3 Total Cache. Pick one and remove the others.

The memory limit, PHP-FPM, and your server's RAM

Here's something most guides miss entirely: your WordPress memory limit interacts with PHP-FPM's pm.max_children setting to determine how many concurrent requests your server can handle. I've written about PHP-FPM worker exhaustion before — memory limits are the other side of the same coin.

The formula is simple:

Available RAM for PHP = Total Server RAM - OS overhead - MySQL/MariaDB - Redis - Nginx
Max PHP-FPM workers = Available RAM for PHP / PHP memory_limit

On a 4GB VPS running WordPress with MariaDB and Redis, it might look like:

4096MB total
- 512MB OS
- 1024MB MariaDB
- 256MB Redis
- 128MB Nginx
= 2176MB available for PHP

2176MB / 256MB per worker = 8 PHP-FPM workers

That means 8 concurrent requests. If you increase memory_limit to 512MB, you drop to 4 workers — and your site starts queuing requests under moderate traffic. If you increase it to 1GB "just to be safe," you get 2 workers, and any real traffic will bring the site down. I've seen this happen more than once: someone increases the memory limit to fix a crash, and the site becomes slower and less stable because the server can now only handle a handful of concurrent requests.

The right approach is to keep the memory limit reasonable (256MB is sensible for most WordPress sites, 512MB for WooCommerce admin operations) and fix whatever is consuming excessive memory.

When it's actually a memory leak

True memory leaks in PHP are rare because PHP releases memory at the end of each request. But they do happen in long-running processes: WP-CLI imports, Action Scheduler background jobs, and WP-Cron tasks that process thousands of items in a loop without calling wp_cache_flush().

If your site runs fine under normal traffic but crashes during background processing, look at those long-running scripts. The fix is usually batching the work and flushing the WordPress object cache between batches:

wp_cache_flush();

This clears the in-memory object cache that WordPress accumulates during a long-running process. Without it, every post and option loaded stays in memory for the entire execution.

Stop guessing, start measuring

The memory exhausted error is a symptom, not a diagnosis. Increasing the limit is a painkiller, not a cure. The cure is finding which plugin, theme, or process is consuming more memory than it should — and either fixing it, replacing it, or scheduling it differently.

If your site keeps hitting memory limits and you're not sure where to start, that's exactly the kind of problem a maintenance plan is designed to catch before it takes your site down. I monitor server resources across all my client sites and catch memory creep long before it becomes a crash.

Get in touch if you'd like help diagnosing your site's memory issues.