Fatal Error: Allowed Memory Size Exhausted — Find What’s Eating It

“Fatal error: Allowed memory size of 134217728 bytes exhausted” means PHP hit 128 MB while generating the page. The instinct — raise the limit — is sometimes right, and often wrong: if something consumes 300 MB on a page load, raising the ceiling just moves the crash. Here is how to do both correctly.

Raising the limit, the right way

1. wp-config.php: define( 'WP_MEMORY_LIMIT', '256M' ); (front end) and define( 'WP_MAX_MEMORY_LIMIT', '512M' ); (admin).
2. Know the override chain: the server’s memory_limit in php.ini beats wp-config if lower — on managed hosts you may need the hosting panel’s PHP settings page.
3. Sensible values: 256M front / 512M admin covers nearly every real site. 1G+ limits mask leaks rather than fix them.

Finding what eats the memory

• The log line names the file where exhaustion happened — usually the victim, not the eater. A media library page dying there suggests the culprit runs on every request.
• Test with plugins halved: memory leaks from plugins (import jobs, backup routines, image optimizers mid-batch) respond to the halving method like any other symptom.
• Check autoloaded options: a multi-megabyte autoloaded option loads into memory on every request — we found a 2.4 MB one costing measurable RAM sitewide, described in the cleanup test. Measure with wp db query "SELECT option_name, LENGTH(option_value) sz FROM wp_options WHERE autoload='yes' ORDER BY sz DESC LIMIT 10" --allow-root.
• Time-correlate: does it die during backups (backup plugin mid-transfer), imports, or bulk image optimization? Then it is a batch job, not a page — schedule batches smaller.

The honest numbers

A well-built WordPress page request runs 40–80 MB. 128 MB default fails only on bloated stacks or legitimate heavy jobs (image processing, importers). If a normal page needs 200 MB+, something is wrong and the limit is a band-aid — the asset audit and free audit identify the usual hogs.