Hello. I work for the Department of Correction and our website is using Drupal 6. We have the Boost module installed to deal with the issues we had with queries taking too long and site slow-downs due to traffic. For the past few months we have been running out of disk space on the server and it turns out the cache_menu table is HUGE! (I can truncate the table in the database, but obviously that's not a permanent solution and doesn't answer the question as to why it is out of control.)
I have found very little information on the web. One solution I found was to disable the cache_menu table altogether but when I tried that, it brought the site down to its knees. Note: I have this solution set up in our test environment and there are no problems with it; as soon as I implement it in our production environment, it hoses everything.
My question is this... Has anyone else run into this issue and what did you do to solve it? We also have our intranet site on Drupal 6 and we don't have the same problem but it is not using Boost. Could Boost be the culprit? What are some ways I can find out what's really going on? Any information/suggestions, etc. is most appreciated!
Thanks,
Rhonda
Comments
Boost will most likely not be
Boost will most likely not be causing the issue.
Each user has their own menu cache. when a user logs in the menu cache is built for them. On your test environment there are probably only one or two developers logging in. How many active authenticated users does the site have.
How many rows are ending up in the cache_menu table?
How much data is in the table?
We have approximately 60
We have approximately 60 active users. We also have a special "anonymous" user (based on IP address), which has rights to view certain content. (They have no editing rights.) The cache_menu table right now is 1 GB and returned 20719 rows. This will continue to grow until the server runs out of space or I truncate the table manually, whichever comes first.
Possibly Pertinent Issue Thread
I haven't worked with Drupal 6 in awhile but I do remember noticing how big the cache_menu got. Here is a place they talk about some possible solutions.
https://www.drupal.org/node/1234830
From skimming the thread it looks like the problem they had here was that the cache_menu items had their expiry set to 0 so they never expire, towards the end they do have a patch that was added 5 months ago. I haven't read through it much but it might help you with your problem.
Thanks, Jed - that was one of
Thanks, Jed - that was one of the few articles I have found regarding this issue and I confirmed that the patch is, in fact, in place in our system.
Update to this issue
I have been monitoring this table and taking a closer look at the contents. I believe the issue has to do with the following:
We have a custom module that appears to write 6 rows to the table each time the "details" page of the search results (of this module) are displayed. The module creates a special search form and that form gets about 35,000 hits per week.
The generic authenticated internal user, which is basically every single employee. So whenever any employee loads the site, there is a menu getting built for them, if I am understanding this correctly. I'm guessing 500+ employees or so, have computers at this agency. Each time this generic user selects a menu item, anywhere from 6-20 rows gets written to the cache_menu table.
I have some "band-aids" in place to clear the cache_menu table a few times throughout the day but I'd really like to find out how to turn off cache_menu caching for our generic user - is this possible? In addition, I would like to disable cache_menu caching in our custom module. I would also like to gain a better understanding of cache_menu's purpose and why it's even being used if the only solution when it gets too large is just to keep truncating the table. That doesn't seem like a good long-term fix.
Thoughts?
Thanks!