Allowed Memory Size Exhausted: Raise It, Then Find the Cause
This error means a PHP process asked for more memory than it was allowed. Raising the limit makes the symptom go away, which is useful when the site is down and misleading if you stop there.
The short version
- Raise the limit to get the site back, then investigate.
- A normal WordPress page should use well under 100MB.
- Query Monitor shows you what is actually consuming it.
- If the admin fails but the front end works, it is usually a plugin’s admin code.
The quick fix
// wp-config.php, above the “stop editing” line
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );
WP_MEMORY_LIMIT covers the front end; WP_MAX_MEMORY_LIMIT applies in the admin, where imports and media processing need more.
If that has no effect, PHP itself is capping you below the value you set. Raise it at the PHP level:
# php.ini or .user.ini
memory_limit = 256M
Watch out
Some shared hosts ignore .user.ini or cap the value regardless. If the error persists at the same number no matter what you set, the limit is being enforced above you and you need your host.
Read the error properly
The message names the file and line where the allocation failed:
Fatal error: Allowed memory size of 268435456 bytes exhausted
(tried to allocate 20480 bytes) in
/wp-content/plugins/some-plugin/includes/class-importer.php on line 312
That file is usually not the cause — it is simply where memory ran out. But a plugin path is a strong hint about which plugin to suspect, and if the number is small (20KB, as above) it means memory was already almost gone before this allocation.
Find what is using it
Install Query Monitor and look at two things: peak memory on the affected page, and the query count. The common causes:
| Cause | Symptom |
|---|---|
| A query returning everything | Thousands of rows loaded to display ten |
| Image processing | Only on upload or regeneration |
| An import or export | Only on that operation |
| Too many plugins loading everywhere | High baseline on every page |
| An infinite or deep recursion | Memory climbs until it fails |
| A huge autoloaded options table | High baseline, slow everywhere |
Check the autoloaded options
Every page load reads every autoloaded row in wp_options. Plugins that store large data there without disabling autoload are a frequent and invisible cause:
wp db query "SELECT option_name, LENGTH(option_value) AS size
FROM wp_options WHERE autoload='yes'
ORDER BY size DESC LIMIT 20;"
Anything above a few hundred kilobytes is worth investigating. Transients left behind by removed plugins are common offenders.
If only the admin fails
Front end fine, admin failing, means plugin code that only loads in the admin. Disable plugins from the filesystem and reintroduce them:
mv wp-content/plugins wp-content/plugins-off
When raising the limit is the right answer
Sometimes it genuinely is. Large imports, bulk image regeneration and some page builders legitimately need more than the default. If the high usage is confined to one deliberate operation, raise the limit for that operation and move on.
What is not normal is a front-end post page needing 256MB. That is a problem to find, not a limit to raise.
Common questions
What should a normal page use?
Typically 30–80MB including plugins. Above 128MB on an ordinary page is worth investigating.
Is more memory bad?
It reduces how many PHP processes the server can run at once, so under traffic you hit a different limit instead.
Why only on one page?
Something on that page — a specific query, a gallery, a large table — is doing the work. Query Monitor on that page will show it.
Sumit
Writes everything on TechMozz.