75 guides published Start a blog Fix my site How we test
FIX IT

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:

CauseSymptom
A query returning everythingThousands of rows loaded to display ten
Image processingOnly on upload or regeneration
An import or exportOnly on that operation
Too many plugins loading everywhereHigh baseline on every page
An infinite or deep recursionMemory climbs until it fails
A huge autoloaded options tableHigh 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.

S

Sumit

Writes everything on TechMozz.

More in Fix It