Description:
------------
APC 3.1.3p1 running with php 5.2.11 produces warnings like this in the error log:
[Mon Dec 7 14:35:36 2009] [apc-warning] Unable to allocate memory for pool. in /home/hanno/websites/test.hboeck.de/htdocs/wp-settings.php on line 337.
(seems to happen often on Wordpress or Mediawiki pages)
Everything seems to work like expected, though this warning pollutes the error log. This does not happen with 3.0.19 (stable) apc or php 5.3.1 (with apc 3.1.3p1).

Pull Requests

History

Can you verify that you are not out of either system memory or APC cache memory (check this one using stats on apc.php)?

[2010-01-06 09:34 UTC] banpei at banpei dot net

I get the same errors polluting my error log, but in my case for about every php script on all hosts.
I am running APC 3.1.3p1 with PHP 5.2.12 and Apache 2.2.14-r1
My server isn't out of memory and I already raised the amount of memory for APC from 30MB to 60MB (apc.shmsize).
This did not solve the problem and after downgrading to APC 3.0.19 these warnings stopped from appearing in my error log.

[2010-03-04 19:31 UTC] contact at stellablue dot org

Happens here too.
I'm sure APC is running out of memory, but it isn't like we can set APC to have unlimited memory. In a hosting environment some people will always have so much PHP that APC won't have enough memory.
Having it spit out 2Kbps of error log of the same thing over & over doesn't help.

Honestly, APC really isn't appropriate for shared hosts like
that. If you can't limit the scope of what is cached either
by running it in a limited environment where you know it
will all fit, or but liberal use of apc.filter to only let
some scripts be cached, you are constantly going to run out
of memory and since APC wipes the entire cache each time
that happens you will probably end up hurting performance
using APC. Running out of memory is an exceptional
circumstance for APC. If it happens regularly you need to
address that and make it not happen somehow.

[2010-03-05 04:49 UTC] hanno at hboeck dot de

Please read my original report. This is ONLY happening with apc 3.1 in combination with php 5.2. It's NOT happening with apc 3.0 (so it's a regression) and NOT happening with php 5.3.
So it's very likely not a general problem but very specific to versions.

[2010-03-21 05:44 UTC] fsjsdfjk at dfjkdf dot com

Happens on this server as well. PHP 5.2.13, not running out of system memory. Not a shared host -- only a single domain.

[2010-05-25 09:57 UTC] oli at thepcspy dot com

Any progress on this? I'm racking up a php-fpm logfile of about 3gigs a month of almost exclusively APC memory issues.
I have free memory on the server, is there a method to make this apc-warning go away?

[2010-06-29 11:10 UTC] simon dot finne at loopon dot se

Any progress on this one? I'm seeing it all the time on PHP
5.3.2 and APC 3.1.3p1.
This on a server with many gigs of free/unused memory, and
I've tried increasing apc.shm_size *a lot* from what
previously worked ok.
At the moment I have it at 2GB, and even after restarting
apache the first load of a new .php page triggers the problem.

If it happens on the first attempt to use the memory, then
it sounds like a configuration/environment issue. Nobody
else has reported anything like this and it runs in
production on literally millions of servers. So, spend an
intimate afternoon with gdb and try to figure out what might
be causing it. Things to look for:
- SElinux issues
- Weird chroot issues with a file-backed shmem segment
- Other systemwide things that affect access to shared
resources

[2010-07-03 15:36 UTC] stephen at itwebexperts dot com

Possibly the reason people don't report is they don't look at their logs? i not have an error log with over 1 million reports of this error in less than 3 days, of course i have multiple sites hosted.
i'm running php 5.3.2 and apc 3.0 RC

[2010-07-10 01:25 UTC] lincoln at icrontic dot com

Same issue
PHP 5.3.2 and APC 3.1.3p1
Dedicated server for high-traffic website; Apache/2.2.3 (CentOS)
Also running Wordpress (effects Wordpress and most other PHP scripts as well it seems).
Racking up nearly a GB/day in the error log with this.

[2010-07-15 03:19 UTC] skolesnyk at gmail dot com

I've had the same problem on the following config:
nginx 0.8.38, php-fpm for php 5.2.13, APC 3.1.3p1.
After downgrading APC to 3.1.2 the problem is gone, php scripts are executed in a stable manner.
Cheers!

[2010-08-06 11:26 UTC] craigb at symbian dot org

Noticed the same problem with PHP 5.3.2 and APC 3.1.3p1.
However, after raising the memory cache size to 60M (from the
default of 30M) the bug seems to go away, and we go back to
your regularly scheduled cache invalidation upon hitting the
memory cap.

I have never seen this happen on any server I have set up.
Could someone who can replicate this please do some debugging
and figure out which apc_pool_create() call is causing this.
One way would be to change each of the apc_wprint() warning
messages so you can identify which one is being problematic.

[2010-08-17 06:30 UTC] info at webtim dot biz

I have same problem after upgrade to 3.1.4 APC, PHP is 5.3.3

[2010-08-17 08:24 UTC] bantam at banime dot com

For me this problem was caused when my apc.shm_size was set
too low, I use redis for most key/value caching and apc for
only opcode caching so my apc.shm_size was set low, after I
started using apc value caching for local caching I got this
error, after tripling my apc.shm_size it went away.

[2010-08-26 03:16 UTC] bantam at banime dot com

I was a bit premature with my previous comment, the issues
returned after sufficient time. Well I waited for a while
before posting again so I could be sure. I figured out that
disabling mmap during APC configure with --disable-apc-mmap
did the trick. I don't know why it was not working correctly
with mmap but I am glad the problem was solved for me! Using
php 5.3.3 with FPM on Centos 5.5

For the people having this problem, please specify you .ini
settings. Specifically your apc.mmap_file_mask setting.
For file-backed mmap, it should be set to something like:
apc.mmap_file_mask=/tmp/apc.XXXXXX
To mmap directly from /dev/zero, use:
apc.mmap_file_mask=/dev/zero
For POSIX-compliant shared-memory-backed mmap, use:
apc.mmap_file_mask=/apc.shm.XXXXXX

[2010-08-30 21:35 UTC] ilia at prohost dot org

This bug has been fixed in SVN.
In case this was a documentation problem, the fix will show up at the
end of next Sunday (CET) on pecl.php.net.
In case this was a pecl.php.net website problem, the change will show
up on the website in short time.
Thank you for the report, and for helping us make PECL better.

Like I asked, please specify your apc.mmap_file_mask setting
if you are seeing this. It really should be fixed in trunk.

[2010-10-10 13:29 UTC] glen dot davis at gmail dot com

I have been seeing this same problem since upgrading to apc
3.1.4. I'm running PHP 5.3.3 on Fedora Core 12.
It happens both with apc.mmap_file_mask=/tmp/apc.XXXXXX (what
I keep it set as) and with apc.mmap_file_mask=/apc.shm.XXXXXX
(which I experimented with just to see what would happen when
I saw you were asking questions about the setting).
It happens as soon as the APC shared memory usage reaches
100%.

[2010-10-12 04:14 UTC] hanwoody at gmail dot com

to:rasmus at php dot net
I've disable mmap when configuring apc

[2010-10-12 04:19 UTC] hanwoody at gmail dot com

when apc memory reached full, always reproduce this bug.
I think apc wont swapout "oldest" data in cache,so it throw
out this warning,just not friendly.

[2010-10-17 22:54 UTC] zzzouch at yahoo dot com

All web pages across all domains displayed "Unable to allocate memory for pool." with php 5.2.14 and apc version 3.1.4. After downgrading to apc 3.0.19 the warnings stopped displaying.
On gentoo you can do the following to work around the apc 3.1.4 bug:
emerge =dev-php5/pecl-apc-3.0.19
/etc/init.d/apache restart

Hi,
I installed a new Ubuntu Server 10.04, with php5, php-apc (3.1.3p1-2 | http://packages.ubuntu.com/de/source/maverick/php-apc) and wordpress with no custom config (cause my tests with ab from apache works fine). After a few days my log-partition grew.... and I found this page, cause my logs were full of "Unable to allocate memory for pool."...

Ah! From the comments I got the impression that "trunk" was
already released (as 3.1.4). But I'll check it out.
As an intermediate fix I upped my cache to "70M".
I shall try trunk and report back.
Thanks!

Happens with 5.3.4 with apc built into php core. It isn't a
free memory issue. The server in question currently reports 24
gigs free. Happens only with latest mediawiki. Does not happen
with older mediawiki installs, other PHP based apps.

Is there truly NO apc option that will prevent this message from outputting to the screen? Turning off PHP display errors did little to remedy this issue for me, and tweaking various apc settings only delayed the problem instead of solving it.

[2011-02-03 10:09 UTC] alan dot g dot dixon at gmail dot com

I had this issue when upgrading a debian lenny apc from
3.0.x to 3.1.6. (Apache 2.2, php 5.2)
I think there were two issues related to the apc.ini file
that had been installed previously (perhaps by php-apc
package?). I upgraded a centos5 install at the same time and
didn't have any issues [and it had an empty apc.ini config]
1. apc.include_once_override=1
No one else has reported this one, but it was causing some
files to be included twice.
2. apc.mmap_file_mask=/tmp/apc.XXXXX
I think this is actually the problem, judging from Rasmus's
requests and the fact that there's now a new default of
/dev/zero
Conclusion: try cleaning out your apc.ini file and using the
apc defaults, it worked (so far) for me.

[2011-02-08 04:24 UTC] www at web-assembler dot com

Hi,
how do I downgrade to an earlier version of APC using a
debian on my VPS?
Please try to give me the exact lines for debian, I only
have these on gentoo: emerge =dev-php5/pecl-apc-3.0.19
/etc/init.d/apache restart
but thats not workingfor debian. :-)
Please help out.
Andre

[2011-02-12 17:17 UTC] info at donationcoder dot com

We solved this problem by allocated a much larger cache size, and the error never came back, even after the larger cache filled up.
Perhaps that means that the warning occurs when fragmentation or block sizes confuse apc into not being able to find a large enough free block, i'm not sure.

[2011-02-14 15:47 UTC] dev at c33s dot net

solution for me:
apc.ttl=0
apc.shm_size=anything you want
had the same issue on centos 5 with php 5.2.17 and noticed that if the cache size is small and the ttl parameter is "high" (like 7200) while having a lot of php files to cache, then the cache fills up quite fast and apc doesn't find anything which it can remove because all files in the cache still fit in the ttl.
increasing the memory size is only a part solution, you still run in this error if you cache fills up and all files are within the ttl.
so my solution was to set the ttl to 0, so apc fills up the cache an there is allways the possibility for apc to clear some memory for new data.
hope that helps

I think same as info at donationcoder dot com
I have latest APC 3.1.6 from Gentoo and PHP 5.3.5.
This bug is reproduced for me only when cache is almost full and badly fragmented. It this case APC can't allocate large enough block for caching a new file.
It would be great to perform defragmentation or empty stale items on this stage.

APC is all about speeding up execution. Defragmenting is super
slow. If you are hitting this condition often you either need
to increase the cache size or cache less stuff. Defragmenting
the cache is much slower than serving up the script uncached.
Basically what we need is to fix the warning mechanism so that
you know this is happening to allow you to tune the cache size
without spewing a million of them.

[2011-03-15 04:10 UTC] vanya at myfastmail dot com

But this is a stalemate situation actually - when you have fragmented almost full cache - nothing is cached anymore and stale items are not released. They will be only released when big enough file is requested or lot of small files requested.
I think that in this situation APC should at least start the same logic as in case of full cache.
You are not able to increase the size of cache all the time. And sometimes it's ok to loose files not used frequently from cache. Even an option in config would suffice.

[2011-03-31 12:48 UTC] bstillman at gmail dot com

For what it's worth, I found this page searching for the same problem. Changing apc.mmap_file_mask=/tmp/apc.XXXXX to apc.mmap_file_mask=/dev/zero resolved the problem as far as I can tell. It's the only change I've made, and the problem doesn't seem to be coming back. I'll post back if it does come back.

[2011-04-01 17:05 UTC] vbirchfield at comcast dot net

Using apc.mmap_file_mask=/dev/zero worked for me (so far) as well. Thank you, bstillman.

[2011-04-15 06:02 UTC] spam at wtools dot eu

This problem is happening to me using PHP 5.3.6 APC 3.1.7
apc.shm_size = 64M
apc.ttl = 7200
apc.user_ttl = 3600
I think APC should silently cache the scripts. This warning is
at no use for the PHP developer, it should be hidden.

[2011-04-28 17:48 UTC] al_dantas at hotmail dot com

I have PHP 5.3.3 and APC 3.1.7 in a high traffic web environment and we I am getting the same warnings.
I tried Changing apc.mmap_file_mask=/tmp/apc.XXXXX to apc.mmap_file_mask=/dev/zero and for some reason my NGINX page requests per second and Apache page requests per second doubled.
I my case I preferred keep the warnings until I find a better solution.

[2011-05-18 16:35 UTC] jsadwith at gmail dot com

Same issue here. All of our sites just randomly went down due to this. Running APC 3.1.6 with PHP 5.3.5. Still no solution?

[2011-05-28 17:46 UTC] contact at stellablue dot org

Still happens Apache 2.2.18, PHP 3.1.9
apc.mmap_file_mask set

[2011-06-07 17:31 UTC] royanee at yahoo dot com

This was happening for me on PHP 5.3.6 and APC 3.1.7 on Debian.
I switched from not setting the apc.mm_file_mask to the recommended value: apc.mmap_file_mask=/dev/zero
It works now. The easiest way to test it was to load up few large web applications and cycle through the tabs. Trivial to trigger before the change, unable to trigger after.

[2011-06-12 12:30 UTC] rune at smistad dot com

Still having this problem, and all sites unresponsive every
time the cache is full :(
Centos 5.6
Apache 2.2.3
APC 3.1.9
PHP 5.1.6
Could it be that the PHP is too old?

[2011-06-14 15:55 UTC] php at danielholm dot se

I just got tons of error messages based on 'Warning: require_once(): Unable to allocate memory for pool' all over my Drupal sites.
Added 'apc.mmap_file_mask=/dev/zero' to php.ini and now there gone. Thank you!
Ubuntu Server 10.04 LTS

[2011-06-14 16:01 UTC] pierre dot php at gmail dot com

This bug has been fixed in latest releases. Please try using
3.1.7+, best is 3.1.9.

[2011-07-16 12:56 UTC] contact at stellablue dot org

As I posted three or four comments above, I am running 3.1.9 and it is still there.

We seem to have run into the same problem on one server. Running php 5.3.4 with apc 3.1.9. Unfortunately it only seems to occur after quite some time running with a cache (maybe a day or more) so I don't have an easy testcase to reproduce it directly after apache-restarts.

Another reason for that error is if apc_bin_* functions are used in apache.
Ideally, they're only good for command line apps - because the apc_bin_load() allocations qualify as memory leaks in shared memory, because the entire cache entry set is tied to a single allocation - so even an apc cache clear won't free up memory.
That's the only scenario where we probably would spam the log with such warnings consistently - any other scenario will only log it till the cache clears.

[2011-10-14 11:30 UTC] xantek dot imc at gmail dot com

Had this issue with:
APC Version 3.1.9
PHP Version 5.2.17
I found viewing apc.php helpful to visualize config and cache information. It
seems this issue is related to configuration and not a software bug. I tweaked
the following setting based on details found in this thread,
http://www.php.net/manual/en/apc.configuration.php, and usage details in
apc.php.
apc.mmap_file_mask=/dev/zero
apc.shm_size=64M
apc.ttl=0

[2011-10-17 12:07 UTC] FractalizeR at yandex dot ru

I've had this problem on PHP 5.3.8 and APC 3.1.9. Fixed it like xantek proposed.

[2011-12-07 09:23 UTC] borsik at active dot sk

Fixed using these values on FreeBSD 8.2-RELEASE-p4, Apache/2.2.21, PHP 5.3.8:
apc.enabled=1
apc.mmap_file_mask=/dev/zero
apc.shm_size=128M
apc.ttl=0
apc.user_ttl=7200
apc.enable_cli=1
Seems to be problem if any value than zero is set to "apc.ttl" variable due to that cache content can not be replaced with new content.

I also encountered this bug with the following configuration :
PHP Version 5.2.6-1
APC Version 3.1.9
apc.cache_by_default On
apc.canonicalize On
apc.coredump_unmap Off
apc.enable_cli Off
apc.enabled On
apc.file_md5 Off
apc.file_update_protection 2
apc.filters no value
apc.gc_ttl 60
apc.include_once_override Off
apc.lazy_classes Off
apc.lazy_functions Off
apc.max_file_size 1M
apc.mmap_file_mask no value
apc.num_files_hint 1000
apc.preload_path no value
apc.report_autofilter Off
apc.rfc1867 On
apc.rfc1867_freq 0
apc.rfc1867_name APC_UPLOAD_PROGRESS
apc.rfc1867_prefix upload_ upload_
apc.rfc1867_ttl 3600
apc.serializer default
apc.shm_segments 1
apc.shm_size 256M
apc.slam_defense On
apc.stat On
apc.stat_ctime Off
apc.ttl 120
apc.use_request_time On
apc.user_entries_hint 4096
apc.user_ttl 120
apc.write_lock On

[2013-01-09 11:52 UTC] hanno at hboeck dot de

I've re-diffed the patch posted by ilia cheishvili in the comments above against
the latest apc version - and would like to note that this issue is still unfixed
and the fix has been posted here long ago ([2011-01-22 20:30 UTC] ilia dot
cheishvili at gmail dot com)

[2013-02-18 00:35 UTC] pecl-dev at lists dot php dot net

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.

[2013-02-18 08:15 UTC] hanno at hboeck dot de

I'm unable to change the bug state, but I want to ask to re-open it.
I don't know what feedback you need, it's pretty clear that the issue still
exists and a fix is available.

Afair it is fixed in the latest releases, please try it.
Also updating to 5.3 or 5.4 would be really a good thing, 5.2 is not maintained
anymore, since long.

[2013-02-18 08:33 UTC] hanno at hboeck dot de

@pajoye@php.net:
It is not fixed with apc 3.1.13 or 3.1.14 and it appears on current php 5.3/5.4
versions as well. I'm not using php 5.2 anymore since ages, this was only the
version I used when I first encountered this bug.
If you read the comments, various other people have statet before they've seen it
with php 5.3.

[2013-03-02 01:08 UTC] bosnjakante at gmail dot com

Well its now 2013, 4 years later and this problem persists. I ran into this problem for the first time in 10yrs of working with php and apache. This occured on my test server with 4gigs ram. I used top, htop and other tools during this error and all report that i have at least one gig of free memory. There must be some kind of configuration error somewhere. Either that or im running some seriously badly coded php app.
To find out systems cache settings via terminal type: sysctl -a | grep -E "shmall|shmmax"
I got kernel.shmall = 2097152 and kernel.shmmax = 33554432
not knowing what to do, i just herp and derp increased all of my mem and cache settings in both http.conf and set my prefork to lowest possible values. ....now im playing around with SELinux to block some apache modules because i had them all unblocked under SELinux. I never ran into this problem before. I just edited my php.ini file and set output_buffering = Off . This seems to fix the problem for now.

[2013-03-02 01:38 UTC] bosnjakante at gmail dot com

Hello, i am back. I just tested another version of the same php CMS on the same server with the same php and http config and i am having no problems. I am now close to certain the issue resides in bad php code. My issue is confined to a custom packaged version of drupal 7 with a theme.

[2013-03-02 02:21 UTC] bosnjakante at gmail dot com

Nevermind my previous comment. My other test cms sites also do not work haveing the same issue. Tried a clean install of latest barebones drupal and same issue.

[2013-03-02 03:33 UTC] bosnjakante at gmail dot com

I logged onto my other slimmed down shell, xfce, for debugging those catching errors and the unusually website access errors or lockups. All the CMS systems that i am running are miraculously fixed whenever the apache server is restarted. I guess the APC catch(s) are not being flushed correctly
Anyhow I removed everything on my system that has anything to do with APC;
apcupsd-cgi.x86_64 : Web interface for apcupsd
apcupsd-gui.x86_64 : GUI interface for apcupsd
php-ZendFramework-Cache-Backend-Apc.noarch : Zend Framework APC cache backend
php-pecl-apc.i686 : APC caches and optimizes PHP intermediate code
php-pecl-apc.x86_64 : APC caches and optimizes PHP intermediate code
php-pecl-apc-devel.i686 : APC developer files
php-pecl-apc-devel.x86_64 : APC developer files
Now everything is working great and 100x faster!
I think APC got installed on my test system automatically when i was updating my linux distro. In conclusion APC has given me a lot of grief. It has wasted an entire days worth of my time.

in my case, i just go to /etc/php.d/apc.ini, and set:
apc_enabled=0
this fixed my problem

[2013-10-02 12:18 UTC] benoit dot montuelle at gmail dot com

We got the same issue here on our brand new servers running php 5.3.3 on CentOS 6.3
The root cause seems to be the ttl of cached items which cannot be overriden even when the cache is full.
On centOS the default value is tt=7200 and we ran into trouble as soon as cache was filled.
We put ttl=0 (as we used to do on previous ubuntu servers) and problem disapperaed. The cached files are kept forever but if cache becomes full (although we provision it with enough shm_size) apc could clear some ones to write the new ones.
see answers on http://stackoverflow.com/questions/3723316/what-is-causing-unable-to-allocate-memory-for-pool-in-php for more details, everybody seems to agree on the observed behavior
I think it once was a bug, by today I would say its a behavior, but the documentation and error message could be more specific for this issue.
Best regards,
Benoit

[2013-10-15 11:54 UTC] pecl-dev at lists dot php dot net

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.

[2015-12-11 08:30 UTC] maggus dot staab at googlemail dot com

we experienced the same issue today in the following setup:
APC Version 3.1.13
PHP Version 5.4.45-2+deb.sury.org~precise+2
either the fix is not distributed in ubuntu distros or the mentioned fix of rasmus didnt fix the cause.