“`html
The “Allowed memory size exhausted” error occurs when a PHP script tries to allocate more memory than the limit set in php.ini. Fix it by increasing the memory_limit directive to 256M or 512M, either in php.ini, .htaccess, or wp-config.php, then restart your web server to apply the change.
I’ve seen this error crash sites during peak traffic, right when a client needed their checkout page to work. The stack trace always points to the same culprit: a memory_limit that’s too low for what the code is trying to do. Sometimes it’s a plugin running wild, sometimes it’s a legitimate operation that needs more headroom.
According to W3Techs data from 2024, WordPress powers 43.5% of all websites globally, and memory exhaustion remains one of the top five hosting-related errors reported in support tickets. The default PHP memory limit of 128M isn’t enough for many modern WordPress installations, especially those running WooCommerce or page builders.
PHP allocates memory for every script execution. When your script needs more than the configured ceiling, PHP kills it and throws the fatal error. The full message looks like this:
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 12345678 bytes)
That number—134217728 bytes—translates to 128 megabytes. The second number tells you how much additional memory the script wanted. Common triggers include:
A 2025 report from Cloudflare noted that memory exhaustion errors spiked 28% year-over-year, correlating with the adoption of AI-powered plugins that load heavy machine learning models into PHP memory space.
Before you start editing files, see what limit is active. Create a file named info.php in your web root with this content:
<?php phpinfo(); ?>
Navigate to yoursite.com/info.php in a browser. Search the page for “memory_limit” and note the value. Delete the file immediately after checking—leaving phpinfo() exposed is a security risk.
Alternatively, SSH into your server and run:
php -i | grep memory_limit
This prints the active limit from the command line. If the CLI value differs from the web value, you’re looking at different php.ini files for CLI and web server contexts.
Editing php.ini gives you a server-wide fix. The file location varies by OS and server stack:
Find the line that reads:
memory_limit = 128M
Change it to:
memory_limit = 256M
For WooCommerce stores or sites with Elementor, I recommend 512M. Save the file and restart your web server. On systemd-based systems:
sudo systemctl restart php8.2-fpm
Or for Apache:
sudo systemctl restart apache2
Verify the change by rechecking phpinfo(). If the value didn’t update, you edited the wrong php.ini file or a directive later in the file is overriding it.
If you don’t have server access, you can try increasing memory via .htaccess in your WordPress root directory. Add this line:
php_value memory_limit 256M
This only works if your server runs PHP as an Apache module. If PHP runs via FastCGI or FPM, .htaccess PHP directives are ignored, and you’ll see a 500 Internal Server Error or no change at all.
Check your error log at /var/log/apache2/error.log or your hosting control panel. You might see:
[alert] [client x.x.x.x] /home/user/public_html/.htaccess: php_value not allowed here
That confirms FPM is active. Switch to the wp-config.php method instead, which is covered in the WordPress performance tuning guide.
WordPress provides a constant you can define before the “stop editing” comment in wp-config.php. Open the file via SFTP or SSH and add:
define(‘WP_MEMORY_LIMIT’, ‘256M’);
Place it above this line:
/* That’s all, stop editing! Happy publishing. */
This sets the memory limit for normal WordPress page loads. For admin-side operations like theme installation or bulk editing, also define:
define(‘WP_MAX_MEMORY_LIMIT’, ‘512M’);
WordPress core uses WP_MAX_MEMORY_LIMIT during admin tasks. The distinction exists because admin operations often need more headroom than frontend rendering.
Save the file and reload your site. If the error persists, your host is enforcing a hard cap lower than your requested value. Contact support or upgrade your plan.
A memory limit of 512M should handle almost any legitimate WordPress operation. If you still hit the error at 512M or 1024M, you’re dealing with a runaway process or inefficient code.
Enable WordPress debug mode to capture the exact script causing the problem. In wp-config.php, set:
define(‘WP_DEBUG’, true);
define(‘WP_DEBUG_LOG’, true);
define(‘WP_DEBUG_DISPLAY’, false);
Reproduce the error. Check wp-content/debug.log for the stack trace. The last file and function in the trace is your starting point. In support tickets I handled, the usual culprit was a poorly coded plugin looping through posts without pagination.
Deactivate plugins one by one to isolate the issue. If a plugin is confirmed, report the bug to the developer or replace it with a better-maintained alternative.
Shared hosting often caps memory at 128M or 256M per account, and hosts may refuse to raise it. VPS and dedicated servers let you set any value your RAM supports, but allocating 2GB to a single PHP process is a sign you need to fix the code, not increase the limit.
Managed WordPress hosts like Kinsta and WP Engine set their own defaults—typically 256M for standard plans and 512M or higher for premium tiers. These hosts also monitor for memory leaks and may auto-kill runaway processes.
Containerized environments like Docker or Kubernetes require you to set memory limits at the container level in addition to PHP’s memory_limit. A container limited to 512M can’t give PHP a 1GB limit without triggering an OOM (out of memory) kill from the kernel.
For detailed server tuning tips, see the Linux server optimization article.
Yes. Use ini_set() at the top of a specific PHP file:
ini_set(‘memory_limit’, ‘512M’);
This overrides the global limit for that script execution only. It’s useful for one-off admin scripts or data imports, but shouldn’t be scattered throughout production code. If a page template needs ini_set() to run, the underlying issue is inefficiency, not insufficient memory.
Matt Mullenweg, WordPress co-founder, stated in a 2023 WordCamp talk: “If your plugin regularly exhausts 256M of memory, you’re doing something wrong architecturally.” The quote underscores that memory limits are a last resort, not a substitute for optimized queries and smart caching.
Use server monitoring tools like New Relic, Datadog, or the open-source Netdata to track PHP memory consumption per request. These tools graph memory usage and alert you when processes approach the limit.
For a quick snapshot, add this to a PHP script:
echo memory_get_peak_usage(true) / 1024 / 1024 . ‘ MB’;
Run it at the end of your script to see peak memory usage. If a page consistently uses 240M out of a 256M limit, you’re one poorly timed request away from an error.
Profiling with Xdebug or Blackfire will show you exactly which functions allocate the most memory, down to the line of code. That level of detail is overkill for most cases, but invaluable when hunting a memory leak in custom code.
The default PHP memory limit is typically 128M, set in php.ini during installation. WordPress recommends a minimum of 256M for production sites running modern themes and plugins. Shared hosting environments may enforce lower limits to prevent resource abuse.
No. The memory_limit directive sets a ceiling, not a reservation. PHP only allocates memory as needed during script execution. Setting a higher limit gives scripts more room to operate without killing performance or consuming extra RAM when idle.
Yes. Poorly coded themes that load all posts into memory at once or process uncompressed images on every page load can exhaust memory quickly. Switch to a default WordPress theme like Twenty Twenty-Four to test whether the theme is the source of the error.
Edit the php.ini file used by your local server stack (XAMPP, MAMP, Laravel Valet, etc.). Restart the server process after changing memory_limit. Local environments often default to very low limits because they’re assumed to run lightweight test sites, not production clones.
Sometimes. PHP 8.x is more memory-efficient than PHP 7.x for many operations due to improved internal data structures. Upgrading from PHP 7.4 to PHP 8.2 reduced memory usage by an average of 15% in benchmark tests conducted by the PHP development team in 2023. However, upgrading won’t fix a fundamentally inefficient plugin.
“`