Hi all.

I have a very strange problem: I get a WSOD or a PHP error (Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 32006063 bytes) regardless of the memory_limit set in php.ini (on both the server and my local machine) when attempting to access the modules admin page.

After I deleted a few of the nodes, such as Devel and the Drupal Firebug helper module, the page loads no problem.

I know someone will ask, so yes, I confirmed with a call to phpinfo() that the memory_limit increase (up to 4 GB) was in fact taking. I set it back to 128M and deleted the modules and poof, the modules page loaded again.

I almost feel as if this should be reported as a Drupal bug because there MUST be a better way to load that page.

Any ideas on how to resolve this issue? I would clearly like to be able to access/use all modules and continue adding more. I have a site with many more modules than this, but it is still on Drupal 5.x, whereas this site is using the very latest (6.12).

I can post my php.ini file if it would help.

Are there any other php.ini settings I can tweak to try and get that page loading w/o deleting modules?

Thanks in advanced,



danharper’s picture

I also have this problem

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 929050 bytes)

and if I delete a few modules it seems to work again

CinderA’s picture

I have the same issue, with a little twist. It's giving me a specific location. The error is in the DATE Module. But i've been using the module just fine.

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 7680 bytes) in /home/tran9775/public_html/sites/all/modules/date/includes/date_api_filter_handler.inc on line 397

Here is the code from line 396 (Included the comments)
* Custom implementation of query() so we can get the
* AND and OR methods in the right places.
function query() {
if (!empty($this->query_fields)) {
foreach ((array) $this->query_fields as $query_field) {
$field = $query_field['field'];
$sql = '';
$sql_parts = array();
switch ($this->operator) {
case 'between':
$sql_parts[] = $this->date_filter('min', $query_field, '>=');
$sql_parts[] = $this->date_filter('max', $query_field, '<=');
$sql = implode(' AND ', array_filter($sql_parts));
case 'not between':
$sql_parts[] = $this->date_filter('min', $query_field, '<');
$sql_parts[] = $this->date_filter('max', $query_field, '>');
$sql = implode(' OR ', array_filter($sql_parts));
$sql = $this->date_filter('value', $query_field, $this->operator);
if (!empty($sql)) {
// Use set_where_group() with the selected date_method
// of 'AND' or 'OR' to combine the field WHERE clauses.
$this->query->set_where_group($this->options['date_method'], 'date');
$this->query->add_where('date', $sql);

I tried removing that section of code. I just started using Drupal a week ago, so I'm not so familiar with the code.


Chairman13’s picture

I'm also having this problem, thankfully it's on the test server...but I can't even access the module page to disable anything.

When you delete...do you just delete the folders from the backend on your server files?

profjk’s picture

If you just delete the folder, without disabling the module first, your drupal site itself might go down, spitting plenty of error messages.

You need to first increase your memory limit higher in php.ini file in the root folder (public_html) so that you are able to access your modules page.

Even for a production site with plenty of module including Views module (which is the known memory hog) 128M php memory should be good enough.

Chairman13’s picture

Thank you very much. ...unfortunately, we max out at 32M with our hosting company. Not in the budget to go to a VP or dedicated server solution. ...so I guess I need to economize.

profjk’s picture

Some shared hosting providers allow 128M php memory. You please find out from your service providers.
One of my sites runs on Bluehost. They said that I can go upto 128M php memory limit. But cureently I have set it to 64M (I did not want to hog the memory unless it was required!). The site is working without any issues.

Good luck.

audaciousweb’s picture

I use mosso and they give you a virtual linux box for $20 a month, slicehost has a similar plan.. its not that much to switch to a cloud host and its very well worth it, I have over 1000 MB of memory at my disposal I definitely recommend checking this option out.

Fabien Crépin’s picture

Well, I experience the same problem. And whatever the memory I allow, the error still comes.

Now, I've a 128M memory set, and i'm facing the "Fatal error: Out of memory (allocated 48758784) (tried to allocate 736146 bytes) in XXX/includes/database.mysql.inc on line 301"

That's really confusing, and I've tried php.ini, .htaccess and settings.php way to set the memory, it is on 128M (a php_info does confirm).

Is there a limitation in Drupal on number of modules???

Drupal rocks!

Anonymous’s picture

Same for me. It happens when I try to upload the Advanced User module. When I delete the advanced user module, I can refresh the page (sometimes I have to refresh a couple times), then the module page comes back. But I can't do anything with the advanced user module uploaded.

Fabien Crépin’s picture

If I deactivate manually the Devel module, it works again. This doesn't seem normal to me, since the error doesn't reflect the actual use of the memory.

Doing this, I've seen that there was a "bootstrap" field in the system database table, with value equal to "1" for a few modules, including Devel and Statistics. Wha's the purpose of this field?

Drupal rocks!

Anonymous’s picture

I've gone and deactivated and deleted several modules and now I'm not getting the error anymore. Very weird problem.

ckreutz’s picture


Same problem for me with a localhost and server side installation. Set both on 128 MB and get same white pages memory size problems with different modules. Completely arbitrary some modules work such as views and other not.

Fabien Crépin’s picture

Do you have Devel module enabled?

Drupal rocks!

ckreutz’s picture

No in my case I do not have the devel module installed. I cannot import terms from taxonomy and had a similar overload problem with different mapping modules.

misterlawrence’s picture

I have the same problem, which just occurred after updating to the latest DEV versions of CCK and Views. I ran the update.php, and it executed with error.

When I went back to admin > modules, I got the following error:

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 214574 bytes) in /home/teameigw/public_html/2009/includes/database.mysql-common.inc on line 41

Haven't been able to get back to the modules admin page to disable any modules. I have very few modules installed.

My php.ini says currently has the following settings (I use Bluehost.com for my hosting):

; Resource Limits ;

max_execution_time = 30 ; Maximum execution time of each script, in seconds
memory_limit = 50M ; Maximum amount of memory a script may consume (32MB)

misterlawrence’s picture

For what it's worth, here's how I solved my problem. Again, I use Bluehost.com for my host, so your mileage may vary...

First I changed my memory_limit to 128M in the php.ini file in my root directory.

That didn't solve the problem so I called Bluehost.

They had me go into the Control Panel (at Bluehost.com) and select PHP Config. Then, I selected the option:

PHP5 (Single php.ini)
Same as PHP5, but all subdirectories will use ~/public_html/php.ini

That did the trick! I don't know if the tech from Bluehost made any changes on his end behind the scenes; I don't think he did though.

Hope that helps somebody!

Fabien Crépin’s picture

I think bluehost is a reseller of HostGator, and since my provider is HostGator, I guess I'll try this method (if I can figure out where this option is).
Thanks! I'll let you know if it does correct it.

Drupal rocks!

matteoraggi’s picture

yes, with bluehost you ahve to put php.ini in any folder that is needing it or your solution, here are other solutions: http://drupal.org/node/76156

bmango’s picture

Hi there,

I was having a similar problem, I had just copied a live site to a test server and I was getting a fatal error message about memory allocated. I solved the problem by going to my hosts (heart internet, www.heartinternet.co.uk) control panel and switching from, PHP 4 to PHP 5.

I hope this helps?


Fabien Crépin’s picture


in my case that was Hostgator which was setting a limit to 40M, even if the phpinfo let you beleive it's higher...
They upgrade my memory limit to 100M, no problem anymore.

So if you're at HG hoster, just call the support and ask them to give you more memory.


Drupal rocks!

bobburns’s picture

What cfab says is correct: I spent an hour in chat trying to tell the tier one guy at hostgator that this was hard limit issue on the server. Finally he escalated it to tier two support and within fifteen minutes I got the following email:


"Due to the fact that you are on a shared server, your server does have certain limits set. These limits provide a productive and workable web server for all customers on the server. We can raise certain parameters to allowed maximum levels, as needed, and we have done so in your case. Some customers do find that these limits are insufficient for their needs, and for those customers we suggest that they use our dedicated servers. Since dedicated servers are not shared with other customers, we do not place these limits on them.

Specifically, we have raised the following:
memory_limit = 64M
max_execution_time = 30
post_max_size = 64M
upload_max_filesize = 64M""


SO YES - Hostgator (and probably most other hosting companies) do limit the memory to 40M in the php.ini no matter what you select it to be, and only a tier two admin can bump it up. You will get the same message referring to the same issue "Fatal error: Out of memory (allocated 4xxxxxxx) (tried to allocate xxxxxx bytes) in /some/path/somewhere/somefile.xxx on line xxx" The key is "Out of memory" - and it could point to any file anywhere - but usually it only occurs when trying to enter "modules" - a.k.a. http:// . . . /admin/build/modules

The key is the first number - always around 40M - in bytes 4xxxxxxx

Here they only gave me 24 meg more - but so far it is working. If I have more trouble I'll ask for 100

So there is nothing strange or weird about this error - it is a man made and induced error.

Bob Burns
Certified UNIX engineer

twasserman’s picture

Using Drupal 6.13 for a test site on my own dedicated server running Ubuntu with the 2.6.28 kernel, I had the same fatal error message as reported by others:

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 171576 bytes) in /var/www/drupal-6.13/includes/database.mysql-common.inc on line 41

I tried all of the suggestions proposed by others on

I increased the memory_limit to 128M in both the php.ini file and the settings.php file, but always
received this error when I went to /administer/build/modules. I restarted my Apache web server
after each change to the configuration.

If I went to create content, things were OK. The system only died on the page displaying the modules, presumably because drupal tried to load all of the modules (enabled and disabled) at that point.

I then removed the views directory from the sites/default/modules directory and then I was able
to access the /administer/build/modules page where I removed a couple of modules and enabled one.
Everything now seems to work OK.

At some point, though, I will want to reinstall the Views modules and perhaps others, but it appears that
I will be back in Fatal Error City unless the PHP memory allocation issue is somehow resolved.

I'm not sure that this problem qualifies as a bug, but I would certainly like to hear any suggestions for
working around this issue.

bobburns’s picture

This is likely an induced hard error - in your case likely you server is set to 35 meg - no matter what you select in the PHP.INI See reply above to the user "cfab"

Bob Burns
Certified UNIX Engineer

twasserman’s picture

I don't think that this is a hard error in the sense that you describe. This Drupal 6.13 instance is running on my own dedicated Ubuntu machine. I used Webmin and looked in the apache.conf file, the httpd.conf file, the phpadmin/apache.conf file, and a couple of other places, but didn't see anything that would place any limits on memory allocation at the size we are discussing here. phpinfo returns memory_limit of 128M. Perhaps there's a limit set in some other, more obscure place, but I didn't see anything in the obvious locations. Any ideas on other specific places to check? Thanks.

WorldFallz’s picture

If the error message still says the same amount of allowed memory size, then you have not actually raised it. Double check via the drupal status report page or use phpinfo to confirm you've actually made the adjustment.

Fabien Crépin’s picture

That's the tricky point :

at HG, both phpinfo or drupal status report page report the high memory limit you have set...
I don't know why (I would have thought that the shown limit would be the actual limit), but if you set 128M, you will see 128M even if HG limits you to 40M.

So looking at those pages won't help you a lot here. I've explained here this point : http://forums.hostgator.com/php-ini-128m-memory-limit-but-t54477.html
I don't know if you'll have access to the page, in case not, here's a small test you can launch to show your actual memory limit :

for ($i=0;$i<=$limit;$i++){

Try it on distant server, you'll see the hard limit that your provider has set.

Drupal rocks!

blackmarketeer’s picture

Hi all,
Also having a huge problem with this issue.

My host terminated my hosting account due to the fact my site continually took up too much memory - and it a very small site! (I have about 30 pages of content).

I increased php.ini from the default 32m, first to 128, then to 256, and no matter HOW much memory I allocated, Drupal would suck it all up. Host was using PHP 5.2.6

I loaded my site in xampp on localhost with Xampp 1.6.8, also using php5.2.6, and made sure to increase php.ini to 128M but always same problem:

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 402868 bytes) in C:\xampp\htdocs\drupal\includes\database.mysql.inc on line 301.

In my case this error occures when I installed CTOOLS and activated plugins from the modules page.

Any help?

WorldFallz’s picture

The number of 'pages' in a drupal site has very little, if anything, to do with the amount of resources it consumes. I could have a one page site-- depending on the number and type of modules I'm using and the amount of concurrent user traffic it could still overwhelm the usually minuscule restrictions of a shared hosting environment.

And what I said above applies in your case as well, if the error message consistently comes back with the same initial allowed size, you may not have actually made the change. I can't speak to hostgator or what cfab said above (http://drupal.org/node/466254#comment-2037880), but every time I've verified that memory outside of drupal with phpinfo, it's been correct.

And also, keep in mind, no matter what you set the memory to in software, you'll always be constrained by the physical memory of the box or vm.

blackmarketeer’s picture

Is there a solution to this nagging problem? I can prevent it by limiting the number of modules i install, but I have barely the ones needed now to be able to use panels or views. These are the modules I have loaded:


My host is the one that increased the php.ini file for me so I assume it would work, I can try them again but we pretty well parted ways. On their message forums I'm getting suggestions to switch over to Joomla as a CMS, but isn't Joomla the one that is supposed to be a tax on server memory and processes?

Fabien Crépin’s picture

Try the script I gave earlier, you'll see what's the limit that your provider set or your own localhost limit (here it seems to be 32 or 33M).

You haven't got a lot of modules activated here... When do you experience limit problems?

Drupal rocks!

blackmarketeer’s picture

As of this moment I have 128M set in php.ini on my localhost. I can't see tweaking it any higher since I know I won't be able to find a webhost that would allow me that much memory for a standard shared account (I don't want to pay for anything more than that).

The last module I installed was CTools (ctools-6.x-1.0), I activated each component individually, ran update, to check all was working. First "chaos tools" first, all was fine, then activated Page Manager, then View Content Panes, still all fine, then lastly CTools plugins, which is when the memory issue came up. I currently have to leave plugins deactivated to keep the memory usage in check.

Even so, running Drupal under Xampp (v. 1.6.8, php v 5.2.6) )on my local machine, the site is INCREDIBLY SLOW.

The php file I changed is located at C:\xampp\apache\bin\php.ini (which I determined from the phpinfo() link under xampp.

The resources I have set in php.ini are:

; Resource Limits ;

max_execution_time = 60 ; Maximum execution time of each script, in seconds
max_input_time = 60 ; Maximum amount of time each script may spend parsing request data
memory_limit = 128M ; Maximum amount of memory a script may consume (128MB)

It takes any page on my test site under xampp at least a full minute to load.

I'm no php whiz, so my only thought had been to roll back to an older version of Drupal which seemed to work for me using those modules listed above.

Anonymous’s picture

My server completely shut down on me after having this problem for weeks. My website is on a managed dedicated server. The accesslog database table crashed and had to be repaired. So when the tech went in to repair the table, guess what he found? That table had over 17 MILLION rows. The load on my server was 110, as compared to a load of 1 for your typical website.
Try disabling the Statistics module, it's under "Core - Optional", and then uninstall it to get rid of the massive database table. If you want statistics, use Google Analytics instead!

davbre87’s picture

I also have this problem. Like other people here the error appeared first when I tried to enable Ctools. Once I disable the "Administation Menu" module the problem disappears....but I want the admin menu :)

jrockowitz’s picture

I switched to using simplemenu (http://drupal.org/project/simplemenu) which has a smaller memory footprint. The admin menu also executes an sql query on every page load to look up the number of logged in users, this is really not necessary.

BTW, the devel module has a setting to display each page's memory usage which can be really helpful figuring out which modules and pages are consuming a lot of memory.

davbre87’s picture

Thanks for the tip!

ButterFly’s picture

Thanks for your help. Subscribe

fairweam’s picture

I'm on a vps with Liquid Web and my test site was running fine.

Then I started getting the "PHP Fatal error: Out of memory " error all of a sudden. Wasn't after installing a module or anything.

I've upped the memory to 128 in the .htaccess file, but that hasn't solved the problem.

Just wondering if any progress has been made.

Fabien Crépin’s picture

What's the exact error message?

Drupal rocks!

dadderley’s picture

I have the memory set to 128 MB in the settings.php and the php.ini.
This problem started not long ago.
I turned off modules still have the problem.
Flushed caches, still the problem.
Switched theme to garland, still the problem.

I have had various error messages, all with the same result WSOD.

Navigation menu:
error message when trying the access navigation menu
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 3218 bytes) in /xxxx/xxxx/xxxxxx.net/includes/form.inc on line 2218

anther error message when trying the access navigation menu another time
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 71 bytes) in /xxxx/xxxx/xxxxxx.net/includes/form.inc on line 1429

error message when trying the access navigation Admin menu:
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 6111255 bytes) in /xxxx/xxxx/xxxx.net/includes/database.mysqli.inc on line 303

dadderley’s picture

Raised the php memory in the php.ini and settings to 150M.
Now it works.

Why do the darned navigation and admin menus suck up so much resources when trying to access them in edit mode.
This is nuts.

dadderley’s picture

Same problem here

jrockowitz’s picture

I am gradually figuring out what is consuming my memory using the Devel module's 'display memory usage' checkbox on the devel settings page.

The website I am building is very complex with a lot of content-types and menu items which are both consuming large chunks of memory mostly due to caching.

I had 40+ content types, each content-type was consuming 500K to 1M of memory during each page load. The _content_type_info() (http://api.lullabot.com/_content_type_info) called by the content_type() function caches all the info about sites 'cck' content types. The _content_type_info() was caching over 30M of data on my site. My solution was to rework and reduce the number of content-types and fields required for my website.

The node edit page's 'Add menu item' fieldset's select menu loads a list with every single menu item. On my website this was consuming a lot of memory because I had 1000+ menu items. My fix was to enable the book module and move some of my menu section/items to books.

In-conclusion the number of content-types, cck fields, and menu item will definitely impact the memory usage on a website. If possible try to simplify your content types and look into menu alternatives/sub modules.

Using 96M to 128M of memory for a complex site using views, panels, cck, etc seems pretty common.

LudachrisGSX’s picture

Wish I knew Drupal was such a resource hog. We have a relatively simple site and just signed up for LiquidWeb's Pro shared hosting... now it seems as if we'll need a VPS solution at minimum just because we're running Drupal - LW told me that they can't up the memory limit for a shared site. We don't get much traffic and our site is not very big. Seems ridiculous to pay for a VPS when we don't need it.

Looks like I'm going to have to inform my boss, who I had to sell on Drupal. Looks like my stock just dropped.

suffering drupal’s picture

Subcribing LudachrisGSX!!
We ran into the same problem just when our site started to take off, breaking the 500 vis/day frontier. About the same time we happened to do some major upgrade and updates (D6.17 and modules) with the idea it would be an improvement, but then spain.on-map.net continuously collapsed the server and they simply shut off our site until we moved VPS. There seemed to be a lot of inefficient memory use and giant temporary tables and stuff...

We DO use Multilanguage, Multidomain, Maps and Galleries, but hey I thought that's what Drupal was all about.... at least that's what I was told. Very multi-everything and very stable! We found it is essentially very much suffering!

The site is now kindof working again, unfortunately without images or galleries. Is not the same....
And it took us almost a month to get this far after our hosting company moved us from a shared to managed server because all the permissions seemed to have changed. This is also a major issue in Drupal and you can find dozen of messages from desperate people because the cache is not working or the /tmp directory is not found (or was it tmp without slash? nobody seems to know exactly...).

Anyway we are still trying to find out if Gmaps clashed with the gallery or whether some other dumb error messes it all up, which would be absolutely no exception with Drupal.

O and by the way we haven't even started user-input. That WILL be scary!

I started with Drupal in 2007 and then my life got stuck...

berenddeboer’s picture

I suppose you get what you pay for?

There are more Drupal hosting providers...

Berend de Boer
Xplain Hosting

arpieb’s picture

What you got was a basic hosting environment, not intended for heavy duty sites and active Drupal development. The $19.95/month hosting solutions out there were not intended for sites that have:

  1. High traffic
  2. High memory requirements (development work, image manipulation, interactive chat systems, etc)
  3. Large storage needs
  4. High bandwidth (in spite of the "unlimited bandwith" claims by many - unlimited at a throttled speed perhaps...)

If you're doing anything more than basic page hosting (as in any of the above), then you do need to step up to a VPS solution or dedicated box. Some of the newer cloud offerings are also offering cost-effective scalability on an as-needed basis.

All my development work is done on a dedicated server with configurable resources, and I never have a problem. When I migrate to a production server (lower horsepower, shared, etc) I shut down all non-production modules and blow out the cache before replicating the database. That way when my production site comes up, it's streamlined without the extra modules, memory, and overhead needed when developing a Drupal site.

Between my day job and freelance work, I work with D6.x sites hosted on RackSpace, Verio, GoDaddy, 1&1, Dreamhost - the list goes on. As long as you are willing to nut up for a server that is properly sized for the kind of site you have, you should have no problems. It's no different with any other form of software out there. You don't see graphics designers using Adobe Photoshop on entry-level $399 desktops, do you? Is that because Adobe Photoshop (GNU Gimp, pick yer flavor of raster editor) is a "resource hog?" Nope, it's because what you're trying to do requires more than a basic entry-level system can handle.

You're just simply not going to be able to run the next Yahoo, Google or eBay on a $19.95/month shared hosting account... ;)

As for hosting options, bang for the buck I've had good luck with 1&1's Linux VPS solutions - usually stepping up to at least a VPS II for anyone hosting/processing large numbers of images. I think their entry-level dedicated boxes are cost effective as well if you need that level of performance.

"Nothing is impossible - it just hasn't been done yet."

TajinderSingh’s picture

Check settings.php for ini_set('memory_limit', 'LIMIT');

Here LIMIT is the value of memory you are getting error for being exhausted.

I was wandering in tension here and there for looking the reason then just came to check settings.php Never thought that as received the backup from someone else.

So, confirm your all possible locations where memory_limit can be set.

Best Regards,

Tajinder Singh
IMP Technologies
Creating Masterpieces...

purna_dey’s picture

I have solved the problem on this way, i.e i just put the line ini_set('memory_limit', '-1'); on settings.php file and save it. It means that is override on memory limit.

alan_hugo’s picture

Thanks!! perfect ;)