Out of memory on admin/build/modules

Hm. All I know is that this is a known issue with Drupal core. Admin menu does no special stuff on that page. But Drupal core is clearing out all caches on admin/build/modules, which (also) triggers admin menu to rebuild its menu. There are one or two issues in the issue queue for Drupal core.

What exactly do you mean with "mysql-related out of memory error" ? Can you provide concrete error messages?

I am getting the same issue - Out of memory - when accessing the Modules page with admin_menu enabled. If I go into the "system" table and change "status" to 0, then go back and refresh my drupal page (F5) it all works smoothly. I have become quite accustomed to the admin_menu, and would hate to have to work without it. I will continue to trouble-shoot, although I'm not much of a PHP programmer yet...

After reading this thread I thought this mod was the cause of the problem explained here http://drupal.org/node/356272#comment-1260310 However, we are still dealing with the same issue error at admin/build/modules even though the mod was uninstalled. Any ideas about the memory issue?

Admin menu is so good that should be part of core.

Sorry, this is a Drupal core issue and cannot be solved by admin_menu. There are several handbook pages about PHP's "memory_limit" setting.

I've been deep into this problem for a couple of days now, and I'm pretty well certain that it isn't an issue that the "memory_limit" setting will fix. I've upped the memory setting on my troubled Prod system to an insane level (1024M as confirmed by phpinfo) and still get the problem. Interestingly, my Dev system runs just fine at 64K.

The failure symptoms are remarkably reliable. If admin_menu is enabled, I get the following error (I've enabled memory reporting in the devel module for debugging):

Fatal error: Out of memory (allocated 37748736) (tried to allocate 590809 bytes) in /var/www/html/drupal/includes/database.mysql-common.inc on line 34
Page execution time was 10212.23 ms.
Memory usage:
Memory used at: devel_init()=1.08 MB, devel_shutdown()=35.68 MB.

(note the 35MB reported size is _way_ below the 1024M limit I set) (did I mention an insane amount of memory)

I've been able to trace the execution of the admin/build/modules code down to the point where admin_menu rebuilds itself.

I'll keep digging for answers and see where I end up, but something else is going on besides the memory_limit issue, and it's unfair to just point in another direction and then turn your back on the problem. (Point out a good direction in 'core', I don't want to live with this problem on my Prod site)

You are misinterpreting the numbers.

Your effective PHP memory_limit is 36 MB (= 37748736), which, depending on the amount of modules you have installed, is quite small. For an average Drupal site you need 64 MB at least, 96 or 128 MB recommended.

True is that the architecture of admin_menu 1.x resulted in a slightly higher total memory consumption. However, 1.x is a thing of the past. As 3.x becomes more and more stable, and the architecture was revamped in there, you can try 3.x-dev - if you cannot increase your memory_limit further.

I oopsed on the numbers... I meant 1024M (not K)...

But now I'm more confused on the memory allocation issue. I also turned on Devel memory reporting in my Dev system, and it reports values over 40MB when I go to the modules page. (I have my Dev system set to 64M)

As for versioning... I'm currently on "6.x-3.0-alpha1" not a 1.x (missed that select box). So, with that in mind, is it still worth moving to the 3.x-dev bundle or am I good enough sticking with the 3.0-alpha?

Also, since I have two systems with differing results, is there any debugging or tracing I can do to further track down the problem, even if it is in core? I don't want to have continued exposure to this problem in my Production environment.

I meant 1024M (not K)...

Anyway, your _effective_ memory limit is 36 MB, no more and no less. So whatever you did to alter the limit, it is not in effect.

Yes, 3.0-dev is completely different than the alpha1 release.

Well after much hair-tearing and frustration, I was finally able to resolve the memory problem (at least for my site).

What kept me at this problem was the different characteristics of two different systems that I had the exact same drupal install deployed on. On my Development system I am able to configure and use 128M of memory in PHP, but on my Production site I would consistently receive an error at roughly 35M even though it was also configured to use 35M. (both sites are kept in sync via mysqldump and rsync scripts)

In posting #4 above, sun is correct when he (paraphrase) says this is not an Admin_Menu problem, but the underlying issue is not even really with core. At it's basic level the Admin_Menu module relies on a call to the (core) menu module to accumulate it's information. If your implementation has a deep-and-wide menu structure (maybe from lots of modules), then the core menu module will return lots of data to Admin_Menu, and you end up with an "out of memory" error and Admin_Menu looks like the culprit.

I was able to track the problem down using the Devel module, and hacking my way deeply into the php code.

For my site I was able to:
Specify memory_limit to be 128M, and confirm that with Devel->phpinfo()
Trace the code down into a db_query in includes/menu.inc
Run the query by hand with phpmyadmin and see that it was indeed huge

Ultimately, after digging through the php.net site and looking for any kind of restriction that might exist, the only restriction indicated seems to be the limitations of your machine, so I made a call to my web provider. Seems that their management tool (Sphera) will impose process limits by default, unless overridden. What this means is that no matter what you do, or what the OS will report back to you, there is a point when your process runs that you will get smacked in the head, and even though you thought you had plenty of room, you don't. Fortunately, my provider was willing to remove the 'secret' limit, and now all is well.

The upshot...
Changing memory in php.ini works! You can even set the limit to -1 and have no limit.
There is no 'effective' limit to php process sizes unless your provider imposes one on you.
And finally, Admin_Menu is a great tool, and there is no reason why anyone should live without it!

Cheers,
Paul

I'm not sure if this is related, hence why I haven't changed this issue to reflect the newest version, but upon updating from alpha1 to alpha2, clearing the menu cache and some admin pages throw out a max_allowed_packet error (for cache_menu). It only happens with alpha2, alpha1 and 1.5 (which I've reverted to) both work fine.

I realise that this is related to the MySQL config, max_allowed_packet is currently set to 16M

Please let me know if this is should be posted as a new issue or is an extension of this one.

- Wayne

@watbe: With alpha2, it is impossible that admin_menu is the cause for this max_allowed_packet error, because it is entirely based on Drupal core's menu system.

Which query did you find to be the culprit Paul?

There is no 'specific query' to pin the blame on... Depending on the memory available to php, your processing will wind it's way into various nooks and crannies of the Drupal code, and eventually run into the memory constraint. That's what makes this issue so difficult to track down. All I can offer is that if Drupal (really php) says that you are out of memory, you are. Even if through your best efforts you think you have all the memory parameters set correctly (double checking phpinfo of course) your best bet is to double/triple check with the admin for your server (may be your ISP).

Good hunting...

Paul

I'm not too experienced with MySQL and PHP so excuse me my ignorance :-)
I came across the same problem - I tried to install ne module and admin pages crashed wit hthe 'out of memry' message. Then I tried to refresh the page and there were messages about failed UPDATE queries for table cache_update. I checked the table in phpMyAdmin and I've noticed that the table have large 'overhead'.
I'm not sure how would it relate to php running out of memory during UPDATE/INSERT but I thought I'll add my comment so that maybe some more experienced LAMP guy will find it useful :-)

Regards
Rafal

...I forgot to add that after running OPTIMIZE on the table cache_update everything works like a dream ;-)

UPDATE: Well... I have to remember not to post any silly things before I check it thoroughly. Overhead on the table I mentioned in comment#14 is a RESULT not a CAUSE of the problem, it's a result of interrupted insert/update. Real cause is very simple - various settings in drupal are stored as serialized arrays in BLOB fields in DB. Before you can run query which updates or inserts data you have to make sure that the data doesn't contain any characters which will break the query, like for example mysql_real_escape_string() (this one was causing memory problems in my case).

Bottom line is - with this kind of approach for saving the application seettings it will fall over now and again if your memory settings are 'tight' on your server :-)

Rafal