11

I've switched from Drupal 7.14 to 7.15 three weeks ago and therefore, I'm encountering a series of very sophisticated (for me) memory limit errors. Those errors occur any time I'm trying to clear cache in performance or to run update scripts.

My hosting company has increased my memory limit in php.ini up to 126 M, 256 M, 512 M, and even 1024 M. But the errors still occur. I've migrated my site from shared to VPS, But the error incredibly still occurs. I have no way and no idea how to move forward.

Here are the errors:

  • Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 30 bytes) in /home/example/public_html/sites/all/modules/views/views.module on line 416

  • Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 108 bytes) in /home/example/public_html/includes/menu.inc on line 2736

  • Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 71 bytes) in /home/example/public_html/sites/all/modules/chain_menu_access/chain_menu_access.module on line 59

  • allocate 64 bytes) in /home/example/public_html/sites/all/modules/views/includes/base.inc on line 93

Improve this question
8
  • What is your peak traffic (pages/second). Also how much data (nodes?) does the view trying to fetch back?
    – cherouvim
    Oct 11, 2012 at 4:52
  • similar discussion on drupal.org drupal.org/node/76156
    – Anoop Joseph
    Oct 11, 2012 at 6:26
  • 2
    Do you by chance have a view that returns a large number of results and for format it loads content instead of fields? I have seen this hamper performance many times before.
    – Jepedo
    Oct 11, 2012 at 12:30
  • Hi guys! Thanks much for your answers. I want to say that th website is under maintenance mode and contains only a few amount of content (nodes) for test purpose. The site is visited only by crawlers As I mentioned in my post, the increase memory limit in php.ini solution suggested in node drupal.org/node/76156 didn't help in my case. For views loading content instead of field. I want to figure it out how
    – salift
    Oct 11, 2012 at 15:45
  • 1
    Have you tried switching back to Drupal 7.14? If upgrading to Drupal 7.15 caused that problem, then why not try switching back? My hunch is that there is infinite recursion in one of your modules. What are your Views related modules?
    – Johnathan Elmore
    Nov 15, 2012 at 19:40

4 Answers 4

Reset to default
13
+100

I've also been beating my head against a wall the last while with Drupal memory issues. Here's my collected knowledge on the topic:

1. Views (can) use a lot of memory

I love me some Views (and Panels and CTools and everything merlinofchaos touches with his mighty, mighty fingers), but it's possible to create configurations with multiple relationships that use a lot of memory. If you disable your Views and the memory issue goes away, it's likely a badly-constructed View causing the issue.

What to do if it is a View, and you really need that View to work? Try putting it into code (Via Bulk Exporter or Features; see below. I've hand-coded Views-like functionality in order to improve performance with very little success) for a start. Another thought is to redo the View a different way -- if ultimately what you're getting at is taxonomy terms, make sure the type of View is a Taxonomy View when creating it; don't create a Content View that uses relationships to get at taxonomy terms.

Could also be worth mentioning here that Panels also supposedly uses a lot of memory -- I haven't really benchmarked it so can't confirm this.

2. Moving stuff from database into code is a very good practice

It took me several Drupal sites to realize this, but keeping everything that's created via a UI in the database (Views and Panels configurations especially) is a Drupal worst practice. Why? It increases load on the database and cannot be version controlled. The first point is particularly problematic in terms of memory usage -- instead of just loading the content from the View from database, the site must also load the view components itself. This is exacerbated by how Drupal uses tables: by abstracting everything to the nth degree, each bit of Drupal's functionality uses a new table, resulting in some requests joining a bajillion tables together. This gives Computer Science people hernias (caveat: link is silly), but can't really be avoided with a piece of software as modular and user-friendly as Drupal is.

The solution? Use Bulk Exporter (Included with CTools) or Features to package up bits of code currently residing in the database as module code.

3. Themes can also eat memory

Does your theme have a lot of template files (I.e., files in themename/templates/)? If so, memory is consumed each time one of those files is loaded. If you're creating templates specifically to suppress bits of Drupal from being displayed, try either:

  1. Changing permissions so that bit doesn't show up for specific non-admin user roles.
  2. Using CSS to hide elements.

The first choice is obviously what you want to do for stuff affecting security -- you don't want to use CSS to hide an "edit" button for certain users, only to have them then unhide it via Firebug or whatever.

4. Don't go overboard on contrib modules

While sometimes a site needs a lot of contrib modules, don't go overboard. Each enabled (note: enabled. Disabled modules don't use any memory) module uses memory. This is a bit obvious, but worth noting regardless.

5. The VPS is (sometimes) a lie

In my experience, some unscrupulous hosting companies love trying to push Drupal sites to VPS servers -- they're more expensive and it frees up shared hosting space for ever-more WordPress websites. The situation is worsened by the fact that webhosts often don't advertise (Or even willingly tell you if asked) what the upper memory limit is for shared hosting.

Alas, often if a site isn't under heavy traffic and is still crashing, the issue likely has something more to do with Drupal's configuration than anything else. Pushing a user to VPS just muddies the waters and adds more variables to deal with (Is it the webserver config? PHP config? VPS guest config? VPS host config, even?).

6. When all else fails, clone to localhost and beat it with a stick

This is a big reason why people use the dev-staging-production methodology with version control -- when all else fails, you can do a DB dump, git clone the site to a local testing server and then royally mess up the site on the testing server without worrying about actually breaking anything on the production server.

For memory issues, this generally means disabling modules one by one until the one causing the issue is exposed. It can also point to webhost-related issues -- if the site runs perfectly fine on a local install with memory set to something reasonable like 128MB, then you know your webhost is on crack.

tl;dr

My gut is that it's chain_menu_access that's causing the issue. Try disabling that and clearing the cache, see if it works.

I'll also add to this answer as I think of other things to try...

Improve this answer
4
  • ...and that's exactly the kind of thing I hoped for when I put a bounty on this question! Especially 2. 110 rep to you good sir :) Hopefully this'll attract some useful comments from others with slightly different experiences too
    – user56reinstatemonica8
    Nov 20, 2012 at 13:34
  • p.s. I've heard in various places that even disabled modules use a certain amount of memory in parsing the files. I've seen people say that all php/inc files get parsed in some way, although that doesn't seem right (more likely just the info files). Any idea if there's any truth in this?
    – user56reinstatemonica8
    Nov 20, 2012 at 13:36
  • Cool, thanks! I'm pretty sure Drupal's fairly memory conscientious when loading files -- if you run XHProf, the number of calls to file_scan_directory use up enough memory as it is. I'll test out some stuff with devel this after to confirm that, though.
    – aendra
    Nov 20, 2012 at 13:49
  • If disabled modules use any memory, it's fairly insubstantial. I looked at how much memory was reported by Devel before and after deleting a module -- while the page refresh after removing the files showed a small (< 1MB) spike, it then returned to exactly the pre-deletion values on the next refresh. This leads me to believe that Drupal a. Scans the modules directory on boot to see if there are any new .info files b. Adds the module's details to its system table c. Loads any modules with system.status field entries set to 1. If anyone can confirm or disprove this, I'd appreciate it.
    – aendra
    Nov 20, 2012 at 14:09
2

You can try putting PHP profiler like XHProf or Xdebug's built in profiler to inspect what is happening in the request.

Improve this answer
1
  • Once you figured out which parts especially needs what amount of memory you have done step 1. Step2 is about actually trying to understand why it is using that much memory and how to reduce it. Above people talk about to much items in the result etc. In general that's a process which can't be simple described.
    – Daniel Wehner
    Nov 15, 2012 at 22:43
1

Views is a memory hog. Drupal's caching can help. Drupal only loads modules active however if they create tables or have other objects those can hang around. Only uninstalling will remove most of the artifacts. We use drupal's authorization/permissions and write our own modules within. Not the best but the performance is much better and easier to tune. We do the same for WP too.

Improve this answer
0

I my case the memory limit problem was generate by cache system (Boost and Boost Expire modules). This give me issue to update module or views. Once disabled Boost modules all work fine.

Improve this answer

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.