Unable to allocate memory for pool. in theme_render_template

Is this apc warning? I had a similar issue where lots of msg's at ./apache2/error.log. I documented the fix at http://dev.vozmob.net/projects/vozmob/wiki/Web_log_varlogapache2errorlog...

Does http://stackoverflow.com/questions/3723316/warning-require-once-function... help?

Just upgraded my pecl-apc and the error message is gone!

Edit: no, upgrade did not work, after a while, errors came back. I uninstalled it.

FYI - I was getting similar error messages. Clearing cache seemed to fix it.

Warning: include() [function.include]: Unable to allocate memory for pool. in theme_render_template() (line 1247 of /Users/jeno/Downloads/drupalCore74/includes/theme.inc).

I am getting this after installing and configure ubercart. I am using Omega subtheme starter kit on D7.4.

Running update.php would give me this:

Warning: Unknown: Unable to allocate memory for pool. in Unknown on line 0

Any solutions?

Cleared theme registry and problem disappeared

This did it too for me! I got this problem when i switched to my new mac, and started working with the Aqcuia dev stack for the first time! I was themeing and suddently i got thousands of lines of error codes.

I set apc.shm_size=128M and the problem was solved!

Thanks IEFBR14!!!

Set apc.shm_size=128M but error appeared again :-(

Has anyone had any more luck with this? I have set apc.shm_size=96M and it's still showing up on a shared install. I have to clear all the caches, and APC as well to get it to go away.

I face this problem few month ago. I didn't document what I did to solve the problem but if I well remember I had to set apc.ttl = 0 (see http://www.php.net/manual/en/apc.configuration.php#ini.apc.ttl ).
This is a workaround, not a solution. It's not ideal for performance but at least my websites now are always on.

I've tried the same setting and so far so good.

Same as elvin - on the acquia dev stack OSX.
It's got apc on by default.
Upping the memory helped, but as this is a dev box I can also drop the ttl
as suggested as stach exchange http://stackoverflow.com/questions/3723316/warning-require-once-function...

I triggered this by switching locally between 3 or four totally unique local d7 sites - so I think the opcode cachegot overloaded with having so many different include files all in the air at once.

just wanted to mention for some who may have the same issue i did that the setting was not in php.ini. i found the setting in /etc/php.d/apc.ini

for my dev box with this error, i changed to "apc.shm_size=256M" from 64M and errors disappeared. also did a #service httpd restart to be safe.

hth

**** SOLVED *****
2nd of June 2012

Alright, for those of you having this problem here is what I did. I am on OSX 10.7.4 (Lion)
First off, if you DON'T have the apc settings in your /private/etc/php.ini by default, do this (or else just edit your values):

1. Install PHP Pear: http://i.justrealized.com/2011/setup-php-pear-mac-os-lion/
2. Install PHP APC: http://i.justrealized.com/2010/install-php-apc-mac-os/

3. Add these lines to the end of your php.ini file (between [xdebug] and ; Local Variables - might not have an influence, but that worked for me).

Applications -> Terminal -> type in (without quotation marks): "cd /private/etc" hit enter/return -> "sudo nano php.ini" -> scroll all the way to the bottom by holding ctrl+v down for a couple of seconds. -> Add these lines to the end of your php.ini file (between [xdebug] and ; Local Variables):

apc.enabled=1
apc.shm_segments=1
apc.shm_size=128M
apc.cache_by_default=1
apc.stat=1
apc.rfc1867=1
apc.stat=0

So the trick for me was to change 32M to 128M and the apc.stat=7200 to =0.

*************

I had this problem while running Acquia Dev Desktop 7.4.4 (on OSX Lion 7.4)

Copying the apc config variables from #16 into my php.ini (available from ui : settings>config>php:edit) solved it for me.

thanks @esbenmr

I'm getting these errors now after upgrading server from ubuntu 10.04 to 12.04 and I need to up the memory size.

I just want to comment on the apc.stat value. From http://www.php.net/manual/en/apc.configuration.php#ini.apc.stat:

Be careful changing this setting. This defaults to on, forcing APC to stat (check) the script on each request to determine if it has been modified. If it has been modified it will recompile and cache the new version. If this setting is off, APC will not check, which usually means that to force APC to recheck files, the web server will have to be restarted or the cache will have to be manually cleared. Note that FastCGI web server configurations may not clear the cache on restart. On a production server where the script files rarely change, a significant performance boost can be achieved by disabled stats.

For included/required files this option applies as well, but note that for relative path includes (any path that doesn't start with / on Unix) APC has to check in order to uniquely identify the file. If you use absolute path includes APC can skip the stat and use that absolute path as the unique identifier for the file.

I'm assuming now that the two lines in #16 first turning on stat then turning it off is not intentional. Please correct me if I'm wrong, but in general I don't think I'd set apc.stat = 0 unless you really know what you're doing.

@odegard, if you have a stable environment and you're not changing APC settings frequently, it's actually recommended to set apc.stat = 0. There are performance benefits from doing so. If you're working on a development environment or making regular changes to your APC configuration, then having apc.stat = 1 is a beneficial choice.

Thanks to #9 I was having same problem! fixed now!

Doing some playing around, I found out some interesting things (at least interesting to me...)

As Andrea pointed out in #12, I too had to set apc.ttl to "0" as a workaround. Looking into things a bit more, I upped my apc.shm_size to 64M but still received errors when the ttl setting was more than 0. That got me playing around with the apc.max_file_size which was set to 1M. I upped it to 2M thinking it would fix it but that didn't help so I decided to go the other way and dropped it down to 512KB. Next thing I know, my fragmentation which was all over the place went to a very nice and pretty pie chart with very little fragmentation. "Huh..." I upped the apc.max_file_size again to 1M and the fragmentation came back and went all over the place... Dropped it down to 756KB and it smoothed back out.

What I've decided in my experimenting, is that apc.max_file_size is the maximum size that apc will cache. (I'm sure it's in the documents somewhere, but I didn't look...) Since drupal likes to do all of it's bootstraping and what-not, it tends to create files that are bigger than 1M in size, thus is completely chewing through apc.shm_size (apc memory) like a fat kid in a candy store. The memory is filling up and maxing out but not clearing itself to make room and hence throws up the wonderful error: Unable to allocate memory for pool.

So, if everything I have said is true, the guys who increased their apc.shm_size to 128M and it fixed their problem, basically gave APC enough room to work with that it wasn't banging it's head against the Drupal wall...

Now, the downside to setting apc.max_file_size less than 1M seems to be that very little get's cached but in my testing, it seemed to run pretty darn quick anyway...

Just my $0.02 on the matter... I'm no expert but hope it helps to shed some light.

Update:
Uhhh... Yeah...
I upped:

apc.shm_size = 256MB
apc.max_file_size = 2M

and my site runs like a striped ass bandit... went from 3-5 second admin page loads to about 1.5 sec...

Full php.ini settings:

pc.enabled = 1
apc.enable_cli = 1
apc.max_file_size = 2M
apc.shm_size = 256M
apc.ttl = 120
apc.user_ttl = 120
;stat should normally be placed at 1 for production / live environment
apc.stat = 0
apc.slam_defense = 0
apc.mmap_file_mask = "/tmp/apc.XXXXXX"

Can't say it will help you're situation but it might give you a start : )

Hello all,

I am having kind of the same issues, except that I get the error when I flush my caches in the admin screen. I am using shared webhosting linux and got a memory limit of 128.

Argeweb, my provider tells me that this problem is caused by a lack of memory and that I should upgrade to VPS. I am not convinced yet, because there is nothing set for apc in the php.ini and I am thinking Drupal 7x should be working without errors in sharded hosting as well. I never seen this error before with other sharded hosting services.

I tried adding apc.shm_size=128M but that didn't solve the problem.
I am looking at comment #16 now but I am not understanding the part about installing Pear and APC. This on the server side right? Or localy on my pc since this IOS is mentioned in the post?

My php.ini doesn't have much content to begin with:

sendmail_path = /usr/sbin/sendmail -t -i -f webmaster@theater-centraal.nl
session.save_path = /www/t/h/e/theater-centraal.nl/tmp
include_path = ".:/usr/local/share/pear:/www/scripts/webshop:/www/scripts/public"
open_basedir = "/www/t/h/e/theater-centraal.nl:/tmp:/usr/local/share/pear/:/www/scripts/webshop/:/www/scripts/public/"
upload_tmp_dir = "/tmp"
max_input_vars=1500
suhosin.post.max_vars=1500
suhosin.request.max_vars=1500

I don't know much about php, so I am pretty much lost here. Can anyone help me out here?

Thanks ahead,
Gigi

Open your mind to become convinced.

Drupal core only will run within 128MB just fine. You can bootstrap inside 32MB.
But every extra module you choose to add can increase overhead : though in vastly different ways.

If each additional module you add increases the memory requirement by 10% ... You may be able to add just 15 modules before you need a bigger box. It's not necessarily true that every module adds that much each time. Many will be much less, but some with certain configurations are potentially greater.

You can't add unlimited features without having to upgrade at some point. You get what you are able to pay for. You must calculate how much your own time is worth. If you want to spend 4 hours looking for (and failing to find) a work-around to try and ignore that fact and save yourself $20, that means you value your own professional time at less than $5 an hour. And a website run by someone who is worth less than $5 an hour ... is likely to fall over regularly.

Look at your own value. Many times I have spent much time tracking down inefficiencies or optimizations (because I find that interesting and am able to contribute back) but in all cases, the most sensible answer would always have been just "pay a few $ more for a bigger box" and be done with it. It saves days of your life.

Or, just drop some of those slow features that you cannot afford.

I got resolved after I restarted my local server

Kudos !!
apc.shm_size=128M
worked for me .

CentOS release 6.5 (Final)
Drupal version 7.26

#21 works for me
Thanks to philsward

#6 work for me.

#21 worked!! Thanks! (still have to see it working a few days though but it is true that now it is speeding.)

#8 work for me. Thanks.

Since I was getting this error after running update.php after updating some modules, I could not access cache clear from within Drupal nor do I have Drush available, so I went with this solution to get my caches cleared, which resolved the error and got my site running again. Hope it helps someone else.

Put this into a file on your server (don't forget to delete it once it runs).

// define static var
define('DRUPAL_ROOT', getcwd());
// include bootstrap
include_once('./includes/bootstrap.inc');
// initialize stuff
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
// clear cache
drupal_flush_all_caches();

#15 worked for me. Thanks!