By krsna-1 on

When the number of modules that I install is exceed about 56, then, I can't access administration->modules,
it says:
Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 11520 bytes) in /www/users/back.kosmos.cn/modules/upload.module on line 43
Allowed memory size of 8388608 bytes exhausted (tried to allocate 137 bytes)

HELP ME, PLEASE!

Comments

robertdouglass’s picture

robertdouglass commented

The admin/modules page loads all the modules (even the ones that aren't activated), so that page is the upper limit of your Drupal's memory usage (or a good indication of it). There is a limitation in the PHP configuration as to how much memory one request can be allocated and if Drupal needs more than that amount of memory, you get the error above. If you're on shared hosting you're basically out of luck (unless you can talk them into changing the limit for you).

There is no limit to the number of modules that Drupal can have installed, only a limit on how much memory your server will let Drupal use.

- Robert Douglass

-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net

sangamreddi’s picture

sangamreddi commented

Hi Robert,

Thank you, but how to change the memory? In php.ini file?
Could you Plz expalin.

Thanks in advance.

Sunny
www.gleez.com

robertdouglass’s picture

robertdouglass commented

http://drupal.org/search/node/out+of+memory

- Robert Douglass

-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net

Stephen Winters’s picture

Stephen Winters commented

In an attempt to head off memory limit problems (with TikiWiki, another CMS), when I contacted my shared host provider with a request to raise my php memory limit from 8M to 32M, this was their reply:

"You need to create a php.ini file in your public_html directory of www.yoursite.com with, the following statement

memory_limit = 32M;

This will take care of it."

I followed their instruction and created a php.ini file with only that line in the file, " memory_limit = 32M; " (without the quotes).

I couldn't tell if it did anything or not. I couldn't find any way to measure the php memory limit.

I hope this helps.
Stephen

sangamreddi’s picture

sangamreddi commented

Thank You Stephen. I tried it's working like charm

Sunny
www.gleez.com

Alaska’s picture

Alaska commented

Add this as the second line in index.php located in your Drupal root directory and it solved the module loading issues when in the Drupal admin mode.

ini_set("memory_limit","20M");

Here is that code placed in that PHP index file.

<?php
// $Id: index.php,v 1.82 2004/08/21 06:42:34 dries Exp $

/**
 * @file
 * The PHP page that serves all page requests on a Drupal installation.
 *
 * The routines here dispatch control to the appropriate handler, which then
 * prints the appropriate page.
 */

include_once 'includes/bootstrap.inc';
ini_set("memory_limit","20M");
drupal_page_header();
include_once 'includes/common.inc';

etc.....

This came from mdowsett....

Jim

robertdouglass’s picture

robertdouglass commented

That's where all the other ini_set's take place.

Unfortunately, on some shared hosting platforms, they disable both this method and the php.ini method of changing things. This is one of the questions you should ask before signing up for a hosting contract:

"Can I override the php memory limit with ini_set?"

- Robert Douglass

-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net

Stephen Winters’s picture

Stephen Winters commented

Hi Alaska,
Thank you so much for your excellent instructions and description. From your very clear instructions I can easily (and have) change these settings. Also, thank you for giving that very helpful example of what if is supposed to look like. That helped a bunch. This was so much better than just saying something like "change the memory settings" (which I've had people do) and then I have no idea of what to do or how to do it.

Thanks again,
Stephen

Alaska’s picture

Alaska commented

Stephen:

Glad that the example worked for you. As stated, some hosts disable the ini function so that this can not be utilized. In my case it did work and solved that memory issue.

I too, like good examples of how the code is placed, etc. Too many times others assume that you are good at PHP. Sometimes yes, but other times no. A little extra does go a long way in helping others.

Jim

celticess’s picture

celticess commented

I was considering switching off Drupal because it was so slow to load. With that little tweak and having friends visit my page to test it I can say it moves a heck of alot faster. It would literally take 6sec+ to load(for me and I'm on broadband).

krsna-1’s picture

krsna-1 commented

Sadly, I'm on a shared host...

A suggestion: Why not separate the admin/modules page into multi-pages? Does it work?

sepeck’s picture

sepeck commented

Drupal loads only the modules it needs... except on the modules page. On the modules page, it loads them all. If you can;t get to your site, you can remove unused modules.

There are memory tricks that you can add to the htaccess file, depending on your host, that have been posted in the forum.

-sp
---------
Drupal Best Practices Guide - My stuff Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide

maserole’s picture

maserole commented

My tests indicate that since drupal doesn't know before hand which module to load for a particular functionality, it has to check in all modules???? All that IO surely has a serious cost. I suspect drupal would be even faster if it knew before hand which module has what functionality.... Thinking of a module+function map like solution which is registered at initial module registration.

Here is how: (put the following small ?harmless? code at the begining of a few modules and .... replace X with the name of your module

-----cut here: start---
drupal_set_message("Loading module X ") ;
-----cut here: end---

and?

robertdouglass’s picture

robertdouglass commented

You would show that every activated module gets loaded for every page view. That's well known, and there are reasons why:

  • Every module can add or manipulate any node being loaded; it is impossible to know in advance whether a module will do this or not since the decision is often dynamic.
  • Every module can implement permissions. This makes all of the various node access modules possible.
  • Any time an action is executed on a node, every module gets the chance to say "no", or to modify the workflow in some way. Any module can add to a node, filter a node, decorate a node, etc.
  • Any module can create blocks.
  • Any module has the chance to do things before or after a page loads. This is how poormanscron does the cron tasks when nobody is looking. All modules have to be loaded to do this.
  • Any module can interact with the user objects when loaded. This is how the profile module lets user objects have custom fields.
  • The list goes on....

The problem of splitting modules into bits of functionality that are related is not easy; one of our more brilliant developers is talking with mathematicians to see if there is a mathematical way to graph dependencies, which would enable him to write a custom parser which would then split the code into a bazillion code snippets, paste them together in related files and use a dependency graph to include and execute them. Don't wait for this to hit core... it probably never will. In the meantime, Drupal will do just fine for a blog or a normal site. If you're going to run a site like Ourmedia.org, NowPublic.com or SpreadFirefox.com, you'll need more iron; more memory, more servers, PHP cache that reads the compiled PHP files into memory, and maybe squid proxies as well.

Or you could use fewer modules.

cheers,

- Robert Douglass

-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net

eldarin’s picture

eldarin commented

I remember one issue where a guy was working on improving module-loading, which I found interesting.

Another thing is to remember the Event-Listener pattern; nothing brilliant in that, but it would sure cut down on all the blind hook_nodeapi() and other hookable calls around. Of course it would change how hooks are implemented now, but the current method is a bit naïve (when it comes to performance) anyways. ;-)

Now, the main rant about this is that there are not that many (memory) persistent variables that can be used with PHP, mostly limited to db-connection etc., if I remember correctly.

Still, it would no doubt be an improvement with some module-/site-config in db for Listeners and events - which would be bootstrapped like the variables get/set.

robertdouglass’s picture

robertdouglass commented

In other words, you'd have each module register its hook dependencies and store them in the database?

- Robert Douglass

-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net

eldarin’s picture

eldarin commented

... something like that.
Of course Event-Listener is a well-known technique to get better performance from "events" - and is a pretty robust and widely used too.

There are other routes to even better performance along the same direction, like pre-selecting some possible variables and using them as even more detailed "events".

One could even cut down heftily on module-loading with a scheme like this.

peterx’s picture

peterx commented

The regular page processing load could be reduced by moving administration code out of the .module file. The memory used by the module list page could be limited by loading the modules through an exec script.

I load some of my extensions through my pet module. The code required for processing every page goes in one file and the code for the administer pages goes in another. When you write a node process for extension pet_xyz, you put it in pet_xyz.class and it is loaded for every page. When you write administration code for extension pet_xyz, you put it in pet_xyz.inc and it is loaded only when in the administer area.

For compatibility with existing modules, you could introduce xyz.admin along side xyz.module. The current code would always load xyz.module. When Drupal in in the administer area, Drupal could load xyz.module, then look for and load an optional xyz.admin. People could gradually split modules into .module and .admin. .module would always be loaded before .admin so that .admin could use any common definitions or functions from .module.

If the module list page blows up too often then you could load the modules one at a time as an external exec file. The exec file would load one module, get the help output and return just the help text. When the exec finishes, the memory should be recycled. You could have hundreds of modules without using more memory than is required for just the largest module. The external exec could be based on the exec script I suggested for massmailer.

http://petermoulding.com/technology/content_management_systems/drupal/

petermoulding.com/web_architect

Alexandre Gomes@poderdapalavra.com.br’s picture

Alexandre Gomes@poderdapalavra.com.br commented

I also think modules in admin/modules must be separate.
For sample, a page with all "filters" modules, other for "taxonomy modules", other to "auth" modules, etc

satovey’s picture

satovey commented

A better way would be to divide the modules in
subcatagories. Using the same methode that
is used within the blocks page.

The first two head catagories are those that are enabled
and those that are disabled. The subcatagories
under these to catagories for simplicities sake would
be alphabets a - z.

The list of enabled and disabled modules would be stored
in seperate tables as opposed to the single table currently
being used. A new table, disabled modules would be added
and it would be ignored unless the modules page subcatagory
of disabled modules was clicked.

The page would show tabs with alphabets in them and
each module would be listed under it's letter enabling
drupal to ignore all other modules that are not under
that particular letter tab.

The enabled modules page would be similarly
organized.

Alternatively, the subcatagories could devide the
modules under those which would be specifically
for administration, commerce, user activities,
content publishing ect. There would be a field
within the table that would enable the modules
to be catagorized upon the initial registration of
the module in drupal. This would allow for a
speedier modules page.

An module update button could replace the automatic
module registration which would eliminate the repetition
of module registrations that occur when the modules
link is clicked under administration. When a module
is removed or installed the module update button would
then be pressed to update the modules list.

The blocks page could be similarly subcatagorized
so that one can determine which blocks one may
wish to enable based on their catagory.

Also, the basic _hooks necessary to activate a module
should be tranfered to a table. This would be the _menu,
_settings, _perm and _help could all be transfered to the
database. This would allow for a button that will create a
bare bones module.

Error handling would need to be better under this change.
instead of the errors posting to the top of the page before
the drupal site loads, the errors would be posted to the
top of the modules page. The error handling must also
eliminate the crash of drupal when a module is installed
that does not work properly or has errors in it.

Scott

chrisbuck’s picture

chrisbuck commented

Increasing the memory limit to 100MB in Settings.php (within the 'sites > default' directory), worked well.

http://drupal.org/node/36628