Out of Memory when Uploading an Image

2 Views

Sometimes when I upload a picture (either with flash or browser uploader), I get a message like (this was with a 1.46MB jpg): 

Fatal error: Out of memory (allocated 69206016) (tried to allocate 4000 bytes) in /home/ab64489/public_html/wp-includes/media.php on line 254

I am on a shared host, but the max upload size is 64MB. I’ve tried uploading other files (I made a zip of some random files, with the archive totaling ~58.1MB, and it uploads and crunches with no problem, so it’s not the file size). It also seems that the upload works fine, but when it tries to crunch, then it encounters the error.

Read More

I’ve seen similar problems here and on other sites with no real solutions.

What could be the cause of this issue?

Post Views: 2

Related posts

Leave a Reply

3 comments

  1. This isn’t a WordPress problem. There’s no telling on a shared environment what the culprit might be. You probably don’t have access to your php.ini config, nor do we know how many websites your hosting company has jammed on your server.

    The very nature of a shared server is that each client shares the resources of that one server. If one website is using massive amounts of resources while you’re trying to upload your image, that would certainly affect it.

    The only real fix to this is getting onto a more controllable environment. I gave up on shared hosting a long time ago and went with a cloud server from Rackspace. I am in complete control and I don’t have to worry about other memory hogs on the same box.

    You can also look at your code and identify blocks that use significant memory by printing out memory_get_usage() before and after. You might need to debug in WordPress core, or in plugins. I typically start pretty wide and start zooming into problematic areas of code. You’ll find the memory leak this way if it’s in your code.

  2. My solution (in wordpress 3.3.1) was to do the image compression myself, then add a single entry to the metadata table in the DB.

    For the image compression, I noted the other correctly compressed files were all compressed to three consistent sizes: 150×150, Mx300, and Nx1024, where M and N would maintain the ratio of the original image.

    In the metadata table, there was already an entry for my newly created post. Sort by post_id and then look for the entry with your post_id and meta_key = _wp_attached_file to make sure yours is there.

    My corresponding row has meta_value = 2012/04/get_in_shape.png.

    Now the fun part! Find a row (from a post which had its image correctly compressed) with meta_key = _wp_attachment_metadata and use its value of meta_value as a template for your new row.

    In your new row, the values should be

    `meta_id`  (null)  as it's an AUTOINCREMENT field
`post_id`  (your post id)
`meta_key` _wp_attachment_metadata
`meta_value`  (as below)

    The following is a serialize()ed string with the data that worked for me for meta_value. It will not work for you without tweaks. If you can do all the above, you can certainly do the tweaks as well.

    a:6:{s:5:"width";s:4:"3321";s:6:"height";s:4:"4153";s:14:"hwstring_small";s:22:"height='96' width='67'";s:4:"file";s:24:"2012/03/get_in_shape.png";s:5:"sizes";a:3:{s:9:"thumbnail";a:3:{s:4:"file";s:24:"get_in_shape-150x150.png";s:5:"width";s:3:"150";s:6:"height";s:3:"150";}s:6:"medium";a:3:{s:4:"file";s:24:"get_in_shape-240x300.png";s:5:"width";s:3:"212";s:6:"height";s:3:"300";}s:5:"large";a:3:{s:4:"file";s:25:"get_in_shape-819x1024.png";s:5:"width";s:3:"724";s:6:"height";s:4:"1024";}}s:10:"image_meta";a:10:{s:8:"aperture";s:1:"0";s:6:"credit";s:0:"";s:6:"camera";s:0:"";s:7:"caption";s:0:"";s:17:"created_timestamp";s:1:"0";s:9:"copyright";s:0:"";s:12:"focal_length";s:1:"0";s:3:"iso";s:1:"0";s:13:"shutter_speed";s:1:"0";s:5:"title";s:0:"";}}

    See the path looking thing 2012/04/get_in_shape.png? That’s the path to your file (with wp-content as its understood prefix). Note it’s preceded by s:24 which is the string length of the value. Change the path to match your file, then change the 24 to match the length of the path you used.

    Do that for each of the file sizes, save the new record, and you’re golden.

    DO NOT TRY THIS if you have little/no idea how to do it. Just sayin’ there is a cheaper(*) method than moving to a new host.

    (*) if learning all this in uni is considered cheap.

  3. For me it was really a memory issue (in the code), I was using a plugin called blurhash that did some stuff on the images, so make sure to disable all your plugins and you might find the problem, and then push a fix or something or fork it.

    For instance in my case the blurhash was running multiple times on the image so I added a simple cache mechanism and my problem was gone.