Warning: Parameter 1 to wp_default_scripts() expected to be a reference, value given in /home/webgalli/public_html/blog/wp-includes/plugin.php on line 571

Warning: Parameter 1 to wp_default_scripts() expected to be a reference, value given in /home/webgalli/public_html/blog/wp-includes/plugin.php on line 571
Allowed memory size exhausted in elgg - Team Webgalli Blog - Team Webgalli Blog
Request quote

Allowed memory size exhausted in elgg

Posted on: August 18th, 2011 by Mohammed Aqeel 1 Comment

Perhaps you’ve been happily administering an Elgg install and come across a mysterious error like this:
Allowed memory size of 67108864 bytes exhausted
(tried to allocate 64 bytes in engine/lib/database.php on line 271)
Try as you may, you can’t find the offending plugin. Increasing the memory limit doesn’t work, or your hosting provider refuses to increase the limit in the first place. You’re frustrated, your users hate you, and you’re thinking about extremes: like dropping your database and starting from scratch or switching hosting providers.

I have good news for you: you’re about to fix this problem!* It seems that many people in the Elgg community have had this problem, but I’ve never seen a definitive or satisfactory solution or explanation for it.** This is that definitive solution and explanation.

I ran into this issue today and was pulling my hair out for 14 hours before I figured it out. Hopefully you will be able to take care of it in 14 minutes, 10 of which are spent just reading fluff sentences like this one in this blog. After an upgrade of our codebase, we were getting the standard “Allowed memory exhausted” error mentioned above. I spent a lot of time examining examining error logs, debugging, pulling my hair out, and thinking about where I was going to find my next job if I didn’t fix this problem soon. Finally, a glimmer of hope emerged. Elgg was dying right after this query:

SELECT * FROM elgg_metadata WHERE entity_guid=1 AND name_id=3

So I ran this query against my database to see what it was getting. It was spitting out a lot more results than I anticipated, and many of them were duplicates! So how many duplicates did I have, I wondered? Well, let’s find out:

SELECT COUNT(*) FROM elgg_metadata WHERE entity_guid=1 AND name_id=3

This gives a count of the enabled plugins. If you’re experiencing this problem, you should do it too and see what you get. Go ahead, I’ll wait.

Ready? Let’s share numbers: the count I got was over 64k!!! Now, fancy Elgg installs like ours have plenty of plugins, but I can assure you it’s not 64 thousand of them. It seems that it’s possible for Elgg’s database to get corrupted such that it starts inserting duplicate entries for the enabled_plugins field. As page loads continue, these duplications multiply and eventually you have pages that are trying to load thousands of rows into memory and Elgg just falls over. I figured all I needed to do was remove all these bad rows. So I followed up with:

DELETE FROM elgg_metadata WHERE entity_guid=1 AND name_id=3

That disables all plugins on your site. Then, you can just go back to the admin panel and enable all your plugins like normal. You should be good to go at this point! No bugging your hosting provider for more memory, no dropping your database, no using up 128M of memory per page load, no losing your job. It’s a good day!

I have submitted a ticket that I hope will prevent this problem from ever happening again. I will also be examining Elgg’s plugin code to see if there’s anything on the application side that can prevent this from happening. If you can identify the code path that causes this before I do, please share!

*OK, I can’t actually promise this article will solve the problem, but I really hope it helps and I’m pretty confident that, if you’re getting the error above (line 271 of database.php), this is the solution.

**Some have suggested that the solution is to just increase the allowed memory limit. We tried that: we had to up the memory limit to 256M before it would start serving pages, and they were very slow. Then a little while later everything died again. I hope it’s obvious that Elgg should never require 256 Megabytes per page load! In fact, most pages on our site require less than 16M per page load normally, far lower than the default 64M. We have a rather ambitious site, so I can almost guarantee you that allocating more memory will not solve the actual problem, even if it seems to relieve the symptoms for a while.

CREDIT FOR THE ORIGINAL POST: EVAN WINSLOW. This is a cached copy of the original post as its not available now. Hope this will be helpful to someone.

Tags: , , , , , , , , ,

One Response

  1. James says:

    Thanks for this great info. It saved my job. ;)