WordPress PHP memory exhausted error: how to fix it

The error message is specific and direct: Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 4096 bytes) . PHP ran out of memory during execution, and the script was terminated. WordPress cannot complete the request – whether that is loading a page, saving a post, uploading an image, or running a plugin operation.

This is one of the most common WordPress errors because the default PHP memory limit on many hosting platforms is set conservatively. A basic WordPress site with a few lightweight plugins may run fine on 64 MB or 128 MB. But add WooCommerce, a page builder, a handful of media-heavy plugins, and a theme with complex templates, and memory usage grows quickly.

The fix is straightforward in most cases – increase the memory limit. But understanding why memory is being consumed helps you address the root cause rather than just raising the ceiling until the next crash.

What the error means#

PHP allocates a fixed amount of memory for each script execution. This limit exists to prevent a single runaway script from consuming all available server memory, which would crash every other process on the machine.

The memory limit applies per request, not per site or per server. Each time a visitor loads a page, PHP starts a new process (or reuses a worker), and that process gets up to memory_limit bytes of RAM. When the script tries to allocate more memory than allowed, PHP kills it with the fatal error.

The error message tells you three things:

Fatal error: Allowed memory size of 67108864 bytes exhausted
(tried to allocate 4096 bytes)
in /home/user/public_html/wp-content/plugins/some-plugin/includes/class-data.php on line 847

1. 67108864 bytes = 64 MB. This is the current memory limit.
2. tried to allocate 4096 bytes = the specific allocation that pushed it over. This is usually small because the script was already at the limit.
3. The file path and line number = the exact code that was executing when memory ran out. This is where you start investigating.

Why WordPress uses so much memory#

WordPress loads a significant amount of code on every request:

1. WordPress core – the core framework, database abstraction layer, REST API infrastructure, template system, and hook system. This alone uses roughly 20-30 MB depending on the version.
2. Active plugins – every active plugin is loaded into memory on every request, even if the plugin only does something on specific pages. A site with 30 active plugins may be loading 30 separate codebases into memory before the page even starts rendering.
3. Active theme – the theme’s functions.php, template files, and any bundled libraries load on every request.
4. Database queries – query results are held in memory. A WooCommerce product page that queries hundreds of products, variations, and metadata can consume significant memory just in query result storage.
5. Image processing – resizing images, generating thumbnails, or processing uploaded media requires loading the full image into memory. A 10 MB JPEG needs roughly 40-60 MB of RAM when decompressed for processing.

On a lean WordPress installation with five lightweight plugins, total memory usage per request might be 40-50 MB. On a WooCommerce store with 25 plugins, a page builder, and complex product queries, it can easily exceed 200 MB.

Where the memory limit is set#

PHP memory limits can be configured in multiple places, and they override each other in a specific hierarchy. Understanding this hierarchy prevents the frustrating situation where you change a value and nothing happens because a higher-priority setting overrides it.

php.ini (server level)

The server’s php.ini file sets the global default for all PHP scripts:

memory_limit = 128M

This is the ceiling. No individual script can exceed this value regardless of what WordPress or plugin code requests.

To find which php.ini file is active:

php -i | grep "Loaded Configuration File"

Or via WordPress:

wp eval "echo php_ini_loaded_file();"

PHP-FPM pool configuration

If PHP runs via PHP-FPM (which it does on most modern hosting including Hostney), the pool configuration can override php.ini values using php_admin_value :

php_admin_value[memory_limit] = 256M

Settings defined with php_admin_value cannot be overridden by .htaccess , ini_set() , or wp-config.php . They are the highest priority. This is how managed hosting platforms enforce per-site limits.

wp-config.php (WordPress level)

WordPress defines its own memory limit constant:

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

When WordPress loads, it calls ini_set('memory_limit', WP_MEMORY_LIMIT) to request this amount from PHP. This only works if:

1. PHP’s  memory_limit  is equal to or higher than the requested value, OR
2. PHP’s  memory_limit  is set to  -1  (unlimited)

If PHP is configured with memory_limit = 128M and WordPress requests 256M, PHP ignores the request. WordPress cannot override the server’s limit.

WordPress also has a separate constant for admin operations:

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

This applies to wp-admin pages, which often need more memory than front-end pages (loading plugin settings, processing imports, running updates).

.user.ini or .htaccess

On some hosting platforms, you can set PHP values via a .user.ini file in your WordPress root:

memory_limit = 256M

Or via .htaccess on Apache:

php_value memory_limit 256M

These work on some hosts and are silently ignored on others, depending on whether the host allows per-directory PHP configuration overrides.

How to fix the error#

Step 1: Increase the memory limit

The immediate fix is to raise the limit. Start with 256M, which handles most WordPress sites comfortably.

On Hostney, the PHP memory limit is set at the platform level and is not user-configurable through PHP Manager. The default is generous enough for most WordPress sites. If your site needs more memory, contact support and they will adjust it for your account.

Via wp-config.php (add before the line that says “That’s all, stop editing”):

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

Via .user.ini (create the file in your WordPress root if it does not exist):

memory_limit = 256M

After changing the value, verify it took effect:

wp eval "echo ini_get('memory_limit');"

If the value did not change, a higher-priority setting is overriding your change. Check PHP-FPM pool configuration or contact your host.

Step 2: Identify what is consuming memory

Raising the limit is a bandage. If your site regularly hits 256 MB, something is consuming more memory than it should. The file path in the error message is your starting point.

If the error points to a plugin, that plugin is the primary consumer. Check:

• Is the plugin up to date? Older versions may have memory leaks that newer versions fix.
• Is the plugin appropriate for your site’s scale? Some plugins are designed for small sites and do not scale well to thousands of posts or products.
• Can you replace it with a lighter alternative? Many popular plugins have lean alternatives that accomplish the same thing with less overhead.

If the error points to wp-includes/class-wpdb.php, the problem is database query results consuming too much memory. This is common on WooCommerce stores with thousands of products when a page queries large datasets without pagination.

If the error happens during image upload, the image itself is too large for the memory limit to handle. A 5000×4000 pixel JPEG at 24-bit color depth requires approximately 60 MB of uncompressed memory just to hold the pixel data, before any processing begins. Either resize images before uploading or increase the memory limit to handle your largest images.

Step 3: Reduce memory usage

If you would rather fix the root cause than keep raising the limit:

Deactivate unused plugins. Every active plugin consumes memory on every request even if it does nothing on that page. If you have plugins installed that you activated once and forgot about, deactivate them. Check your plugin list for plugins you no longer use.

Replace heavy plugins with lighter alternatives. Some categories of plugins are known for high memory usage:

• All-in-one SEO plugins (Yoast, Rank Math) – consider whether you need every feature they offer
• Page builders (Elementor, Divi) – use more memory than the block editor
• All-in-one security plugins – often duplicate functionality that the server already provides. See Wordfence and server-level security: why you need both for a discussion of where plugin security ends and server security begins.

Limit post revisions. WordPress stores every revision of every post in the database. On a site with thousands of posts, loading revision data for bulk operations consumes significant memory:

define('WP_POST_REVISIONS', 5);

Use object caching. Without object caching, WordPress re-runs the same database queries on every page load and holds the results in memory. With object caching (Memcached or Redis), frequently-used data is cached outside PHP and retrieved without running queries. This reduces per-request memory usage because query result sets are smaller. On Hostney, enable Memcached from the control panel – the Hostney Cache plugin handles the integration automatically. For a deeper look at how caching fits into WordPress performance, see How Hostney handles WordPress cache purging automatically.

Optimize autoloaded options. WordPress loads all autoload = 'yes' options from wp_options into memory on every request. Plugins that store large serialized arrays as autoloaded options inflate memory usage site-wide. Check what is autoloaded:

wp db query "SELECT option_name, LENGTH(option_value) AS size FROM wp_options WHERE autoload = 'yes' ORDER BY size DESC LIMIT 20;"

If you see entries with sizes in the hundreds of kilobytes or megabytes, those are candidates for cleanup or for switching their autoload flag to ‘no’.

Memory limits for WooCommerce#

WooCommerce is the most common cause of memory exhaustion on WordPress. Product pages with many variations, cart calculations with complex shipping rules, and checkout processes that load payment gateways all consume significant memory.

Recommended minimums for WooCommerce:

• Small store (under 100 products): 256 MB
• Medium store (100-1000 products): 256-384 MB
• Large store (1000+ products, complex variations): 384-512 MB

If your WooCommerce store regularly hits memory limits during normal browsing (not just admin imports or bulk operations), the problem is likely a plugin that loads too much product data at once. The WooCommerce core team has optimized memory usage significantly in recent versions – make sure WooCommerce and all extensions are up to date.

Memory exhaustion during specific operations#

Some operations are inherently memory-intensive and may hit limits even on sites that normally run fine.

Plugin and theme updates. WordPress downloads and extracts zip files during updates, which requires memory for the archive handling. If updates consistently fail with memory errors, increase WP_MAX_MEMORY_LIMIT (the admin-specific limit) to 512M.

WordPress imports. Importing large XML files (WXR format) loads the entire file into memory for parsing. For large imports, use WP-CLI instead of the browser-based importer:

wp import large-file.xml --authors=create

WP-CLI runs in the CLI SAPI, which may have different (often higher) memory limits than the web SAPI. It also does not have the web request timeout, so long imports can complete without being killed.

Image regeneration. Regenerating thumbnails for thousands of images (after a theme change) processes each image in memory. Use WP-CLI with the --batch-size option to process images in smaller groups:

wp media regenerate --batch-size=50

Database operations. Plugins that run search-replace operations, database optimizations, or bulk metadata updates may load large result sets into memory. Break these into smaller batches when possible.

How to check current memory usage#

You can check what your site actually uses versus what is allocated.

Via WP-CLI:

wp eval "echo 'Peak: ' . round(memory_get_peak_usage(true) / 1024 / 1024, 2) . ' MB' . PHP_EOL . 'Limit: ' . ini_get('memory_limit') . PHP_EOL;"

Via a temporary code snippet in functions.php:

add_action('shutdown', function() {
    if (current_user_can('manage_options') && !wp_doing_ajax()) {
        $peak = round(memory_get_peak_usage(true) / 1024 / 1024, 2);
        $limit = ini_get('memory_limit');
        error_log("Memory: {$peak} MB / {$limit}");
    }
});

This writes peak memory usage to the error log on every page load (admin users only). Run it for a day, then check the log to see which pages use the most memory.

Via Query Monitor plugin. The Query Monitor plugin shows memory usage per page in its admin bar panel. This is the easiest way to identify which pages are close to the limit.

The difference between memory_limit and WP_MEMORY_LIMIT#

This causes significant confusion. They are not the same setting and they serve different purposes.

memory_limit (PHP setting) is the hard ceiling. PHP will never allocate more than this value for a single script execution. It is set in php.ini, PHP-FPM pool configuration, or .user.ini.

WP_MEMORY_LIMIT (WordPress constant) is what WordPress requests from PHP via ini_set() . It can raise the effective limit up to (but never above) PHP’s memory_limit . If PHP allows 512M and WordPress requests 256M, the effective limit is 256M. If PHP allows 128M and WordPress requests 256M, the effective limit is 128M.

WP_MAX_MEMORY_LIMIT (WordPress constant) applies only to wp-admin pages. WordPress sets this separately because admin operations (imports, updates, bulk edits) typically need more memory than front-end page loads.

For the setting to work as expected, PHP’s memory_limit must be equal to or higher than WordPress’s requested value. On managed hosting platforms like Hostney, the PHP memory limit is configured at the PHP-FPM pool level by the platform. If you need more than the default allocation, contact support.

When increasing memory is not the answer#

If you find yourself needing 512 MB or more for a normal WordPress site (not WooCommerce, not a large multisite), something is wrong with the codebase, not the limit.

Signs that a plugin or theme has a memory leak or inefficiency:

• Memory usage grows linearly with the number of posts or pages
• The same page uses 50 MB on one load and 200 MB on the next
• Memory usage increases over time without any content changes
• A single plugin accounts for more than half the total memory usage

In these cases, replacing or updating the offending plugin is a better solution than increasing the limit. A memory limit exists to protect the server – setting it to 1 GB to accommodate a broken plugin just delays the crash and puts other resources at risk.

How Hostney handles PHP memory#

Per-site PHP containers. Each site runs in its own isolated PHP-FPM container. A memory-intensive operation on one site does not affect PHP memory availability for other sites. If one site’s PHP process hits its memory limit and crashes, only that container restarts – other sites continue uninterrupted.

Generous default memory. The platform sets a generous PHP memory limit by default. Other PHP settings like max execution time, upload sizes, and error reporting are configurable per site through Hosting > PHP Manager > Variables. If your site needs a memory limit increase beyond the default, support can adjust it for your account.

Object caching with Memcached. Hostney provides per-account Memcached instances that reduce PHP memory usage by caching database query results outside of PHP. The Hostney Cache plugin integrates automatically – you enable Memcached from the control panel and the plugin handles the object-cache.php drop-in installation.

Monitoring. If your site consistently uses memory close to the limit, the PHP error log captures the exhaustion events with file paths and line numbers, making it straightforward to identify which component is consuming the most memory.

Summary#

The PHP memory exhausted error means a script tried to use more RAM than PHP allows. The immediate fix is increasing memory_limit in PHP configuration and WP_MEMORY_LIMIT in wp-config.php. The long-term fix is identifying which plugin, theme, or operation is consuming excessive memory and addressing it directly.

256 MB is a reasonable default for most WordPress sites. WooCommerce stores may need 384-512 MB. If you need more than that for a standard site, investigate the codebase rather than raising the limit further. For a complete reference of WordPress errors and their quick fixes, see How to fix the most common WordPress errors.