Fix WordPress "Allowed Memory Size Exhausted" Fatal Error

The "Allowed Memory Size of X Bytes Exhausted" error is PHP running out of RAM allocated to your site's process. It typically looks like this:

Fatal error: Allowed memory size of 134217728 bytes exhausted
(tried to allocate 20971520 bytes) in
/var/www/html/wp-content/plugins/some-plugin/big-class.php on line 482

The number 134217728 is 128 MB in bytes (128 × 1024 × 1024). When PHP tries to allocate more memory than the limit allows, it throws this fatal error and your page either shows a WSOD or a partial broken layout.

Why the default limit is often too low

WordPress sets a default memory limit of 40 MB. That was reasonable in 2008 when WordPress was simpler. Modern WordPress sites run page builders, WooCommerce, SEO plugins, caching plugins, and custom post type frameworks simultaneously. A complex WooCommerce product page can easily require 64-128 MB just to render.

WordPress also tries to bump the limit itself:

// From wp-settings.php
if ( ! defined( 'WP_MEMORY_LIMIT' ) ) {
    define( 'WP_MEMORY_LIMIT', '40M' );
}

And it attempts to set the PHP limit at runtime if its limit is higher:

@ini_set( 'memory_limit', WP_MEMORY_LIMIT );

The @ suppresses errors if your host does not allow PHP memory changes via ini_set. On many shared hosts, the PHP memory limit is set in the server config and cannot be overridden by PHP code - only by editing php.ini, .htaccess, or asking support.

Step 1 - Increase the limit in wp-config.php

The first thing to try. Open wp-config.php and add these before the /* That's all, stop editing! */ line:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // for admin area operations

WP_MEMORY_LIMIT covers frontend requests. WP_MAX_MEMORY_LIMIT covers admin requests - things like bulk-editing posts, processing imports, or running WooCommerce reports.

Step 2 - Increase via php.ini

If wp-config.php alone does not work, your host may be capping the limit at the server level. Create or edit php.ini:

On cPanel hosts you can often place a php.ini in your web root:

memory_limit = 256M

On VPS/dedicated, edit the main php.ini:

sudo nano /etc/php/8.1/fpm/php.ini   # PHP-FPM
# or
sudo nano /etc/php/8.1/cli/php.ini   # CLI

Find the line:

memory_limit = 128M

Change it to:

memory_limit = 256M

Restart PHP-FPM:

sudo systemctl restart php8.1-fpm

Step 3 - Increase via .htaccess (Apache only)

On Apache servers, you can set the memory limit per directory:

php_value memory_limit 256M

This will not work on Nginx + PHP-FPM setups. Nginx does not process PHP directives in .htaccess.

Step 4 - Find what is consuming memory

Increasing the limit treats the symptom, not the cause. 256 MB should be enough for almost any WordPress site. If you are hitting 256 MB regularly, something is wrong.

Use Query Monitor

Install the free Query Monitor plugin. It shows peak memory usage for every request in the admin bar. You can immediately see if a particular page is consuming dramatically more memory than others.

Enable WP_DEBUG logging

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

The memory exhaustion error with a full stack trace will be written to /wp-content/debug.log. The stack trace shows you exactly which plugin class or function triggered the allocation.

Memory profiling with Xdebug (development only)

For deeper investigation in a local or staging environment:

# Install Xdebug
sudo apt install php8.1-xdebug

# In php.ini, enable memory profiling
xdebug.mode = profile
xdebug.output_dir = /tmp/xdebug

Then open the cachegrind files in KCacheGrind or Webgrind to see which functions allocate the most memory.

Common culprits

WooCommerce with large product catalogues

WooCommerce loads significant data structures for cart calculations, inventory checks, and price rules. Sites with 10,000+ products often need 256 MB or more. Check whether the memory spike happens on specific WooCommerce pages (cart, checkout, account) or everywhere.

Page builders (Elementor, Divi, WPBakery)

Elementor in particular loads a large amount of JavaScript and CSS data structures in PHP before rendering. The Elementor team has been improving memory usage, but complex pages with many widgets still spike hard.

ACF (Advanced Custom Fields) with deep nested fields

Loading a post with hundreds of ACF fields, especially nested repeater fields and flexible content blocks, can allocate significant memory. Each field value is loaded into an object in PHP memory.

Large image uploads

PHP loads the entire image into memory when processing uploads. A 20 MB RAW photograph requires over 150 MB of memory to open and resize. The formula is roughly: width × height × 3 bytes × 2 (original + resized copy). A 6000×4000 px image = ~140 MB just to open.

Fix: resize images before uploading, or use a hosted image processing service. If you must process large images on the server, the WP memory limit needs to be at least 256 MB.

get_posts() without limits

Developers sometimes call get_posts() or WP_Query without a posts_per_page limit, accidentally loading thousands of posts into memory at once:

// Dangerous on large sites:
$all_posts = get_posts( [ 'post_type' => 'product' ] );

// Safe:
$posts = get_posts( [
    'post_type'      => 'product',
    'posts_per_page' => 100,
    'fields'         => 'ids', // only load IDs, not full post objects
] );

wp_options autoload bloat

WordPress loads all autoload = 'yes' options on every request. Some plugins store large serialised datasets as autoloaded options. Check your autoloaded options size:

SELECT SUM( LENGTH( option_value ) ) as total_bytes, COUNT(*) as total_rows
FROM wp_options
WHERE autoload = 'yes';

If total_bytes is over 1 MB, you have a problem. Use the Transients Manager plugin to identify and clean up bloated options.

Setting the right limits for different server sizes

Setting memory limit too high on a small server is counter-productive. If every PHP worker can use 256 MB and you have 20 workers, that is 5 GB of potential RAM usage on a 2 GB server - which triggers OOM kills and takes down the whole server.

WP-CLI memory limits

Running WP-CLI commands (imports, exports, bulk operations) uses the CLI php.ini, not the web server one. Set the memory limit for CLI separately:

# Run a single command with higher memory
php -d memory_limit=512M $(which wp) import big-file.xml

# Or set it permanently in wp-cli.yml
php:
  memory_limit: 512M

Checking what your current limits actually are

Add this temporarily to confirm which limits are actually in effect:

// Paste in a test plugin or functions.php, view the page, then remove
add_action( 'wp_footer', function() {
    if ( ! current_user_can( 'manage_options' ) ) return;
    echo '<pre>PHP memory_limit: ' . ini_get( 'memory_limit' ) . '</pre>';
    echo '<pre>WP_MEMORY_LIMIT: ' . WP_MEMORY_LIMIT . '</pre>';
    echo '<pre>Peak usage: ' . size_format( memory_get_peak_usage( true ) ) . '</pre>';
} );

This tells you the real limit PHP is enforcing (not just what you set in wp-config.php), and the actual peak memory usage for that page load.

Related reading

• WordPress Plugin Performance Audit
• Fix WordPress Slow Admin Dashboard
• WordPress wp-config.php Tweaks