I'm experiencing the white screen "Fatal error: Out of memory..." when trying to access:

1. .../admin/build/modules - 100% of the time
2. .../admin/build/views/list - intermittently
3. .../admin/reports/status - intermittently
4. .../admin - intermittently

e.g. - Fatal error: Out of memory (allocated 41156608) (tried to allocate 35 bytes) in /home/kilboa/public_html/includes/theme.inc on line 758

Prior to the error appearing I was running Drupal 6.10, MySQL database 5.1.30, PHP 5.2.8 with 128M php memory with no glitches on a shared server. One night after routine updates of a few modules the error started appearing. Even when I downgraded those modules it was too late. The damage was done.

HERE IS THE CATCH. The error appears after allocating no more than 41156608 bytes (~40M) in EVERY case, sometimes less. This is FAR below the memory limit, which my host - HostGator, has now upped to 512M in an effort to problem solve. They have overridden the set server limits in my case in an attempt to eliminate causes.

Also it doesn't just happen when accessing information from one specific module or module table. I've seen this error attached to:

1. .../sites/all/modules/simplenews/simplenews.admin.inc on line 1190
2. .../sites/all/modules/ubercart/uc_cart/uc_cart.pages.inc on line 190
3. .../includes/theme.inc on line 758
4. .../includes/database.mysql.inc on line 301
5. .../sites/all/modules/views/includes/admin.inc on line 2707

Since the error first occurred, I've upgraded to Drupal 6.11 (in hopes of overwriting any bugs) and I've completely removed some modules using Filezilla and taken many more offline directly through the database System table with no effect. I consistently rerun update.php throughout these changes. So the number of active modules is much less than before the error started to occur.

My host is trying everything but has commented, "...The issue is not that you're hitting the PHP limit, or even the apache limit. You don't appear to be. I honestly think you're hitting the MySQL server limit..."

Could this be a MySQL performance issue or server limit issue? I'm on a shared server. The MySQL database is on the same server as my site. Obviously trying to load the modules admin page is going to tax the database more than any other page I'd guess. But this certainly is not the typical, "you need to increase your php memory" issue that many face when this error occurs.

Did I get a corruption in the works somewhere? I do my Drupal core upgrades by the books exactly as written in the update.txt file, so I'd hoped a fresh install of 6.11 would have cleared it. Why is the error occurring at ~40M when there is so much more php and apache memory available?

Any insight would be appreciated. I'll try anything at this point. My site is like a car that is running fine. I just can't open the hood.



grendzy’s picture

Can you visit /admin/reports/status/php and tell us what it says for memory_limit? Also I would double check php.ini, settings.php, and (if you have civicrm) civicrm.settings.php to see if any of those files are setting memory_limit.

snepa’s picture


Thanks for giving this some attention.

1. /admin/reports/status/php shows "Local Value" and "Master Value" of 512M for memory_limit in the Configuration - PHP Core section

2. php.ini shows:

; Resource Limits ;

max_execution_time = 60
max_input_time = 60
memory_limit = 512M

3. /sites/default/settings.php shows no memory_limit settings at all. Only ini_set statements in the php section.

4. Don't have civicrm.


asespat’s picture

I have the same issue

Out of memory when i go to modules

and i have in php.ini 150M

I'm using drupal 6.12

grendzy’s picture

Is the problem reproducible on other hosts, or does it only happen on hostgator?

If it only happens on hostgator, then I think it's time to find a different host.

If it's reproducible, then I would start disabling contrib modules one at a time until the problem goes away, and then you know what module triggers it. You could then file an issue in that module's queue. (Or drupal core if it happens when only core modules are enabled).

asespat’s picture

I use Hostmonster

iameric’s picture

same issue, also using hostmonster.

snepa’s picture

The latest feedback from my host - "I increased the MySQL memory limits today...Even with that adjustment, nothing changed on your site. The problem still exists, exactly as before." They said they have "seen Drupal have memory leaks, before, where it would always report it was running out of memory at the same amount, but would always say it needed more, no matter how high the limits were raised."

asespat’s picture

I tried to change the memory limit in settings.php

as is described here


but nothing changes

allnet000’s picture


I am using Hostmonster as well and running into the same issue. Where you able to fix this problem and if so, how?

Thank you in advance.

deumatasha’s picture

I tried this and it seem to have worked for me. not sure if it will revert to its old ways, but for now its working find, no more memory low messages.

Gaperville’s picture

After attempting to figure out this crazy memory error with the ini, htaccess, and the settings.php files , I finally went to the /admin/reports/status to find I was only using 64 and my ini file said 128. I added the same ini file in the root of the public_html and it shows the 128 now. My drupal is on a test directory one level down.

paulmckibben’s picture

I find it really odd that your memory is capped at 40M even though your host has set the memory limit to 512M.

This is a real stretch, but is it possible that one of your contributed modules, or one of your theme files, is setting the memory limit to 40M using the ini_set() call?

halver’s picture

I am having a similar issue. I, too am using hostgator. I have upped the memory limit in php.ini to 64M. When I enable panels and ctools, I get the following error on the admin/modules page:

Fatal error: Out of memory (allocated 40370176) (tried to allocate 1042307 bytes) in /home/mysite/public_html/includes/database.mysqli.inc on line 303

I asked hostgator why I was hitting the wall at 40M. They replied:

"The problem is with the Apache memory limit. Apache is limited to 80MB on our servers, and this limit must include the apache process itself, PHP, and any libraries loaded by either of them. You may want to try disabling other modules before enabling the new one."

On their website, hostgator says it limits memory to 64M.

I am not using an excessive number of modules. Just the standards: views, friendlist, imagecache, etc. What can I do? Should I really be using this much memory?

FYI: I'm pretty new to all of this.

grendzy’s picture

It sounds like hostgator isn't being truthful about the memory limit they advertise. Another user has reported something similar with BlueHost. (http://drupal.org/node/371789) I think you have a choice between upgrading to a plan with more memory (or a different host if this isn't possible on hostgator), or using fewer modules.

64M is a lot, but it can add up fast once you start loading up contrib modules. Panels and Views have significant memory needs, and imagecache recommends 96M if the images are large.

altbzh’s picture


I have also a shared server and admin server sais that it was not a PhP memory problem but a data base problem.

orianasarac’s picture

To get around problem of having no access to Modules due to out of memory message, you can disable modules through settings in the database. Go to phpmyadmin interface and locate system database. Browse and locate modules that you may not be using or you think may have caused out of memory. Update record by setting the status to 0 instead of 1. Refresh your /admin/build/modules page. To finish uninstalling modules, go to uninstall tab and select unnecessary items. This will hopefully just get you back in a state where you can now make choices which modules you want to keep till you sort out memory requirements with your provider.

altbzh’s picture

how can we know the memory we need (only an idea !) : I think I have not too many modules ! 32 Mo ? 64 Mo ? How for a small or mid Drupal site ? I think Drupal needs more much memory than other CMS ?
Anyway, thank

sendmycard’s picture

Dear all,
I have been labouring over this with a new site we have built Send My Card.
One clue - I have just finished customising the Alagna theme in Marinelli.
I flipped back to the 007 niGraphic Studio and hey presto - I can list my modules again.
This was driving me crazy - it clearly is a memory issue of some description, but in our case was theme related. I also took out lots of modules in the system table to no avail.
I hope this helps!

jjbarrows’s picture

I was having this problem, so adjusted memory limit to 320M in php.ini
drupal still reported it as 16M - so I restarted apache, all fine now, drupal show new 320M

chrisroge’s picture

I upped my memory limit in php.ini to 320M as suggested and problem gone. Can now access modules etc.

Antonius’s picture

I am experiencing the same issue. I am pretty sure that no changes have been made to my site for awhile, but now I get periodical Fatal Error messages, either pointing to the database.mysql.inc or cache.inc, when I try to load the Modules page.

I called 1and1 and they assure me that no changes have been made at the server, however, they do confirm that the set memory limit on shared hosting is 40M.

Any ideas?

KathyIce’s picture

I'm having this problem too... I suspect it is a Drupal problem vs. a memory limit problem vs. hosts being too limited.

(FWIW - we're running the latest D6 on HostMonster w/ memory limit (apparently) maxed out at 96MB...I have it set higher in php.ini, but when I run the status, it says we've got 96... also Hostmonster support said the memory being asked for 100MB was "close to the limit".. I suppose they should have said "over the limit")

TEMPORARY WORKAROUND - When I disable Devel modules (using the Admin menu under the icon), everything else works fine... I got my modules page back. So, that's a possible temporary fix for those getting messed up by this.

After disabling Devel modules, I re-enabled imagecache_ui, views_ui and util ... and things still seem to be working all right.

We have not had the Devel Theme module enabled (presumably due to incompatibility with older version of Zend Memory Optimizer), because there were several WSD issues on that module at the time we were looking at it, and we can live with out it... However, this WSD problem started showing up without the Theme module enabled... and we are seeing Zend errors on our server log.

Here's a sample of what we get in our server log, in case it helps (sorry for funky formatting):

Error Logs
[Wed Jun 24 06:01:39 2009] CURRENT SERVER TIME MAIN error_log: [Wed Jun 24 06:01:01 2009] [warn] RewriteCond: NoCase option for non-regex pattern '-f' is not supported and will be ignored. [Wed Jun 24 06:01:02 2009] [warn] RewriteCond: NoCase option for non-regex pattern '-f' is not supported and will be ignored. [Wed Jun 24 06:01:03 2009] [error] [client] File does not exist: /usr/local/apache/htdocs/install.txt [Wed Jun 24 06:01:03 2009] [warn] RewriteCond: NoCase option for non-regex pattern '-f' is not supported and will be ignored. [Wed Jun 24 06:01:18 2009] [error] [client] Failed loading /usr/local/Zend/lib/Optimizer/php-5.2.x/ZendOptimizer.so: /usr/local/Zend/lib/Optimizer/php-5.2.x/ZendOptimizer.so: undefined symbol: compiler_globals SUEXEC error_log: PHP error_log: /home6/icenogle/public_html/error_log: [24-Jun-2009 05:04:54] PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 7680 bytes) in /home6/icenogle/public_html/modules/acquia/views/views.module on line 895 [24-Jun-2009 05:04:55] PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 7680 bytes) in /home6/icenogle/public_html/modules/acquia/views/views.module on line 895 [24-Jun-2009 05:05:20] PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 7680 bytes) in /home6/OURSITE/public_html/modules/acquia/views/views.module on line 889

tchurch’s picture

I can't seem to resolve this, even though I've done some of the things suggested.

Fatal error: Out of memory (allocated 34865152) (tried to allocate 19456 bytes) in ... /sites/all/modules/views/includes/admin.inc on line 3051

I have 320M in my php.ini file.

tchurch’s picture

I've managed to rebuild my site from a snapshot I took using a Demostration module and now I can access the modules page.
My problems seem to start when I delete a role.

Wolvenheart’s picture

Same problem here, on two different sites hosted on two seperate hosts.
While I haven't been able to solve it through any pointers in this thread, I did have a nagging suspiscion for one of the two sites that it was theme-related, and one of the posts in this thread strengthened that suspiscion for that one site, but even swithing back to the standard theme didn't do the trick.
For the second site I'm clueless as far as possible causes go; it has been on the standard theme, latest version, host has plenty of memory... it only has two modules installed (CCK and the one that shows that very useful admin bar on top, I forgot the name).

For both, the error shows up when I'm trying to work under admin.
I can access admin fine, but some functions I can't access at all anymore, in the case of the second site it seems to pick random functions at random occasions.

I'll continue scouring the web for answers and if I get anywhere before an answer shows up here, I'll post a walk-through of what fixed it for me.

cflemm’s picture

I also get this Fatal Out of Memory error always around 40mb. My php memory limit is set to 256mb and shows as 256mb on the Status page, very frustrating!

My error starts when I enable the phpbbforum module, but I suspect this is due to the memory requirements of the module causing the site to get to the 40mb tipping point. I tried running without the admin_menu module (as suggested above) with no luck. I will try disabling CCK maybe. I am running:

Drupal 6.10
CCK 6.x-2.2
Views 6.x-2.3
Date 6.x-2.2
Administration Menu 6.x-3.0 alpha 1
A good list of other modules

nhoeller’s picture

I am running Drupal 6 on a shared 1&1 web server that restricts PHP scripts to a maximum of 40MB. Increasing the "memory_limit" in php.ini has no effect, even though php_info() reports the higher value. I am in the process of building a 'core' Drupal configuration that I could cline and tailor for various Drupal websites. I had upgraded to Drupal 6.13, refreshed all the modules and had added five additional modules when I hit repeated "Fatal error: Out of memory (allocated 33030144) (tried to allocate 846209 bytes)" from Admin/Modules. Removing Admin_menus and Devel did not help. I was able to get Admin/Modules working by moving the most recently added modules out of 'sites/all/modules'.

Clearly, I either need to find a hosting providing that allocates more PHP memory and/or dramatically reduce the number of enabled modules. However, the following analysis may be of interest for others having the same problems and may suggest improvements to the Admin/Modules code.

I added a 'memory_get_usage()' call to the 'db_query' function of 'database.mysql-common.inc' to dump memory usage prior to the SQL call. The largest memory allocated in this successful run was 27.3MB. I then added the new modules back in, most of which were already enabled from the first time I added them. I had two more modules to add and was still able to load Admin/Modules successfully, with memory peaking at 29.5MB and then dropping to 28.8MB.

Without doing anything else, I refreshed the Admin/Modules page and got a "Fatal error:" with maximum memory allocated 33.2MB. I compared the two memory dumps. The successful attempt had 9,000 entries, while the failing one had 10,300 entries. In both cases, I started at about 457KB which rapidly climbed to 14.7MB at entry 11 after the SQL statement that extracts module information (name, filename, throttle) from the 'system' table. Memory usage rose quickly to 23.9MB before entry 100 - it looks like vocabulary information was being extracted and various 'cache...' tables are updated.

Memory usage stays relatively steady until within 303 entries of the successful attempt and 48 entries of the failed attempt. The successful attempt shows the following memory usage:
* 27.3MB to the first 'SELECT m.load_functions, m.to_arg_functions, m.access_callback'
* 27.7MB to the second 'SELECT m.load_functions, m.to_arg_functions, m.access_callback'
* jumps to 29.1MB prior to the next SQL call
* peaks at 29.4MB and then drops to 28.8MB

The failing attempt shows the following memory usage:
* 27.8MB to 'SELECT DISTINCT(category) FROM {profile_fields}'
* 28.9MB to 'SELECT data, created, headers, expire, serialized FROM {cache} WHERE cid = '%s''
* 30.9MB to 'INSERT INTO {cache} (cid, data, created, expire, headers, serialized) VALUES ('%s', %b, %d, %d, '%s', %d)'
* 30.2MB to the first 'SELECT m.load_functions, m.to_arg_functions, m.access_callback'
* 30.7MB to the second 'SELECT m.load_functions, m.to_arg_functions, m.access_callback'
* jumps to 32.3MB prior to the next SQL call
* peaks at 33.2MB and fails shortly thereafter

There are a few differences in the SQL around the point where the two logs diverge, including the 'SELECT DISTINCT(category) FROM {profile_fields}' statement in the failing log (see above).

zbombicz’s picture

Same problem... subscribing.

keith_k’s picture

It's happening to me too.

JayNL’s picture

Get better hosting. My KnownHost VPS never has these errors. HostMonster, BlueHost (same company) and HostGator are OVERSELLERS, which means they grocely sell more resources than they can deliver. Don't put a horse like drupal on such a low quality shared environment.

keith_k’s picture

OK. I figured out a way to get around this: temporarily disable the imagecache module

  1. In your site's database, go to the system table.
  2. Change the status column to "0" for imagecache (you don't even need to do this with imagecache_ui)
  3. Do whatever you were trying to do at /admin/build/modules/list
  4. Turn imagecache back on by setting status back to "1"

On my site, this is clearly the module that's causing all my problems. However, I can't give up imagecache since I want it for my photos and images. This is working for now...

aklouie’s picture

The size of your images drives the resource usage of imagecache. IIRC for large images (about 1mb jpg) my imagecache using gd will require somewhere between 30 and 60mb. If you're only uploading smaller images, the resource requirement will be significantly less.

Using a dreamhost PS server, when I use imagecache on large images, I always have to adjust my memory resources to around 300mb or greater (2mb jpgs required a spike to 400mb to process sucessfully).

I haven't done serious testing, but this is generally from watching Top in the shell command line.

owntheweb’s picture

I'm having the same issue on hostmonster as well.

When I first installed Drupal from scratch, the module page loaded fine, even with 15 or so non-installed modules visible. When I tried to install them, I got the error. Now, when I simply try to access the modules page, I get the same error with no success.

Changing themes, running in a circle, or barking like a dog doesn't help. :(

I seem to have great success on my Godaddy shared hosting account, however I need to get my current site working on a hostmonster account. I don't have much choice right now.

I look forward to additional feedback.

Worlds to explore. Worlds to create.
Blog: http://www.christopherstevens.cc/blog
Twitter: http://www.twitter.com/owntheweb

aklouie’s picture

For everyone else's information, check your status report and note the php memory limit.

orianasarac’s picture

I have been able to (un)install modules using workaround solution I have posted few weeks back. Again, I hack the system table for newly installed items - update the 'status' column from 0 to 1 to install module. To uninstall, I change value from 1 to 0.

Here are the step and additional information:
1) Copy new module to sites/all/modules directory
2) Access the url http://yoursite.com/admin/build/modules - you will get an error. This step is necessary to update the system table with this new module info
3) Go to system table, search for your new module and update record by setting the value of the status column to 1
4) Refresh http://yoursite.com/admin/build/modules - this 'installs' your module, so it can show up on your admin page
5) Go to http://yoursite.com/admin and locate settings for your new module

I have noticed that sometimes this does not fully work - the tables for the new module are not created in the db. To overcome that, I have created an additional test site with a minimum number modules installed, which does not give me 'out of memory' error. That way, I can see what are the tables necessary for the module to work.

Here is how:
1) Install the module in the 'clean' test environment using UI http://yoursite.com/admin/build/modules - this creates all necessary tables in the db
2) Locate new table(s) in the 'clean' test database and get SQL structure through export feature in phpMyAdmin. I only used 'create table' part, not 'insert data'
3) Create table(s) using the export SQL in the environment that is giving you error

So far, I have been able to install 6 new modules on my site and it has been working without problems. I do spend more time testing than usual. Hope this helps.

If you see major flaws of this approach (besides that it's a total hack ;) please let me know.

nhoeller’s picture

At least in the case of the 1&1 shared web hosting service, the Status report/PHP memory limit values do not reflect reality. Right now, it is showing 256MB (the value set in php.ini) but I know 1&1 caps me at 40MB.

keith_k’s picture

So after a long dialogue with Hostgator -- 45 minutes+ chat and a dozen emails, Hostgator tech support did fix it for me.

The "smoking gun" I presented to them was the code I posted at the bottom of this post. My php memory limit was clearly 64mb (set by my php.ini file) but I could only "use" 40mb. This was obvious when you run the script on the server.

A couple of useful quotes from tech support:


"This script may be hitting the apache server limit and not the php limit."

"You will need to check the scripting to keep it from hitting the apache memory limit."

"The php limit is set to 64MB, but that is not what is stopping the script from running."

"You can have the memory limit corrected as well within the apache .conf file."

I pushed back and requested that he do it for me. At this point, he established a support ticket to pass me on to someone else. The next guy that came on and after he got caught up, I requested that he raise this "Apache memory" limit to 64mb. He said:

"I can raise the apache memory limit a little to accomodate [sic] any particular script that might be having issues, but I cannot simply remove them entirely. This would allow all users to use any amount of memory simply by using perl instead of php. If you have a particular page that isn't loading because of these memory limits, give us the URL so we can see how much we would need to raise the apache limits and make our decision at that time."

I then explained that I needed to access the modules page, explained what it was, and gave him access to check it out. He came back with:

"I permanently changed the setting for the domain so it can use 64mb"

It's working fine now. So, there you go. I had been pulling my hair out, trying different ways to increase my memory up the 64mb that I understood to be advertised. It was particularly insightful that there were TWO DIFFERENT types of memory limits: an Apache limit and a PHP limit. I still have no clue what the difference is.

So, thanks to Hostgator tech support, their understanding and willingness to make the change, and a little persistence. I'm up and running now!

Personally, I don't want to harp on Hostgator. I thought their tech support was courteous and helpful. They "stuck in there" with me and tried to explain what was going on and why they did what they did. When my request was deemed reasonable, they made the adjustment. That's what good tech support should do.

Here's the code to test how much memory you are able to use. Save this into a new .php file somewhere in your pubic_html folder and access the file via your browser. You'll have to change it if you want more than 64mb.

// phpmemory.php

$memlimit = 64;
print 'Expected memory limit ' . $memlimit . 'MB <br />';

$memory_mb = round(memory_get_usage() /1024/1024 , 2);
print 'Base  -> ' . memory_get_usage() . ' (' . $memory_mb . ' MB)' . ' <br /> &ensp; <br />';

$pattern = str_repeat("0123456789", 1000);
$fill = str_repeat($pattern, 1);
$counter = 1000;
while ( $counter <= 6500 ) {
	$memory_mb = round(memory_get_usage() /1024/1024 , 2);
	print 'Clear -> ' . memory_get_usage() . ' (' . $memory_mb . ' MB) <br />';
	print $counter . ' x 10000 chars -> ' ;
	$fill = str_repeat($pattern, $counter);
	$memory_mb = round(memory_get_usage() /1024/1024 , 2);
	print  memory_get_usage() . ' (' . $memory_mb . ' MB)'. ' [' . $memory_pct = round($memory_mb / $memlimit *100 , 1) . ' percent]<br />';
	$counter = $counter + 500;
print '<br />If you can see this, the server can allocate something close to 64mb';

Credit: I got the idea from here. http://drupal.org/node/371789#comment-1334640

Output looks something like this if you get 64mb; you get an error when you're being throttled.

Expected memory limit 64MB
Base -> 60272 (0.06 MB)
Clear -> 70564 (0.07 MB)
1000 x 10000 chars -> 10070640 (9.6 MB) [15 percent]
Clear -> 70760 (0.07 MB)
6000 x 10000 chars -> 60070772 (57.29 MB) [89.5 percent]
Clear -> 70760 (0.07 MB)
6500 x 10000 chars -> 65070772 (62.06 MB) [97 percent]
If you can see this, the server can allocate something close to 64mb
jeffjohnvol’s picture

I stumbled across this conversation when I got the error you guys are getting. I have two sites with the same modules, both on 1 and 1. I was getting the module errors on one site, but not the other.

I had to go to dinner, and when I got back, I remembered they are on different themes. I put the problem site on the default theme, issue gone, then back to acquia marina (sp?) and tried again, but no error this time.

so..... I'm not sure if being away for 2 hours made a difference or not, but ya'll may want to try different themes to see if it makes a difference.

I did try that phpmemory trick that kieth_k listed and I got the same result before and after dinner in terms of the error at "3500 x 10000 chars ->"

I also tried the imagecache disable/enable but it didn't help me at the time, unless it was a caching issue at the time.

ralfvk’s picture

thanks for that post, I was about to get nuts about it.
Just changing the admintheme solved it and I was able to get to the module page again.
I am also on 1and1 shared host.

kvvnn’s picture

This was a great comment - Thanks.

Interestingly enough, I used this on our Host Gator server, and even when settings "memlimit = 1" , I got a memory error. Unsure what that means, as I my previous errors were at like 40MB and I expect the Drupal processes that were working to be above 1MB.

In the end, we are leaving Host Gator and going back to Media Temple. I had a staging site on MT and it has worked without issue. I am not advertising MT, but, people should now which host works well with Drupal.


rocket777’s picture

Every time I upgrade I am having this issue.
So I have to increase the php memory limit. I am not sure if it's ok to run it as high as 320mb as some have suggested.
What is the best solution for this.
I don't have devel installed on production but I do run cck,views,image etc

E Ismail

jeffjohnvol’s picture

Which theme are you using? Changing my theme "may" have helped me. Not entirely sure though. Worth a shot.

jeffjohnvol’s picture

I'm not sure if this will fix the situation, but I had about 5-6 themes available for use. I inactivated all but two of them (Acquia Maria-sp? and Multiflex-3, hit save, then went back to modules and it worked fine.

Hope this helps.

rocket777’s picture

Thanks, I also typically disable the themes I don't use.
So currently I have my custom theme, which uses Zen and I use garland for admin
So 3 themes are enabled

E Ismail

jeffjohnvol’s picture

Did it help your situation?

rocket777’s picture

Yes, it did help, thanks

E Ismail

orianasarac’s picture

I am curious if this problem prevents from normal execution of the site in general.

So far, I have been effected only when trying to install new modules or export CCK types (admin role actions only), till recently. Some of more intensive views (loading up to 500 objects/locations using GMaps module) started to give me error intermittently. Once I have limited the display to 300 elements, the errors are gone. However, since I was not able to locate errors in the log file, so I am not confident that the problem is not reacquiring. I haven't received any emails from my users to report the problem, but that doesn't mean that the problem is not there. Anyone else?

My webhost provider is 1&1 and had their customer service rep offered Dedicated Server package as a solution, which requires manual upgrade. This is not a solution for me, so I am considering switching to another provider. I would rather avoid if painful migration if possible. Has anyone else had much luck trying to convince 1and1 customer support to upgrade memory limit, just like hostgator?

jeffjohnvol’s picture

I too am a 1and1 victim. They don't want to touch it. I know hostgator has opened up their limit for some people, but not sure how easy it is to convince them.

My biggest problem is with the module page, and I've been trying to look at the code so I can output the memory usage of each module when loaded, but I got distracted and haven't gotten back to it. Thought being that I could weigh the value of each module's memory usage versus actual need of the module.

I would love to have a module page that would only pull up one group at a time (Core, Other, CCK, Views) etc, but I haven't had much luck getting any interest in it and lack the skills to do it at this point.

jeffjohnvol’s picture

I switched over to a host that doesn't cost much more than 1and1.com and it totally fixed my problem. I don't want to be an advertising shill, so if you contact me I'll send you the host, but its the same one that the user Michelle recommends. I'm sure there are MANY other good hosting companies that specialize in drupal. Just make sure they give you more than 40 mb. I have ALL my modules turned on, plus some more and no memory issues!!

idcm’s picture

I have been having the same issue but not in a shared environment, on an individual server account at hostgator. Memory set to 96M and the apache server is no restrictions. Not only am I getting the memory issue around 40M but the database does not appear to be updating. Examples of things not updating:

1. I disabled all the themes except Garland but the variable table still shows the default theme as chameleon and there are Zen theme settings in there as well.

2. Status report shows a module that needs to be updated. I confirmed that its status was '0' and since I didnt want the module anymore, I went ahead and deleted it from the server as well as from the system table. It still thinks the module is installed and in play. Where else is it being referenced? I dont see a taxonomy_csv variable any place but maybe it isn't under this name.

3. I can't clear cache via Performance so I cleared it manually. Cache has not rebuilt itself (like it has on other sites I have).

4. I tried setting imagecache to '0' but that didn't help so set it back to '1'

I have run cron.php several times hoping it might update whatever is the issue.

I am concerned that there is something wrong with D6.13. Thoughts, suggestions?

idcm’s picture

The issue I posted above may be a domain issue. When I migrated to a dedicated server at hostgator, I changed the Arecord on godaddy to point to the new IP address. Everything was working fine until this morning when apparently godaddy dropped all Arecord settings for my domain and the DNS servers reverted to the old shared account IP (where the memory issues started).

I had no idea that the memory issues I was seeing were those from the old shared account that had not been closed yet. It also explains why the database on the dedicated server was not being updated.

I just did a nameserver configuration (versus the Arecord approach chosen by my predecessor) and am waiting for the DNS to propagate.

SO ... there is a lesson for you. Check where your domains are pointing if you have a legacy account. If I further issues, I'll be back

idcm’s picture

to be fair to godaddy, the drop occurred when one of the staff thought to create a nameserver instead of an Arecord and didn't have all the instructions - hence it broke but he didn't know.

philsnipes’s picture

I had exactly the same problem - site was 20% built, using a high number of modules and could not gain access to a multitude of pages along with modules page resulting in the dreaded "Fatal error: Out of memory..." . On the back of which I then got a repeat string of error messages whereby I can only assume other modules were failing to complete tasks, notably 'Search Config' and 'Devel' mostly.

I read this and other forums to see a wave of people seeing the same thing - contacted my host who confirmed both my php and Apache mem allocation was at 128MB. My errors still reflected the php mem allocation failing at around 32MB setting nonetheless. My php.ini was changed, as was the htaccess file and phpsettings file as per the above notes to cover all bases. (http://drupal.org/node/76156)

The problem was therefore inexplicable, as it still occurred - however after the problem was escalated, a single line of "RLimitMem 128000000", in the .htaccess file under my public_html dir fixed everything. I then ran cron, flushed caches and BANG! Everything was back to normal - no server errors at all. Suggest that you gain confirmation of your max. allocated mem space from your host and adjust the figure to suit your own requirements, of course.

Cost me a week of going crazy - but all well now.
Hope this is useful for some of you....

zamek’s picture

I was having the same "out of memory" problem every time I enabled the "Panels" module. I added your suggested line of "RLimitMem 128000000" in the .htaccess in my Drupal directory and that seemed to fix the problem.

Saved me a week of going crazy. Thanks!

intent’s picture

Not sure what to say, except "Wow!" and "Thank you."

I was beginning to become resigned to the idea that I would probably have to switch hosts (currently using HostGator) just to see if that would resolve this issue. Added your suggested code to my .htaccess file, ran cron, and cleared cache and, voila, error disappeared.

Thanks for posting.

holsworth’s picture

VPS host Wiredtree.
I was about to give up on the host and drupal ..thanks!

portulaca’s picture

This fixed it for me too, on hostgator.

micheleannj’s picture

Thanks for this fix! It really ought to be documented along side all the "php memory limit" How Tos...

Toque’s picture

Thanks Phil, that worked for me.

dockstaderj’s picture

Worked like a charm! Thank you so much

orizonmedia’s picture

You got it, memory limits set in php.ini is not reflected on our VPS server for a reason that we actually dont know. The answer was in the error line....

Fatal error: Allowed memory size of 33554432 bytes exhausted

33554432 bytes == 32MB

putting the line «RLimitMem 128000000» on .htaccess file on our server root allow now 128mb to php memory.

Everyhting work perfectly now!!

rahulbarge21’s picture


Yes it works for me RLimitMem 128000000

Thank you,
Rahul Barge

rwilson0429’s picture

Thanks for this. That 'Fatal error: Out of memory' thingy drove me crazy. I'm sane again thanks to your post.


JayNL’s picture

... and find out that all complaints come from a low quality shared hosting provider. 1and1, HostGator, BlueHost, HostMonster... all crap. Check out webhostingtalk.com and do a search for these crap hosts to find out you're not alone.

The solution is simple, but not free: get better hosting. Get a VPS or at least a big reseller package, from a GOOD hosting company, not a groce overseller.

Liliplanet’s picture

Looking good! works for me .. adding RLimitMem 128000000 ot .htaccess

mlosee222’s picture

I had the same problem at siteground, except it was only when enabling the Update module.

I eventually switched to cirtexhosting to get FFMPEG support and I have had no problems with module memory there.

Also, I know there are other threads about this, but I just want to reiterate that siteground is a terrible host. you can call the sales line and get connected to them instantly... but the support number is completely inexistent. That's a Big red flag there that I wish I saw before I signed up. I'm loving cirtex though

Ben Kim’s picture

Currently struggling in 1 and 1. Getting crazy with memory limit since last autumn. These days no test possible because of memory restriction of 32MB. I tried every solutions in this thread to result in vain.

Finally I have come to conclude that all errors are originated from the physical memory shortage of hosting server. Then, couple of days survey drive me to consider moving to http://rimuhosting.com.

There is no review found in Internet about this new host. But their spec sheet looks charming, (http://rimuhosting.com/vps/aboutvps.jsp) and VPS price is $20 only. It's very hard for me to keep my composure with these terms.

Not familiar with VPS and rimu hosting, any comments are welcome.

Akrotiri’s picture

I'm also getting out of memory messages when running cron.php as a scheduled task.

Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 46080 bytes) in /home/sites/my site/public_html/sites/all/modules/diff/diff.module on line 511

I was using PHP 4.4.9. My host came up with a potential solution of running chron.php under PHP 5. I'm not sure if this has worked or not. The message I now get is:

PHP Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent in /home/sites/my site/public_html/includes/bootstrap.inc on line 1019 PHP Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already

Any help greatly appreciated :-(

couturier’s picture

* Follow-up note: I did switch to better hosting and my memory limit issues are completely resolved, even with modules added back to the site. Get good hosting. Even a 128 MB memory limit may be too low. I'm now on a professional commerce plan with Hosts of America, who are Drupal experts. Also, disabling Views caching within the Views API may help reduce memory limit overload for weak servers, but lack of Views caching does slow the site. Again, just get better hosting. *

Previous comment:

This thread was helpful to me in deciphering a "user warning: Out of memory; check if mysqld or some other process uses all available memory" message. After trying several solutions that did not work, I finally solved the problem by disabling some modules which I've seen called "memory hogs." My host is allocating 95 MB of PHP Memory for my site, but it was not enough for all the modules I had running. The modules I had enabled when the error message began occuring included the following, and I've starred the ones I disabled to get my PHP memory requirements back under 95 MB:

  • * Advanced help
  • Backup and migrate
  • CCK
  • * Comment notify
  • Filefield
  • Image
  • * Image API
  • * Image cache
  • Image field
  • Image assist
  • * Lightbox 2
  • Link
  • Markdown
  • Mollom
  • Pathauto
  • Print
  • Site verify
  • Token
  • Views
  • Xml sitemap

In particular, I wonder if the Image API and Image cache modules were tipping the balance. I've seen posts where those programs, along with Views, were called "memory hogs." I couldn't disable Views ("the known memory hog" according to one post) without ruining my site, so I took down what else I could. I've also seen posts where developers were able to increase their PHP memory limit to 128 MB or even 320 MB or more in some cases, before the memory limits were adequate for the modules they were running. The server that my host is running has a limit of 100 MB, so I will need to move the site to a server with greater resources if I want to add back more modules in the future, which I plan to do when I incorporate Ubercart (or the new Drupal Commerce in D7 that is scheduled to be a better replacement for Ubercart, with an upgrade path from Ubercart, from what one involved developer told me). Ubercart utilizes some of those image-related modules I had to cut for now.

When looking at entry-level hosting plans for professional Drupal sites, I'm seeing something like this: 128 MB Memory, 64 MB Swap Space, 10 GB storage and 200 GB/mo transfer. Mine is the only Drupal site that my hosting company has ever had (I paid for the year with them before discovering Drupal), and they told me that with just looking at my site, they could not believe that I would come near the 95 MB limit and that with all the other database-driven sites they had produced, they themselves never came close to that. However, I've seen posts where Drupal was called a "workhorse," not suited for a shared hosting environment with limited resources, and I've seen PHP limit requirements of 128 MB or higher commonly in Drupal posts, so I really do think that was the problem, not my amount of content, but the requirement of the modules themselves. I've seen posts stating that Drupal 7 core alone will require 40 MB memory, not including the database, module and content requirements.

Final note, I did do a clean re-install of my version of Drupal 6 along with disabling some of those memory-eating modules, and I don't know if the re-install helped fix any part of the problem. I've seen feature requests for D7 that each module should post its own prominent listing somewhere of how much memory it uses so that memory limit problems can be more easily assessed. Also, there is the need to make sure that the memory that the host claims it is allocating to a site is actually the amount of memory available for use, and other posts address this topic and how to test for that. Hope this helps someone.

Todd Young’s picture

I could have sworn that 1&1 used to have a 40M limit, but I just called and confirmed in writing that their shared hosting is ONLY 30M! But then I tried the "RLimitMem 128000000" tip above and miraculously I stopped getting the WSOD's! Thanks a bunch - I can't believe I've been dealing with that for years without finding that trick.

1&1 now offers up to 80M in their "Dual" hosting - whatever that is - and it's about the same price but you have to manually migrate your sites - what a drag. Actually, I don't believe the Customer Service rep that told me that - it would be suicidal for their retention rate. I'm willing to bet you can click-upgrade your account.

Todd Young’s picture

Well, the RLimitMem seemed to fix many errors, but not all. But luckily the 1&1 customer service agent was mistaken; an upgrade from the "business package" to the "Dual Unlimited" package was completely automatic - it's pretty much just a change in policy and billing. Now I allegedly have 80 Megs PHP memory instead of 30 MB and for like two bucks a month difference.

Scatterspell’s picture

I had this issue. It only came up when I tried to access certain administration pages (Service Links and User Account settings.) After trying every issue under the sun, including uninstalling modules, I finally uninstalled Comment Notify and the problem stopped. Still unsure what the actual issue was, but it's stopped now.

jmcerda’s picture

My eyes glazed over after reading the first half of this discussion, so I'm not sure if anyone has suggested a reboot of the server, or even simply restart apache ( /etc/init.d/apache2 restart ). This might be a bit obvious, but there have been many times when I thought my coffee machine was broken but it was simply unplugged (that was a joke).

Jooblay.com’s picture

We fixed this issue after glazing or was it blazing:) with file permissions. Check the actual file permissions on directories defaults, and file settings.php as most of this discussion has been focused on memory. Which turned out to not be the issue at all for us on the 500 error. Some times you tick something and then space it!)

This is a little more info from Greengeeks.com:

Error Codes

500 Internal Server Error - If you see an 500 error appear randomly, this is because our system is limiting you for exceeding your memory limit. You will have the ability to optimize your site to prevent this error from occurring by using caching plugins, optimizing code, etc. Note: This error code is also common when incorrect permissions or file types are uploaded to the server. If you're not sure, you can always contact our support and we'll be able to help you determine the issue. However, you can check yourself by looking at the Resource Statistics in your control panel to see if you're hitting your limit.

ckopack’s picture

THANK YOU Phil Snipes!

I was having this problem and it was driving me nuts for a week until I found this post. Most of my images were working fine, however any images that were uploaded over 5MB or so were coming up broken after being processed for Views or the front page etc.

IMPORTANT: The fix has to be applied to the ROOT .htaccess file though. Not just the one in your drupal folder. I also increases my memory limits as found here: http://drupal.org/node/207036

Vako’s picture

I added "RLimitMem 128000000" to my .htaccess file and still the same. Everytime I access any of the Admin pages or any configuration page the site crashes with Fatal Error: Out of memory or SQL has gone away messages.
I use the Droptor service which is a very nice Drupal monitoring system, it mentioned that my cron is not running and that the watchdog table is getting too large. I fixed cron working with my ISP and optimized the Watchdog DB using cPanel's myPHPAdmin and the site came back to normal.
So this is another solution that might help someone.

Also check the Droptor module, it's free and amazing! http://drupal.org/project/droptor

my_boss_will_fire_me’s picture

The problem was therefore inexplicable, as it still occurred - however after the problem was escalated, a single line of "RLimitMem 128000000", in the .htaccess file under my public_html dir fixed everything.

On stinking hostmonster here, and adding RLimitMem 512000000 per Phil's advice, all is working fine! (on Wordpress!!!)