How to Diagnose and Resolve Memory Exhaustion Errors at Pressable

See our guide to accessing WordPress/PHP error logs here: https://pressable.com/knowledgebase/accessing-wordpress-error-logs/

A memory exhaustion error occurs when a PHP process exceeds its allocated memory limit. These errors look like:

PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 20480 bytes) in /path/to/plugin/class.php on line 125

On Pressable, each PHP worker has a 512 MB memory limit. When this limit is reached, PHP stops immediately and logs a fatal error. Multiple workers can hit this limit independently during high-traffic periods, which is why you might see several errors happening at once.

Important: The file path and line number in the error show where PHP gave up, not what caused the problem. Understanding this distinction is critical to fixing the issue.

Understanding Memory Exhaustion: The Error Message and Investigation

Think of PHP memory like a bucket filling with water. The error message shows you where the bucket finally overflowed (the last drop added), but this might or might not tell you what filled most of the bucket.

The file and line number show where PHP ran out of room; sometimes that’s directly related to the cause, and sometimes it’s just the unlucky operation that happened to run when memory was already exhausted.

What the file path tells you (and what it doesn’t)

When you see a file path in the error (like /wp-content/plugins/some-plugin/file.php), it means that specific file was involved when memory ran out. This could mean:

• Direct cause: That plugin is genuinely consuming excessive memory through inefficient code or a bug
• Indirect cause: That plugin made a reasonable request, but memory was already 90% full from earlier operations
• Coincidental timing: That plugin was simply the next thing to run after something else exhausted memory

You won’t know which scenario applies without investigation.

What this means for troubleshooting

Don’t assume the file mentioned in the error is broken, but don’t dismiss it either. Instead:

• Note which plugin or file appears in the error
• Check if that same file appears in multiple errors (a pattern suggests a high likelihood that it’s involved)
• Look at log entries before the fatal error to see what else was running
• Test with that plugin disabled to see if the issue persists
• Consider whether that plugin’s function (reports, imports, image processing) is inherently memory-intensive

The error message is a clue, not a diagnosis. Treat it as a starting point for investigation, not a definitive answer.

Common causes of memory exhaustion

Memory exhaustion typically involves:

• Large database queries loading thousands to millions of rows
• Autoloaded data that loads on every single page view
• Multiple plugins stacking their memory overhead
• Import or export operations processing too much data at once
• API calls returning large payloads
• Image processing or regeneration
• High number of page revisions

The 512 MB context

Is 512 MB a lot or a little? Here’s some perspective:

Site Configuration	Typical Memory Usage
Fresh WordPress install	30-50 MB
WordPress + basic theme + 10-15 plugins	80-150 MB
WooCommerce site with typical extensions	150-250 MB
Page builder (Elementor, Divi) editing a complex page	200-400 MB
Large import or report generation	300-500+ MB

Most sites run comfortably under 200 MB for normal page loads. Memory exhaustion usually means either:

1. Progressive exhaustion: Your site gradually crept toward the limit as you added features, and finally tipped over
2. Spike exhaustion: A specific action (import, report, regeneration) instantly demands more than 512 MB

What Actually Consumes PHP Memory

PHP memory holds everything loaded into the process during a single request. Here’s what builds up:

Database operations: When WordPress runs a query, it loads the results into PHP arrays. A query returning 10,000 posts with metadata can easily consume 100+ MB.

See our guide on using Query Monitor to identify slow or bloated queries: https://pressable.com/knowledgebase/using-wordpress-query-monitor-plugin/

Autoloaded data: WordPress loads certain options into memory on every page view, whether they’re needed or not. Think of it like carrying a full backpack everywhere when you only need one book. Individual plugins often store settings, cache data, or serialized arrays in autoloaded options.

See our guide to optimizing and reducing autoloaded data here: https://pressable.com/knowledgebase/speed-up-your-wordpress-site-by-optimizing-autoloaded-data/

Plugin overhead: Each active plugin loads its code, classes, and dependencies. A site with 30+ plugins might load 50-100 MB of code before doing any actual work.

REST API and AJAX: API responses build arrays or objects in memory. A single endpoint returning detailed product data for 500 items can spike memory dramatically.

Object cache operations: When data is retrieved from cache, it’s unserialized back into PHP arrays and objects. Cached queries or transients containing large datasets still consume memory when loaded.

Image processing: Manipulating images (resizing, cropping, regenerating thumbnails) loads the full image into memory. A 5 MB JPEG might require 40-50 MB of RAM to process.

High number of page revisions: Each revision is stored as its own row in the database. If revision count gets too high, editing or saving a page may require WordPress to load an excessive amount of data at once, using up all available RAM. This can be exacerbated by the additional memory needs of a page builder.

See our guide on resolving 500 errors when saving posts in Elementor here: https://pressable.com/knowledgebase/fix-elementor-server-error-500-error-when-saving-posts/

Section 1: Non-Technical Guide

Goal: Help site managers and non-technical agency staff identify symptoms, understand what’s happening, and isolate problem areas before escalating to developers.

This section uses Pressable and WordPress dashboard tools only (no SSH or WP-CLI required). However, resolving some underlying causes may still require technical assistance.

Common Symptoms

• White screen of death or 500 error
• Admin pages timing out during report generation, imports, or editing
• Sluggish or incomplete page loads
• Log entries referencing “Allowed memory size exhausted”
• Repeated PHP warnings or notices before a fatal error

Understanding What You’re Seeing

When you check your error logs, you’ll see entries like this:

PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 20480 bytes) in /wp-content/plugins/woocommerce/includes/class-wc-product.php on line 847

Breaking this down:

• “Allowed memory size of 536870912 bytes”: This is 512 MB, your worker’s limit
• “tried to allocate 20480 bytes”: PHP needed 20 KB more but couldn’t get it
• File path and line number: Where PHP stopped, NOT necessarily what caused the problem
• The real culprit: Usually something that ran earlier and consumed most of the 512 MB

Step 1: Check for Recent Changes

If at all possible, the following testing should be done on a new staging clone of the site, not directly on the production site. Keep in mind, though, that in rare cases the live site’s traffic levels may be needed to reproduce the error.

Start by reviewing what changed recently:

Plugins and themes:

• Disable any newly installed or updated plugins
• Check if the error started immediately after an update by reviewing timestamps in error logs
• Note that even small plugins can trigger issues if they interact badly with existing ones

Content operations:

• Review recent large media uploads (especially if you bulk-uploaded)
• Check for bulk content edits or imports still in progress
• Look for stuck background processes (imports, migrations, backups)

Integrations and automations:

• Verify scheduled tasks aren’t running during high-traffic periods
• Check if any new API connections or syncs were added
• Confirm third-party services aren’t sending excessive webhook calls

Step 2: Use Pressable and WordPress Tools

Pressable PHP log viewer:

From your site overview in the Pressable dashboard:

1. Navigate to Logs → PHP Logs
2. Filter by severity: select Fatal to see only critical errors
3. Review several log entries before the memory error to identify patterns

Look for the same plugin or process appearing repeatedly. The error might mention different files each time, but if they’re all from the same plugin, that’s your lead.

If you need to search logs more thoroughly, use the Send PHP Logs option to email yourself the log file, then search it locally.

Cache management:

Go to Performance → Object Cache from your Pressable dashboard and hit the “Flush Object Cache” button to clear stale data. Note: This won’t fix the underlying issue, but it can help rule out cache-related problems and give you a clean slate for testing.

Safe plugin isolation:

To test whether a plugin is causing the issue:

1. Disable your plugins from the Pressable Dashboard under the WordPress → Plugins menu
2. Alternatively, use File Manager to rename your wp-content/plugins folder to wp-content/plugins-disabled to prevent WordPress from loading them
3. If the error stops, rename it back to wp-content/plugins and disable plugins one by one through WordPress admin or Pressable control panel. When the error recurs, the last plugin activated is your likely culprit.

Database and autoload checks:

Oversized autoloaded data can inflate every page load’s memory footprint before any real work begins. This is one of the most common causes of progressive memory exhaustion.

Check and optimize autoloaded data using our guide: Speed Up Your WordPress Site By Optimizing Autoloaded Data

Warning signs:

• Any single autoloaded option over 0.25 MB is problematic and can directly cause memory exhaustion
• Total autoloaded data should remain below 1 MB (ideally no higher than 0.5 MB for optimal performance)

Note: Checking and optimizing autoload requires some technical comfort or developer assistance.

WordPress Site Health:

1. Go to Tools → Site Health in WordPress admin
2. Review the Info tab for memory limit confirmation
3. Check the Status tab for flagged performance issues
4. Look for warnings about REST API delays, heavy plugins, or database problems

Step 3: Recognize High-Risk Scenarios

Some legitimate operations can temporarily exceed 512 MB. These aren’t necessarily “bugs” but rather resource-intensive tasks that need to be managed carefully:

Operation	Why It Uses Memory	How to Handle
WooCommerce reports and exports	Loads all order data with metadata into arrays	Filter by date range; export in smaller chunks
Page builder editing (Elementor, Divi, etc.)	Loads all widgets, scripts, and preview data at once	Break complex pages into smaller sections or templates
Bulk REST API updates	Processes multiple items in a single request	Implement batching (50-100 items per request)
Backup or import plugins	Reads and processes entire database or file sets	Schedule during low-traffic periods; use incremental backups; consider relying on Pressable’s automated backups instead
Image regeneration	Loads full-size images into memory for processing	Process in batches of 50-100; use WP-CLI during off-hours
Analytics or tracking plugin syncs	Retrieves and processes historical data	Limit sync ranges; schedule during off-peak times

Step 4: Collect Details Before Escalating

Whether you’re contacting your developer, agency, or Pressable support, provide:

From error logs:

• The complete error message (copy/paste, don’t screenshot; this makes it much easier to copy parts of the error into things like backend searches of the site’s code base)
• Timestamp of when it occurred
• 5-10 lines of log entries before the error (these often show what was actually running)

About the trigger:

• What action caused it (saving a post, generating a report, loading a specific page)
• Whether it happens every time or intermittently
• If it started after a recent change

Environment details:

• Recent plugin or theme updates
• Any new integrations or automations
• Traffic patterns (did this happen during high traffic?)
• Summary of the testing and fixes that you have already tried

This information dramatically speeds up troubleshooting.

Section 2: Technical Guide

Goal: Provide developers and technical agency staff with WP-CLI commands, profiling tools, and optimization strategies to identify and resolve memory exhaustion at the code level.

Step 1: Confirm and Examine the Error

View recent PHP errors via WP-CLI:

wp --skip-plugins --skip-themes php-errors

This prints the latest PHP errors without loading plugins or themes, which is useful if the site is broken.

Search archived logs for memory-related errors:

From the /tmp directory:

find . -name 'php*' -exec zgrep -ahi 'memory' {} \; | sort

This searches through archived log files for any mention of memory issues and sorts them chronologically.

What to look for:

• Patterns in file paths (same plugin or sequence of errors appearing repeatedly)
• Timing (errors clustered during backups, imports, or high traffic)
• Progression (warnings about memory usage before the fatal error)

Step 2: Identify High Autoload Data

Autoloaded data is loaded into memory on every single request, whether it’s needed or not. This is often the foundation of memory exhaustion problems.

List the 20 largest autoloaded options:

wp option list --autoload=on --fields=option_name,size_bytes | sort -n -r | head -20

What the output means:

• Each line shows an option name and its size in bytes
• Anything over 262,144 bytes (0.25 MB) is excessive
• Common culprits: plugin cache data, serialized arrays, imported settings

Calculate total autoload size:

wp db query "SELECT SUM(LENGTH(option_value)) / 1048576 AS total_autoload_mb FROM wp_options WHERE autoload='yes';"

What’s healthy:

• Under 0.5 MB: Excellent
• 1 MB: Acceptable but monitor it
• Over 1 MB: Problematic and likely contributing to memory issues

How to fix: See our complete guide: Speed Up Your WordPress Site by Optimizing Autoloaded Data

Step 3: Profile Plugin and Query Load

Install Query Monitor:

Query Monitor is a debugging plugin that shows real-time memory usage, database queries, and component overhead. However, Query Monitor itself can be resource-intensive and wherever possible should be used on a fresh clone rather than the production site.

1. Install and activate Query Monitor
2. Load the page or perform the action that triggers memory exhaustion
3. Check the Query Monitor panel (top of admin bar)

What to examine:

Queries by Component tab:

• Shows which plugins, themes, or core components are generating queries
• Look for components running hundreds of queries on a single page load
• Identify queries without proper limits (unbounded queries)

Memory Usage panel:

• Shows peak memory for the request
• Components using over 100 MB are suspicious
• Compare memory across different pages to identify patterns

Common heavy components:

• Advanced Custom Fields (ACF) with many field groups
• Elementor or Divi with complex pages
• WooCommerce with large catalogs
• Analytics or tracking plugins syncing data
• Custom queries without limits

Testing approach:

1. Deactivate suspected heavy plugins
2. Clear all caches (wp cache flush)
3. Reload the problem page and check Query Monitor again
4. If memory drops significantly, you’ve found a culprit

See our guide: Using the WordPress Query Monitor Plugin

Long-term monitoring:

Use APM Insights in your Pressable dashboard:

• Navigate to Performance → scroll down to the Application Performance Monitoring (APM) section to activate APM for 5-30 minutes
• Identify spikes correlated with specific events or times
• Record your findings
• Track improvement after optimizations

See our guide: Using APM Insights to Troubleshoot Performance Issues

Step 4: Reduce Plugin and Query Bloat

Remove redundant functionality:

Multiple plugins providing similar features compound overhead:

• Caching plugins: These cannot function properly at Pressable due to our built-in caching layers. Remove W3 Total Cache, WP Super Cache, etc. Our caching guide: Caching types available at Pressable
• Backup plugins: Consider whether you need real-time backups when Pressable provides daily backups (with additional redundant backups via the free Jetpack Security license we provide for every site)
• Analytics plugins: Evaluate whether you need multiple tracking scripts

Optimize cron tasks:

Background tasks can spike memory during unexpected times:

wp cron event list

Review scheduled tasks:

• Disable or reschedule tasks that call external APIs
• Limit import/sync operations to off-peak hours
• Remove abandoned tasks from deactivated plugins

Prevent recursive actions:

Code patterns that can cause instant memory exhaustion:

• save_post hooks that trigger additional saves (infinite loops)
• REST API callbacks that fire on every item in a batch
• Filters that call database queries inside loops
• Actions that recursively call themselves without exit conditions

WooCommerce-specific optimizations:

• Filter reports by date range (avoid loading all orders)
• Limit product query results with pagination
• Disable unnecessary product meta loading
• Export data in chunks (100-500 products at a time)

Page builder optimizations:

• Break large pages into reusable templates or sections
• Reduce the number of nested widgets per page
• Disable widget features you don’t use
• Use global widgets instead of duplicating content

Step 5: Advanced Cleanup and Testing

Clear all caches:

wp cache flush

This clears object cache and resets transients, giving you a clean baseline for testing.

Binary isolation testing:

When you have many plugins and can’t identify the culprit:

1. Deactivate half of all plugins
2. Test if the error still occurs
3. If it stops, the problem is in the disabled half; if it continues, it’s in the active half
4. Repeat the process, dividing the problematic group in half each time
5. Continue until you isolate the specific plugin

Reproduce with debugging:

wp --skip-plugins --skip-themes php-errors

Keep this command running in a terminal while you reproduce the issue. You’ll see errors in real-time, which helps identify the exact sequence of events.

Monitor autoload growth:

After each round of testing:

wp db query "SELECT SUM(LENGTH(option_value)) / 1048576 AS total_autoload_mb FROM wp_options WHERE autoload='yes';"

If this number grows significantly after activating a specific plugin, that plugin is storing excessive autoload data.

Step 6: Edge Cases and Advanced Causes

Serialized arrays in options:

Some plugins store massive serialized arrays in the options table. When unserialized, these can instantly consume hundreds of MB. Check for:

wp db query "SELECT option_name, LENGTH(option_value) as bytes FROM wp_options WHERE option_value LIKE 'a:%' AND LENGTH(option_value) > 1000000 ORDER BY bytes DESC LIMIT 10;"

This finds serialized arrays (a:) larger than 1 MB.

Recursive hook problems:

The save_post hook is commonly misused:

// BAD: This can cause infinite recursion

add_action('save_post', 'my_function');

function my_function($post_id) {

    wp_update_post(array('ID' => $post_id, 'post_status' => 'publish'));

    // This triggers save_post again!

}

If you suspect recursive hooks, check your theme’s functions.php and active plugin files for actions that call save functions.

Unbounded queries:

Queries without limits can load thousands of rows:

// BAD: No limit

$posts = get_posts(array('post_type' => 'product'));

// GOOD: Limited and paginated

$posts = get_posts(array(

    'post_type' => 'product',

    'posts_per_page' => 50,

    'paged' => $page

));

Use Query Monitor to identify plugins making these queries.

Object cache exhaustion:

When object cache data is too large, retrieving it from cache can be just as memory-intensive as querying the database. If you see object-cache.php in error messages:

1. The file itself isn’t the problem (it’s a read-only symlink)
2. The issue is the data being retrieved from cache
3. Identify which plugin is storing excessive cached data
4. Clear cache and monitor which plugin repopulates it with large datasets

Summary

Key takeaways:

• Each PHP worker at Pressable has a 512 MB memory limit per request; this ensures platform stability and fair resource distribution
• Workers can fail independently when overloaded, which is why you might see multiple errors during high traffic
• The file path in error messages shows where PHP stopped, not what caused the problem
• Most memory exhaustion stems from site-level code inefficiency, data bloat, or resource-intensive operations
• Progressive exhaustion happens over time as a site adds features; spike exhaustion happens from specific actions

Troubleshooting path:

1. Check error logs for patterns (not just the last error)
2. Review recent changes (plugins, imports, integrations)
3. Measure autoload data size (should be under 1 MB)
4. Use Query Monitor or APM Insights to profile memory usage
5. Isolate problematic plugins through systematic testing
6. Optimize queries, cron tasks, and resource-intensive operations

Getting additional help:

• Technical optimization guides: pressable.com/knowledgebase/
• Contact your developer or agency with detailed logs and reproduction steps
• Pressable support can assist with platform-level questions and provide additional insights when you share logs, timestamps, and troubleshooting steps already taken

Memory Upgrade Option

For sites with consistently high memory requirements that have been optimized and still need additional resources, Pressable offers a per-worker memory upgrade. Account owners can purchase an upgrade from the default 512 MB to a maximum of 2 GB per PHP worker.

This upgrade is suitable for sites that:

• Have already implemented optimization best practices
• Legitimately require more memory for complex operations (large-scale e-commerce, heavy data processing, etc.)
• Cannot further reduce memory usage through code optimization

To discuss memory upgrades with the Pressable sales team or determine if your site is a good candidate:

• Live chat: Available on pressable.com
• Contact form: pressable.com/contact/

Note that upgrading memory works best when combined with the optimization strategies in this guide. Increased memory limits won’t resolve inefficient code, runaway processes, or excessive autoload data.