---
title: How to Diagnose and Resolve Memory Exhaustion Errors at Pressable
url: "https://pressable.com/knowledgebase/how-to-diagnose-and-resolve-memory-exhaustion-errors-at-pressable/"
published: 2025-11-26
modified: 2026-02-11
author: Nox Dineen-Porter
---
See our guide to accessing WordPress/PHP error logs here:
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 install30-50 MBWordPress + basic theme + 10-15 plugins80-150 MBWooCommerce site with typical extensions150-250 MBPage builder (Elementor, Divi) editing a complex page200-400 MBLarge import or report generation300-500+ MBMost 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:
**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:
**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:
## **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](https://pressable.com/knowledgebase/how-to-clone-website-to-staging/) 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](https://pressable.com/knowledgebase/accessing-wordpress-error-logs/):**
From your site overview in the Pressable dashboard:
1. Navigate to **Logs → PHP Log**s
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:**
See our guide on [how to flush the object cache](https://pressable.com/knowledgebase/how-to-purge-cache-in-wordpress-cdn/) for up-to-date instructions and screenshots.
**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](https://pressable.com/knowledgebase/wordpress-plugin-and-theme-actions-through-mypressable-control-panel/) under the **WordPress → Plugins & Themes** menu
2. Alternatively, [use File Manager](https://pressable.com/knowledgebase/using-wp-file-manager-with-pressable/) 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](https://pressable.com/knowledgebase/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 exportsLoads all order data with metadata into arraysFilter by date range; export in smaller chunksPage builder editing (Elementor, Divi, etc.)Loads all widgets, scripts, and preview data at onceBreak complex pages into smaller sections or templatesBulk REST API updatesProcesses multiple items in a single requestImplement batching (50-100 items per request)Backup or import pluginsReads and processes entire database or file setsSchedule during low-traffic periods; use incremental backups; consider relying on [Pressable’s automated backups](https://pressable.com/knowledgebase/accessing-backups/) insteadImage regenerationLoads full-size images into memory for processingProcess in batches of 50-100; [use WP-CLI](https://pressable.com/knowledgebase/how-to-use-wp-cli/) during off-hoursAnalytics or tracking plugin syncsRetrieves and processes historical dataLimit sync ranges; schedule during off-peak times Info:If these operations are causing memory exhaustion, the solution is to break them into smaller pieces or schedule them during low-traffic periods. Simply running them again will likely produce the same error.
### **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](https://pressable.com/knowledgebase/speed-up-your-wordpress-site-by-optimizing-autoloaded-data/)
### **Step 3: Profile Plugin and Query Load**
**Install [Query Monitor](https://wordpress.org/plugins/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](https://pressable.com/knowledgebase/using-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](https://pressable.com/knowledgebase/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](https://pressable.com/knowledgebase/caching-types-available-pressable/). Remove W3 Total Cache, WP Super Cache, etc. Our caching guide:[ Caching types available at Pressable](https://pressable.com/knowledgebase/caching-types-available-pressable/)
- **Backup plugins:** Consider whether you need real-time backups when [Pressable provides daily backups](https://pressable.com/knowledgebase/accessing-backups/) (with additional redundant backups via the [free Jetpack Security license](https://pressable.com/knowledgebase/what-is-jetpack-security-how-to-enable/) 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
Info:If you see `object-cache.php` in an error message, this does NOT indicate a caching or server problem. The issue is with the data being cached, not the caching system itself. Focus on identifying which plugin is storing excessive data in cache.
## **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/](https://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](https://pressable.com/)
- **Contact form:**[ pressable.com/contact/](https://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.