Mysteries about the WordPress Memory Limit

Note: The information in this report applies to WordPress 3.0 specifically. Starting with WordPress 3.2, the memory limit will be configurable again.

 

Being on track to write a really simple plugin that should take care of the memory related crashes problem I began to wonder a bit about how Memory Limit is dealt with in WordPress 3.0 core code.

It looks like that in case there is a need of memory, the PHP function ini_set() is called to set the memory_limit php.ini configuration directive. The magic value it is set to is 256MB.

First of all, the reason for having a memory limit is to [help] prevent poorly written scripts for eating up all available memory on a server (from the PHP Manual). So the original idea of this setting is to set the memory limit in the servers configuration. That’s normally the job of the administrator and an application should not deal with it on it’s own. Otherwise there would be no need to have such a limit.

On the other hand, a server should be properly configured for an applications needs that is calling it it’s home. For example running WordPress with a 4 megabyte limit is not suitable and instead a very bad idea. This leads to check WordPress system requirements, but they do not name a minimum amount of memory at all. So a wordpress user is left alone to figure this out, as well as for WordPress developers because they have no mark for orientation. So far so bad but nothing surprisingly at all. Documentation is for those of who are damn stupid.

Okay, let me help you with this one: It is said, that a standard (default) blog needs 32 MB and the new multisite variant 64 MB. Those are the standard WordPress memory limits. They are defined within core code (albeit the implementation is buggy and renders those default constants useless but it’s enough for the moment to read the code as documentation replacement and just go on). Let’s say, these memory limits of 32 or 64 MB are intended. Blogs with more content, especially long posts, need more memory than that, but to gather the proper amount for a concrete install is not within the scope of this post, so I won’t go into detail here. Let’s take these values in absence of anything else.

As already written, the wordpress application is then designed to set the memory_limit directive everywhere when it seems to fit to make more memory than that/configured available. It’s used in the following places:

  1. Unzipping files – unzip_file()
  2. Previewing, Saving and Loading Images – stream_preview_image(); wp_save_image(); wp_load_image()
  3. The Admin – No single function, all admin

 
When it comes to these places, it looks like the magic value of 256MB has been elected to provide enough memory. I know images that are of larger size than that. And I know that standard servers do not provide that much memory for PHP. So why 256MB? Probably because Matt Mullenweg needed it for his photoblog. And since then no complaints must have been heard so to use that value in other places as well. But who knows, the original intentions nor for what this fix was for in concrete might never be revealed precisely because mostly the changes are done w/o any accompanied ticket-info ([6786], [14491]).

To summarize: WordPress needs 32/64 MB of memory, and next to that it needs 256 MB. That’s for Photos (and the Admin).

Server! Give Me The Memory! Or I Will Kill You!

The originating problem which did make me think about writing the Memory Limit Plugin was that many users reported that setting to limit to 256MB kills the request because the server prevents wordpress doing so. As written, 256MB is a very high value.

Because next to a PHP memory limit, there are other things that control and limit the amount of memory that can be consumed by PHP and processes in general. Often this is referred as soft- and hard-limits. In short: soft can be gone over but warns, hard is a show-stopper.

The popular PHP extension Suhosin for example can prevent script from doing such a thing. If that’s the case on your blog you’ll find something like this in your error log:

… ALERT – script tried to increase memory_limit to 268435456 bytes which is above the allowed value …

This is the poster scenario, because suhosin is very popular (and well, yeah, useful). If you run into this problem, please tell your system administrator that you need 256MB of memory for wordpress and both, the php and the suhosin memory_limit directive should reflect that accordingly. But be warned, you just might get a harsh answer, because 256MB for webhosting is often considered as a misconception. Maybe it helps if you say, “well, it’s WordPress” and that you have large images to process.

Next to that, a properly configured server has hard limits as well. That means, for whatever has been configured in PHP or suhosin, the system takes care of any process anyway and if the PHP process in a CGI/FCGI configuration is consuming more memory than allowed, it well get killed. Period. Normally this will return a 500 Internal Server Error then.

If you’re running PHP as an apache module, this might just bring the whole server down, at least one of it’s childs. Connection terminated. As written on top, it’s wise to have a memory limit and it’s wise that this is properly configured by the servers administrator. Otherwise you can run into problems you do not want to run into.

And even if you feel like so: Fighting against your Admin will always make you lose, it’s not a fight you can win. Okay maybe with your wallet. But then it’s your money anyway.

To configure or not to configure

So buying hardware and properly configuring a server can cure the problems to run wordpress. If this is not an option, the problem remains. On the one hand, WordPress wants more memory, but how to deal with that? How to prevent wordpress from triggering other limits on your server? That’s what my plugin should do, prevent the blog from crashing.

First of all, let’s take a look how much memory should be allowed. The best hint by your sys-admins would be the bespoken memory_limit directive. It was configured by the server’s administrator. In case that is not enough, a good software should report this to it’s user so that he can discuss with system support how much memory is possible and to configure it accordingly.

WordPress does not warn because it know that their users feel what the application wants. And anyway, the truth is, who wants warnings? Who needs them? Warnings are completely useless, they only come when you don’t need them. So it’s a wise-programming style to block all warnings as wordpress does.

Since WordPress is changing the memory limit, this prevents the usage of the setting as it was designed for. But that’s for the moment only, because ini_restore() restores a given configuration option to its original value.

So it’s as easy as restoring the default value by calling ini_restore('memory_limit'); for the admin, for example within the admin_init hook. But for the admin, there is as well another filter that can return the maximum allowed memory: admin_memory_limit. So that filter can return the original value as well to override the 256MB magic number and set it to the server-configuration.

So now everything is in order to create a plugin, right? It’s possible to gather the original memory limit value and it’s possible to filter the setting done by wordpress. Using that filter was suggested by Andrew Nacin in the related trac ticket. Thanks to Nacin, I know knew how I could implement such a great plugin. You know it’s a joke, don’t you? That filter is only in there for one of the many places where the memory limit is set. All the other places lack of such a filter – well I think because nobody was caring for years anyway.

So to make the long story come to an end: This can not be fully fixed with a plugin and WordPress 3.0 is broken. Tja, Pech gehabt Jungs. So to say, you need to get your server properly configured, to be worry free, extend the PHP Memory Limit to 256MB.

So instead of writing a plugin in the first place, I‘ll suggest a patch instead. Should be easy to solve with a single wordpress configuration constant.

Related Stuff

This entry was posted in Hacking The Core, Pressed and tagged , , , , , , , , , , . Bookmark the permalink.

15 Responses to Mysteries about the WordPress Memory Limit

  1. mtekk says:

    Fighting against your Admin will always make you loose, it’s not a fight you can win

    Do you mean “lose” (as in the opposite of winning), or “loose” (as in not tight)? 🙂

  2. Pingback: Wordpress Snippets » Increase memory limit

  3. Pingback: links for 2010-10-19 | Ronaldo Richieri

  4. Pingback: Project 2061 Techlog » suhosin gives wordpress the smackdown

  5. Pingback: Sécuriser PHP avec Suhosin sur Gentoo | Le carnet technique de Poirsouille

  6. duyhen says:

    i don’t think so
    my blog put at byethost and memory size 24M
    i need more memory, how ?

  7. Pingback: Menangani Memory Limit Dashboard WordPress di Server MWN « Outstando

  8. Paul says:

    So, after reading this and putting a load of my clients sites with fasthosts.co.uk, find that admin screens are ‘white’ing’ out when we try to add new plugins?

    Reason? Perhaps the limit they set on shared server hosting of JUST 20MB PHP MEMORY may have something to do with it!!!!

    Interesting read, but now on the lookout for more accomodating UK hosting for WordPress clients…

    Cheers for the heads up!

  9. Pingback: WordPress Memory Limit fixed in 3.2 | hakre on wordpress

  10. Pingback: jgiam.com: Tweaking Apache + Wordpress

  11. In the file wp-config, which is located in the root of your wordpress installation, you can edit the file and edit or add this line of code:
    set_time_limit(160);
    If you change 160 to 0, it would be unlimited (not recommended) Usually 60 secs will fix most plugin issues.
    You can also set your memory in the same wp-config file by using this line:
    define(‘WP_MEMORY_LIMIT’, ‘256M’);
    Where 256 can be changed to what you need to run your plugin.
    I hope this helps.

  12. Pingback: suhosin to WordPress: go on a diet | Project 2061 Techlog

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.