WordPress: Fatal Error Memory Exhausted

At some point, anyone building a theme, plugin, or even just working with WordPress has seen the Fatal Error: Memory Exhausted message. It typically reads something like this:

Fatal error: Allowed memory size is 268435456 bytes exhausted (tried to allocated 29596635 bytes) in …/wp-includes/wp-db.php on line 885.

Yes, your message may be a little different, but the point is the same: You see a fatal error, it has something to do with the amount of memory allowed, how much was attempted to be allocated, and what file threw the error.

In my opinion, one of the big problems with errors like this is that it’s far too easy to Google for a quick solution to fix the problem rather than truly understand the problem.

Sure, I understand we’ve got stuff to do and work to get done, but understanding what the problem may be is important to helping us become better developers, and, who knows, we may uncover a bug in a piece of open source software.

In this case, it’s not the latter, but here’s a good way to go about understanding the above error.

WordPress Fatal Error Memory Exhausted

Using the above message as an example, we’re told what the allowed memory size is: 268435456 bytes. But no one deals in bytes anymore, right?

We’re much more comfortable with megabytes, gigabytes, and even terabytes (though if you have that kind of memory and are seeing this error, that’s a whole other situation :)).

Bytes To Megabytes

So the first thing to do is to convert bytes to megabytes. Google makes this really easy: In the search field simply enter:

268435456 bytes to megabytes

And it’ll return a result for you:

This equates to 256MB

This equates to 256MB

Kind of neat, right? But what do we do with this information?

First, we need to understand that we have a limit of 256MB of memory that’s available to be used by PHP and WordPress and that it was insufficient for the operation.

Honestly, this tends to be more of a limitation of PHP, but I bring up WordPress because part of the solution may involve defining a new constant if you’re using WordPress. But more on that in a moment.

Adjusting PHP

Knowing that PHP has a memory limit and knowing that you have some control over this using WordPress, there are normally two things that I recommend others do in order to make sure that they solve the problem in all the right places.

But first, you need to know what version of PHP you’re using. If you’re running this on a local machine, then you’re likely able to find this within your web server’s control panel:

I'm running PHP 5.3.14

I’m running PHP 5.3.14

Otherwise, your web host should have this prominently displayed somewhere in the dashboard of your hosting account.

This lets us know which PHP configuration file to edit. Specifically, you need to locate the php.ini file that’s relevant to your version of PHP.

If you only have one version installed, easy; otherwise, you’ll need to locate the php.ini file for the specific version of PHP that you’re running.

Increase The Memory Limit

Once you’ve located the php.ini file, look for the memory_limit directive:

The PHP memory_limit Directive

The PHP memory_limit Directive

In the shot above, you can see that the memory limit is set at 25 megabytes which is clearly less than what we need. To that end, you should be able to increase it to, say, 128M, restart the server and be good to go.

What If WordPress Still Complains?

In that case, then you may need to make one additional change to your wp-config.php file. There are two constants that we can define:

  1. WP_MEMORY_LIMIT
  2. WP_MAX_MEMORY_LIMIT

You can read more about both of these values in details in the Codex, but the gist of it is that I’ve had more success defining both values that simply editing WP_MEMORY_LIMIT.

I mention this because there is a lot of advice that advises others to define the WP_MEMORY_LIMIT. I’m certainly not saying that’s wrong – I’m just saying that I’ve had better results when both have been defined.

So, just as with the php.ini file, add the following values to wp-config.php:

define('WP_MEMORY_LIMIT', '128M');
define('WP_MAX_MEMORY_LIMIT', '128M');

And that should resolve the issue.

A Word About Memory Allocation

One thing I do want to mention is that although a simple solution may be to simply vastly increase the available memory, this isn’t necessarily the first thing that you should do.

In fact, this is normally the last thing I do.

Often times, this particular issue is a result of a block of code, a procedure, or some algorithm that may be better optimized than how it currently stands when the error is thrown.

So to that end, double-check your code first – use some profiling tools or debugging tools to make sure you aren’t doing anything that’s inefficient. If not, then adjust your memory.

16 Comments

Sometimes .htaccess rule works too:

php_value memory_limit 256M

Trading the introduction test, I was hoping you would talk about common causes for this problem in WordPress, such as calling WordPress native functions for retrieving information and forgetting what happens under the good, especially for database-related calls.

However, the article focuses on solving the error, but not the problem lying beneath. It’s good that you talk about handling memory limits in WordPress, though :-).

    +1, I was hoping you’d go into memory optimization for plugin developers.

    128MB is a lot of memory for a script to consume. Just as a reference, a clean WordPress installation will use ~20MB in the admin area.

    Like assets, plugin developers should load and run their code conditionally. Split-up your code in multiple files, check if the current request is a frontend / backend / ajax request and act accordingly. Now this might be obvious but you’d be surprised on how many plugins out there are loading or running all of their code for every request. Especially for users on shared hosting this can be crucial.

      +1, I was hoping you’d go into memory optimization for plugin developers.

      Perhaps in another post :)

      128MB is a lot of memory for a script to consume. Just as a reference, a clean WordPress installation will use ~20MB in the admin area.

      This is true (which is why I added the disclaimer at the end of the post), and I agree. I wouldn’t necessarily leave the total amount of memory that high mainly because, like you said, scripts should not execute in such a way that that’s how much they require; however, there are exceptions where sometimes this may be needed temporarily (such as in the case of a one time task).

      I’ve noticed different hosts can use memory differently. I’ve had users tell me their memory usage and, even with my plugin only active, it’s using a lot more memory than I see on my development site (localhost MAMP), and my client sites (some shared, some WPEngine).

      I’ve got some installs using as little as 9MB and others 20 or 30MB – with same plugins. Then I get someone saying on their server, 64MB isn’t enough.

      This is something that puzzles me greatly. It’s tough when someone says “Hey, your crap plugin is suckin’ memory!” when it’s not anywhere I’m running it.

        I’ve noticed different hosts can use memory differently. I’ve had users tell me their memory usage and, even with my plugin only active, it’s using a lot more memory than I see on my development site (localhost MAMP), and my client sites (some shared, some WPEngine).

        This is nothing but pure speculation, but my guess is that hosts set limits based on worst-case/best-case scenarios and it varies from shared-to-managed for those reasons alone.

        But trying to nail it down so it works in all scenarios is one of those challenges of working with WordPress, associated plugins, themes, and so on across environments with which we’ve no control =T.

Wow, I should check what autocorrect does to my carefully crafted comment before posting it… I wasn’t trading tests, I wad reading an introduction text!

Thanks for all of the tips. I’ve been banging my head against a wall trying to resolve this exact issue. We’ve migrated to a different server with more RAM, and I’m trying to adjust settings to tap into the available RAM. Building a video library site that allows the end user to select files and then click download, php then zips and downloads them. It’s a memory beast given that video files by nature are large. Totally open to other suggestions or tips on how to cut down on memory usage if you have any to give!

    Working with videos and large files like that can be tough.

    Dynamically building up a zip file for users to live can be tough depending on the amount of resources that you have available (obviously). If you were able to host the videos on a CDN or on a place like Amazon S3, and then write a script to bundle up the videos that way, then you may have some success, but I’ve not had to do something like that before under constrained resources so it’s tough for me to suggest anything more :/.

Anyone processing images probably has a bloodied forehead with the telltale indentations of a qwerty keyboard because of this issue.

Users like to load WP up with big images straight off their smartphones and cameras. The GD Library handles them as uncompressed (as you’d expect). So, an 8MP picture could suck 24MB just to load. Then whatever the processing is doing, will create a second image (hopefully smaller if you’re doing things right!). So memory can disappear in a blink.

I’ve had this issue for a couple of years with my gallery plugin and resolved it by *temporarily* overriding the PHP memory limit with ini_set 128M (then resetting it).

But recently, that wasn’t even enough for some users’ sites.

So I decided to have dig around to see how WP resolved it. Was pleased to see they are doing exactly the same thing; however, they bump the limit up to twice that.

Here’s their code (from wp-includes/class-wp-image-editor-gd.php):

// Set artificially high because GD uses uncompressed images in memory
@ini_set( ‘memory_limit’, apply_filters( ‘image_memory_limit’, WP_MAX_MEMORY_LIMIT ) );

And later

If you look in wp-includes/default-constants.php you’ll find they’ve set WP_MAX_MEMORY_LIMIT to 256M

So, now my plugin does the same and so far users haven’t encountered that error anymore.

    Then whatever the processing is doing, will create a second image (hopefully smaller if you’re doing things right!). So memory can disappear in a blink.

    If I recall correctly, it’ll create even more than a second image (depending on the installation’s configuration), so that’d consume even more :).

    So I decided to have dig around to see how WP resolved it. Was pleased to see they are doing exactly the same thing; however, they bump the limit up to twice that.

    That’s really interesting to know. And not a bad strategy – bump it up temporarily, then bump it back down – thanks for sharing this, Chris.

    Good stuff.

Trackbacks and Pingbacks

[…] WordPress: Fatal Error Memory Exhausted […]

[…] WordPress: Fatal Error Memory Exhausted […]

[…] WordPress: Fatal Error Memory Exhausted […]

[…] WordPress: Fatal Error Memory Exhausted […]

Leave a Reply

Name and email address are required. Your email address will not be published.

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>