1

I'm aware that this is a known problem but I was unable to address it using information found in WPAnswers and Wordpress support forums.

In my Worpdress single site installation the media uploader is always throwing an error at me

    out of memory (allocated 99614720) (tried to allocate 3760 bytes) 

the amount of allocated memory is more or less always the same - that should be about 96M... but in my server the php memory limit was set to 512M, post size is 12M, max upload size 8M

it's a VPN server and there's 1.5GB memory on it!

Wordpress throws the error also on images as small as 300-400K and under.

I tried using

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

or

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

but neither of these (alone or together) worked, in fact the error thrown was always the same and I had the impression Wordpress was disregarding both - I tried other settings too, the error was always the same and the amount of memory allocated more or less the same

I tried to change the php settings, like lowering the memory limit to 128M or bringing back again to 256M, restarting http service (apache) and restarting the whole server, but nothing changes

I proceeded to disable plugins, but the only way they don't seem ultimately responsible for the problem.

I decided to edit line 257 of media.php inside wp-includes folder, since the errors were always coming from line 258 which was executed thereafter

   @ini_set( 'memory_limit', apply_filters( 'image_memory_limit', WP_MAX_MEMORY_LIMIT ) );

I've replaced WP_MAX_MEMORY_LIMIT with values above 96MB for instance 128M or 256M

but no matter what, the allocated memory never exceeded 96MB. I tried lowering the WP_MAX_MEMORY_LIMIT to values such as 16M, 32M... anything below 96. Well! In that case the allocated memory resulted lower as in fact I was setting a lower limit - but how come it can't be more than 96? Still, I don't understand why wordpress takes so much, but nevertheless, why I'm not able to set to 128 and see if the problems are finally fixed? I'm only experiencing issues with the image uploader.

I've even tried to use

    @ini_set( 'memory_limit', '128M' );

in my wp-config but again it doesn't change the 96M limit... however it's able to lower it if I set to anything below 96 (resulting memory errors will state corresponding values)

I've run phpinfo from where my Wordpress installation is and the available memory is indeed that which is set on the server... 512M! so I don't understand why Wordpress seem to use less than that no matter what

any clues?

thank you

1 Answer 1

4

You're looking at the problem the wrong way. The error you're seeing isn't an error coming from WordPress, it's a PHP error.

Somehow, somewhere, something is limiting the memory limit to 96M, and it ain't WordPress that's doing it.

Here's the thing: WordPress can't actually limit the memory on most servers. I know that it attempts to increase the limit using ini_set and such, but that's more of a just-in-case sort of thing. Sometimes it can set the limit higher. Most of the time, PHP simply ignores that line.

You're also misunderstanding how memory works. This is made clear by the line "Wordpress throws the error also on images as small as 300-400K and under". The size of the compressed image has little or nothing to do with the size the uncompressed image takes in memory. That is all about the resolution. Megapixels matter. One pixel takes 4 bytes. 8 million pixels (8 megapixels) takes 32 megabytes of memory to represent, and the size of the resulting compressed JPG is irrelevant. WordPress needs to hold a couple copies of the image in memory too, the original one that it's working from, and another that it is creating the modified versions of. So yeah, lots and lots of memory is needed.

But again, WordPress can't set the memory limit in most cases. So something is limiting it to 96M. Which will severely limit the maximum size of the images WP can work with. Until you find where that 96M limitation is coming from, looking at the WordPress core code and such is kinda a waste of your time here.

5
  • Undestood Otto, thank you - this was driving me crazy (you're right about the uncompressed part, actually I did know that the image is passed as a string didn't have the patience to think anymore after wasting hours on that) - just on a hunch, where would you suggest to look at in the server configuration? from Cpanel and phpinfo looks normal... or perhaps do you know any reliable sysadmin for hire that would be able to look for me? thank you!
    – unfulvio
    Aug 14, 2012 at 14:27
  • also it is kinda of strange that it happens only on one website on the same server... if I disable all plugins I can upload images slightly bigger than usual (ok in term of pixels), but I guess that's because there might be more memory freed - I was mislead when I noticed that plugins like Woocommerce or Gravity form extensions seemed to ease the issue
    – unfulvio
    Aug 14, 2012 at 15:11
  • Try making a phpinfo.php file (containing just a <?php phpinfo(); ?> line in it), and putting that in various places on your installation. In the root directory, in the wp-admin, etc. Then pull up that file in a web browser. That might show you different results than what CPanel shows you, help you narrow it down.
    – Otto
    Aug 14, 2012 at 20:36
  • I raised a paid managed assistance ticket with my host and see if they can fix the issue - I ran phpinfo on various locations (account root, several wp folders, my theme forlder...) and checked the results side by side but I couldn't find anything unusual - I've found this serverfault.com/questions/329422/… looks similar to my problem
    – unfulvio
    Aug 15, 2012 at 3:32
  • RlimitMEM did it! the customer service from my host found it in the Apache config file. I have no idea how that happened - actually it might have been there for long time and I only realized when working with a more memory consuming setup. Do you know if there's a way to access the apache config file via ftp or WHM without using the terminal? thanks
    – unfulvio
    Aug 15, 2012 at 14:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.