"Fatal error: Out of memory..." occurring well below set PHP and Apache memory limits

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.

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?

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!

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

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?

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.

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.

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).

Same problem... subscribing.

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.

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:

Chat:

"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 ) {
	unset($fill);
	$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

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

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?

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....

... 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.

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

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.

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 :-(

* 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.

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.

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.

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).

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

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!!!)