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

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.

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.

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.

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

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?

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

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

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.

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!

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.

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

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.

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

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.

We still reproduce this warning after upgrading from trunk 
code.
apache:2.2.15
php:5.3.0
apc:trunk in 20100927

apc configure:
./configure --with-php-config=/usr/local/bin/php-config --
disable-apc-mmap

----------------------------------------------------
extension="apc.so"

[apc]
apc.enabled="1"
apc.shm_size="256"
apc.stat="1"
apc.file_update_protection="2"
apc.ttl="3600"
apc.user_ttl="1200"
apc.gc_ttl="3600"
apc.num_files_hint="40000"
apc.rfc1867="1"
apc.lazy_functions=1
apc.lazy_classes=1

anyone can help ?

We are seeing this problem on APC 3.1.4 with 1024MB of SHM.
very frustrating, any fixes yet?

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

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

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

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.

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

APC 3.1.4
PHP 5.3.3 [php-fpm]
Ubuntu 9.10

apc.mmap_file_mask=[empty]

I have ~30 MB allocated to APC.

I see the error only on servers where the 30 MB are almost 
all used.

Try the current trunk.  This was fixed a while ago and the fix 
will be in 3.1.5 which is coming soon.

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!

APC 3.1.5
PHP 5.2.5
CentOS 5.3

Problem still exist

[09-Nov-2010 11:31:47] PHP Warning: Smarty::include() [<a 
href='function.Smarty-include'>function.Smarty-include</a>]: 
Unable to allocate memory for pool. in 
/path/to/Smarty/Smarty.class.php on line 1263
[09-Nov-2010 11:31:48] PHP Warning: Smarty::include() [<a 
href='function.Smarty-include'>function.Smarty-include</a>]: 
Unable to allocate memory for pool. in 
/path/to/Smarty/Smarty.class.php on line 1263
[09-Nov-2010 11:31:49] PHP Warning: Smarty::include() [<a 
href='function.Smarty-include'>function.Smarty-include</a>]: 
Unable to allocate memory for pool. in 
/path/to/Smarty/Smarty.class.php on line 1263
[09-Nov-2010 11:31:49] PHP Warning: Smarty::include() [<a 
href='function.Smarty-include'>function.Smarty-include</a>]: 
Unable to allocate memory for pool. in 
/path/to/Smarty/Smarty.class.php on line 1263
[09-Nov-2010 11:31:49] PHP Warning: Smarty::include() [<a 
href='function.Smarty-include'>function.Smarty-include</a>]: 
Unable to allocate memory for pool. in 
/path/to/Smarty/Smarty.class.php on line 1263

config:
#v+
extension = apc.so
apc.enabled=1
apc.report_autofilter=0
apc.shm_segments=1
apc.optimization=0
apc.shm_size=64M
apc.ttl=7200
apc.user_ttl=7200
apc.num_files_hint=1024
apc.mmap_file_mask=/var/apc/apc.XXXXXX
apc.enable_cli=1
apc.cache_by_default=1
apc.include_once_override=0
apc.cache_static_contents=0
apc.rfc1867=1
apc.slam_defense=0
#v-

The problem isn't fixed on 3.1.6 , php 5.2.14, FreeBSD AMD64.

Having this issue as well. APC 3.1.6 PHP 5.3.4 FreeBSD 8.1 AMD64

APC Support => disabled
APC Debugging => Disabled
apc.cache_by_default => On => On
apc.canonicalize => On => On
apc.coredump_unmap => Off => Off
apc.enable_cli => Off => Off
apc.enabled => On => On
apc.file_md5 => Off => Off
apc.file_update_protection => 2 => 2
apc.filters => no value => no value
apc.gc_ttl => 3600 => 3600
apc.include_once_override => Off => Off
apc.lazy_classes => Off => Off
apc.lazy_functions => Off => Off
apc.max_file_size => 1M => 1M
apc.mmap_file_mask => no value => no value
apc.num_files_hint => 1000 => 1000
apc.preload_path => no value => no value
apc.report_autofilter => Off => Off
apc.rfc1867 => Off => Off
apc.rfc1867_freq => 0 => 0
apc.rfc1867_name => APC_UPLOAD_PROGRESS => APC_UPLOAD_PROGRESS
apc.rfc1867_prefix => upload_ => upload_
apc.rfc1867_ttl => 3600 => 3600
apc.shm_segments => 3 => 3
apc.shm_size => 90 => 90
apc.slam_defense => On => On
apc.stat => On => On
apc.stat_ctime => Off => Off
apc.ttl => 7200 => 7200
apc.use_request_time => On => On
apc.user_entries_hint => 4096 => 4096
apc.user_ttl => 7200 => 7200
apc.write_lock => On => On

Hello I have the same message.

PHP 5.2.16

Name       : php-pecl-apc
Arch       : x86_64
Version    : 3.1.6
Release    : 2.el5.art

This error start to appear after upgrade the apc.  The applications generates error 500.

Issue also exists with the latest IUS PHP 5.2 RPMs on RHEL 5.5 x86_64:

php52 ==> 5.2.16-1
php52-pecl-apc ==> 3.1.6-2

apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.shm_size=64M

Triggered by Magento Community Edition and AMFphp Flash shopping cart.

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.

Still happening with 3.1.7 release?

Yes? It still happens in 3.1.7 for me

I am receiving this error when using Drupal 6.20 with the following configuration:

* opensuse 11.3 x86_64 (2.6.34.7)
* apache 2.2.17
* php 5.3.5
* apc 3.1.6


apc.ini:

apc.enabled=1
apc.shm_segments=1
apc.shm_size=96M
apc.num_files_hint=1024
apc.user_entries_hint=4096
apc.ttl=7200
apc.use_request_time=1
apc.user_ttl=7200
apc.gc_ttl=3600
apc.cache_by_default=1
apc.filters
apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.file_update_protection=2
apc.enable_cli=0
apc.max_file_size=1M
apc.stat=1
apc.stat_ctime=0
apc.canonicalize=0
apc.write_lock=1
apc.report_autofilter=0
apc.rfc1867=0
apc.rfc1867_prefix =upload_
apc.rfc1867_name=APC_UPLOAD_PROGRESS
apc.rfc1867_freq=0
apc.rfc1867_ttl=3600
apc.include_once_override=0
apc.lazy_classes=0
apc.lazy_functions=0
apc.coredump_unmap=0
apc.file_md5=0
apc.preload_path

This issue, aside from filling up logs, is a headache when developing.  If, as a good developer, you have error reporting displaying everything, then this error will usually create output that is sent before the headers are, which pretty much "breaks" the response as a chain of errors proceed to occur.  Therefore, I developed a patch for APC 3.1.7 that I am forced to run with.  The patch makes it so that the errors are still written to PHP's standard error log, but don't clobber the HTTP response output.  Perhaps this will be useful to someone:

diff -u -r APC-3.1.7/apc_bin.c APC-3.1.7-patched/apc_bin.c
--- APC-3.1.7/apc_bin.c 2011-01-11 12:06:38.000000000 -0700
+++ APC-3.1.7-patched/apc_bin.c 2011-01-21 18:03:49.000000000 -0700
@@ -703,7 +703,7 @@
     apc_bd_alloc_ex(pool_ptr, sizeof(apc_pool) TSRMLS_CC);
     ctxt.pool = apc_pool_create(APC_UNPOOL, apc_bd_alloc, apc_bd_free, NULL, NULL TSRMLS_CC);  /* ideally the pool wouldn't be alloc'd as part of this */
     if (!ctxt.pool) { /* TODO need to cleanup */
-        apc_warning("Unable to allocate memory for pool." TSRMLS_CC);
+        php_log_err("Unable to allocate memory for pool." TSRMLS_CC);
         return NULL;
     }
     ctxt.copy = APC_COPY_IN_USER;  /* avoid stupid ALLOC_ZVAL calls here, hack */
@@ -854,7 +854,7 @@
     for(i = 0; i < bd->num_entries; i++) {
         ctxt.pool = apc_pool_create(APC_SMALL_POOL, apc_sma_malloc, apc_sma_free, apc_sma_protect, apc_sma_unprotect TSRMLS_CC);
         if (!ctxt.pool) { /* TODO need to cleanup previous pools */
-            apc_warning("Unable to allocate memory for pool." TSRMLS_CC);
+            php_log_err("Unable to allocate memory for pool." TSRMLS_CC);
             goto failure;
         }
         ep = &bd->entries[i];
diff -u -r APC-3.1.7/apc_main.c APC-3.1.7-patched/apc_main.c
--- APC-3.1.7/apc_main.c        2011-01-11 12:06:38.000000000 -0700
+++ APC-3.1.7-patched/apc_main.c        2011-01-21 18:03:35.000000000 -0700
@@ -414,7 +414,7 @@
     ctxt.pool = apc_pool_create(APC_MEDIUM_POOL, apc_sma_malloc, apc_sma_free, 
                                                  apc_sma_protect, apc_sma_unprotect TSRMLS_CC);
     if (!ctxt.pool) {
-        apc_warning("Unable to allocate memory for pool." TSRMLS_CC);
+        php_log_err("Unable to allocate memory for pool." TSRMLS_CC);
         return FAILURE;
     }
     ctxt.copy = APC_COPY_IN_OPCODE;
@@ -539,7 +539,7 @@
         ctxt.pool = apc_pool_create(APC_UNPOOL, apc_php_malloc, apc_php_free,
                                                 apc_sma_protect, apc_sma_unprotect TSRMLS_CC);
         if (!ctxt.pool) {
-            apc_warning("Unable to allocate memory for pool." TSRMLS_CC);
+            php_log_err("Unable to allocate memory for pool." TSRMLS_CC);
             return old_compile_file(h, type TSRMLS_CC);
         }
         ctxt.copy = APC_COPY_OUT_OPCODE;
diff -u -r APC-3.1.7/php_apc.c APC-3.1.7-patched/php_apc.c
--- APC-3.1.7/php_apc.c 2011-01-11 12:06:38.000000000 -0700
+++ APC-3.1.7-patched/php_apc.c 2011-01-21 18:03:09.000000000 -0700
@@ -578,7 +578,7 @@
 
     ctxt.pool = apc_pool_create(APC_SMALL_POOL, apc_sma_malloc, apc_sma_free, apc_sma_protect, apc_sma_unprotect TSRMLS_CC);
     if (!ctxt.pool) {
-        apc_warning("Unable to allocate memory for pool." TSRMLS_CC);
+        php_log_err("Unable to allocate memory for pool." TSRMLS_CC);
         return 0;
     }
     ctxt.copy = APC_COPY_IN_USER;
@@ -819,7 +819,7 @@
 
     ctxt.pool = apc_pool_create(APC_UNPOOL, apc_php_malloc, apc_php_free, NULL, NULL TSRMLS_CC);
     if (!ctxt.pool) {
-        apc_warning("Unable to allocate memory for pool." TSRMLS_CC);
+        php_log_err("Unable to allocate memory for pool." TSRMLS_CC);
         RETURN_FALSE;
     }
     ctxt.copy = APC_COPY_OUT_USER;

By the way, I have provided another patch that addresses a similar issue here: http://pecl.php.net/bugs/bug.php?id=16814

we are getting this as well.  still no fix?

This bug still appears to be relevant. we are running PHP 
5.3.5 with APC 3.1.7, I've tried apc versions 3.1.6 and 3.1.4 
all reporting the same.

I'm seeing this as well.

CentOS release 5.5 (Final)
Linux myhostname.com 2.6.18-194.17.4.el5xen #1 SMP Mon Oct 25 16:36:31 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

php52-5.2.17-1.ius.el5
php52-pecl-apc-3.1.6-2.ius.el5

apc.enabled=1
apc.shm_segments=1
apc.optimization=0
apc.shm_size=32M
apc.ttl=7200
apc.user_ttl=7200
apc.num_files_hint=1024
apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.enable_cli=1
apc.cache_by_default=1

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.

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.

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

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.

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

With my own APC 3.1.6 compilation I've found out that this error happens only in apc_compile_cache_entry() function call (file apc_main.c:414). PHP 5.3.5 as RPM (CentOS 5.5) got from IUS:
http://dl.iuscommunity.org/pub/ius/stable/Redhat/5/x86_64/repoview/php53u.html

apc.ini contents:
apc.enabled=1
apc.shm_segments=1
apc.optimization=0
apc.shm_size=32M
apc.ttl=7200
apc.user_ttl=7200
apc.num_files_hint=1024
apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.enable_cli=1
apc.cache_by_default=1

Not sure if this is related to code, but it's a symfony 1.4 + Doctrine 1.2 project.

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.

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.

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.

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

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.

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.

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?

Still happens Apache 2.2.18, PHP 3.1.9

apc.mmap_file_mask set

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.

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?

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

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

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

PHP/5.2.17
APC Version 3.1.9 

sometimes, it does not rotate.

Might as well add another data point:

PHP 5.3.6 (cli) (built: Mar 18 2011 14:54:34) 
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
[richard.lynch@lmsdev01 ~]$ php -i | grep -i apc
Additional .ini files parsed => /etc/php.d/apc.ini,
apc
APC Support => enabled
APC Debugging => Disabled
MMAP File Mask => /tmp/apc.S1YF0a
apc.cache_by_default => On => On
apc.canonicalize => On => On
apc.coredump_unmap => Off => Off
apc.enable_cli => On => On
apc.enabled => On => On
apc.file_md5 => Off => Off
apc.file_update_protection => 2 => 2
apc.filters => no value => no value
apc.gc_ttl => 3600 => 3600
apc.include_once_override => Off => Off
apc.lazy_classes => Off => Off
apc.lazy_functions => Off => Off
apc.max_file_size => 1M => 1M
apc.mmap_file_mask => /tmp/apc.S1YF0a => /tmp/apc.S1YF0a
apc.num_files_hint => 1024 => 1024
apc.preload_path => no value => no value
apc.report_autofilter => Off => Off
apc.rfc1867 => Off => Off
apc.rfc1867_freq => 0 => 0
apc.rfc1867_name => APC_UPLOAD_PROGRESS => APC_UPLOAD_PROGRESS
apc.rfc1867_prefix => upload_ => upload_
apc.rfc1867_ttl => 3600 => 3600
apc.shm_segments => 1 => 1
apc.shm_size => 32M => 32M
apc.slam_defense => On => On
apc.stat => On => On
apc.stat_ctime => Off => Off
apc.ttl => 7200 => 7200
apc.use_request_time => On => On
apc.user_entries_hint => 4096 => 4096
apc.user_ttl => 7200 => 7200
apc.write_lock => On => On

I can't install debug versions on this box, as it's puppet controlled by Ops.
I'll try to repo on a Desktop if they ever give me a RHEL entitlement I've been awaiting for a month...

Also, my app is Moodle, just in case that's relevant somehow.

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.

PHP 5.3.6 (cli) (built: Mar 19 2011 07:44:03)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend 
Technologies
    with eAccelerator v0.9.6.1, Copyright (c) 2004-2010 
eAccelerator, by eAccelerator
    with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick 
Rethans


APC 3.1.9

apc.enabled=1
apc.shm_segments=1
apc.shm_size=64M
apc.num_files_hint=1024
apc.user_entries_hint=4096
apc.ttl=7200
apc.use_request_time=1
apc.user_ttl=7200
apc.gc_ttl=3600
apc.cache_by_default=1
apc.filters
apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.file_update_protection=2
apc.enable_cli=0
apc.max_file_size=1M
apc.stat=1
apc.stat_ctime=0
apc.canonicalize=0
apc.write_lock=1
apc.report_autofilter=0
apc.rfc1867=1
apc.rfc1867_prefix =upload_
apc.rfc1867_name=APC_UPLOAD_PROGRESS
apc.rfc1867_freq=0
apc.rfc1867_ttl=3600
apc.include_once_override=0
apc.lazy_classes=00
apc.lazy_functions=0
apc.coredump_unmap=0
apc.file_md5=0
apc.preload_path

Kernel 2.6.21.7-2.fc8xen

Server with 5 virtualhosts and max 2 users per virtualhost 
at once, happens around half an hour after apache reload.

@ondrej Why are you running both eAccelerator and APC? That's 
not going to work.

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.

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

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

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.

We also encountered this issue on our servers. However, the issue is somewhat 
different. I think this is not really caused by that the apc memory is 100% 
used, it may be caused by that some out of boundary pointer operation flush the 
memory used by apc to zero. From apc.php we can find that "avail_mem" is zero 
and start_time is zero. This will cause memory usage to be 100% and the flowing 
funny output in apc.php:

Start Time	1970/01/01 07:00:00
Uptime	41 years, 49 weeks, 3 days, 12 hours and 5 minutes

Some important information about version numbers and configurations are 
attached:

=======

APC Version	3.1.9
PHP Version	5.2.10

Server Software	Apache/2.2.3 (CentOS)

apc.cache_by_default	1
apc.canonicalize	1
apc.coredump_unmap	0
apc.enable_cli	1
apc.enabled	1
apc.file_md5	0
apc.file_update_protection	2
apc.filters	
apc.gc_ttl	3600
apc.include_once_override	0
apc.lazy_classes	0
apc.lazy_functions	0
apc.max_file_size	1M
apc.mmap_file_mask	/tmp/apc.KlGiYe
apc.num_files_hint	1000
apc.preload_path	
apc.report_autofilter	0
apc.rfc1867	0
apc.rfc1867_freq	0
apc.rfc1867_name	APC_UPLOAD_PROGRESS
apc.rfc1867_prefix	upload_
apc.rfc1867_ttl	3600
apc.serializer	igbinary
apc.shm_segments	1
apc.shm_size	256M
apc.slam_defense	1
apc.stat	0
apc.stat_ctime	0
apc.ttl	7200
apc.use_request_time	1
apc.user_entries_hint	4096
apc.user_ttl	7200
apc.write_lock	1

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

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)

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.

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.

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

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.

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.

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.

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.

CentOS release 6.4 (Final)
17:26 [root@WebServer ~]# rpm -qic php-pecl-apc
Name        : php-pecl-apc                 Relocations: (not relocatable)
Version     : 3.1.9                             Vendor: CentOS
Release     : 2.el6                         Build Date: Fri 22 Jun 2012 17:47:04 WST
Install Date: Tue 10 Jul 2012 20:59:49 WST      Build Host: c6b10.bsys.dev.centos.org
Group       : Development/Languages         Source RPM: php-pecl-apc-3.1.9-2.el6.src.rpm
Size        : 326037                           License: PHP
Signature   : RSA/SHA1, Mon 25 Jun 2012 06:16:40 WST, Key ID 0946fca2c105b9de
Packager    : CentOS BuildSystem <http://bugs.centos.org>
URL         : http://pecl.php.net/package/APC
Summary     : APC caches and optimizes PHP intermediate code
Description :
APC is a free, open, and robust framework for caching and optimizing PHP
intermediate code.
/etc/php.d/apc.ini
17:26 [root@WebServer ~]# cat /etc/php.d/apc.ini | grep ^[a-z] | sort
apc.cache_by_default=1
apc.canonicalize=0
apc.coredump_unmap=0
apc.enable_cli=0
apc.enabled=1
apc.file_md5=0
apc.file_update_protection=2
apc.filters
apc.gc_ttl=3600
apc.include_once_override=0
apc.lazy_classes=0
apc.lazy_functions=0
apc.max_file_size=1M
apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.num_files_hint=1024
apc.preload_path
apc.report_autofilter=0
apc.rfc1867=0
apc.rfc1867_freq=0
apc.rfc1867_name=APC_UPLOAD_PROGRESS
apc.rfc1867_prefix =upload_
apc.rfc1867_ttl=3600
apc.shm_segments=1
apc.shm_size=64M
apc.stat=1
apc.stat_ctime=0
apc.ttl=7200
apc.user_entries_hint=4096
apc.use_request_time=1
apc.user_ttl=7200
apc.write_lock=1
extension = apc.so
17:27 [root@WebServer ~]# 

I'm removing apc. I don't know the consequences of the "sure-fire" fixes offered and I've wasted more time than this problem is worth.

I'm pretty unwilling to run non-standard versions of anything, if you fix this in the next 24 hours it's still going to be ages before it gets through RH and Centos to me.

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


this fixed my problem

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

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.

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.

We are also experiencing this issue.  I checked our apc.php output and was a bit confounded.

http://i.imgur.com/l2EuB2Y.jpg

(Chart indicates 100% usage; legend indicates 8.8% usage and 91.2% free)

Could someone explain why the numerical output is different from the chart in terms of memory usage?

Here is our apc.ini:

; Enable and Configure APC
extension=apc.so
apc.enabled=1
apc.ttl=1200
apc.user_ttl=1200
apc.gc_ttl=600
apc.shm_size=3072M
apc.stat=1
apc.file_update_protection=2
apc.max_file_size=3M
apc.num_files_hint=8192
apc.user_entries_hint=8192

This host is running RHEL6.8.