Using the current software versions from the portage tree, I am seeing the same error again. The workaround is, again, to set the apc.mmap_file_mask, but this is not expected. +++ This bug was initially created as a clone of Bug #338471 +++ When dev-lang/php-5.3.3-r1 and dev-php5/pecl-apc-3.1.4[-mmap] are installed and apc.mmap_file_mask is not explicitely set in the .ini-file, output of php scripts include "Unable to allocate memory for pool" warning message. Reproducible: Always Steps to Reproduce: 1. USE="-mmap" emerge -av "=dev-lang/php-5.3.3-r1" "=dev-php5/pecl-apc-3.1.4" 2. check, that /etc/php/apache2-php5/ext-active/apc.ini includes the line ";apc.mmap_file_mask="/tmp/apcphp5.XXXXXX" (commented out!) 3. run an php-skript with lots of "include_once" (e.g. drupal - update.php) Actual Results: Output includes "warning: require_once(): Unable to allocate memory for pool. in <FILENAME> on line <LINE NUMBER WITH require_once()" Expected Results: no warning. should not exluding "mmap" from being build into APC prevent any mmap-related errors from happening? What else is the USE flag for?
There was a regression in 3.1.8. Could you see if you get the same problem with 3.1.9?
(In reply to comment #1) > There was a regression in 3.1.8. Could you see if you get the same problem with > 3.1.9? Yes, I still see the same error, although less often (in 3.1.8 I would see the error maybe 20 times on a single call of the drupal update script, with 3.1.9 I see it 2-3 times...).
Since you are using apc with drupal it may be that your pool is actually filled. Remember that when you do not use mmap you usually only have 32k to store data in.
(In reply to comment #3) > Since you are using apc with drupal it may be that your pool is actually > filled. Remember that when you do not use mmap you usually only have 32k to > store data in. In case I am not using mmap, will apc then ignore the apc.shm_size and apc.localcache.size settings (those are "30M" and "2048" on my machine)? Where are the 32k specified?
(In reply to comment #4) > (In reply to comment #3) > > Since you are using apc with drupal it may be that your pool is actually > > filled. Remember that when you do not use mmap you usually only have 32k to > > store data in. > > In case I am not using mmap, will apc then ignore the apc.shm_size and > apc.localcache.size settings (those are "30M" and "2048" on my machine)? Where > are the 32k specified? They will not be ignored, but they will be constrained by kernel.shmmax, which is set to 33554432 by default.
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > Since you are using apc with drupal it may be that your pool is actually > > > filled. Remember that when you do not use mmap you usually only have 32k to > > > store data in. > > > > In case I am not using mmap, will apc then ignore the apc.shm_size and > > apc.localcache.size settings (those are "30M" and "2048" on my machine)? Where > > are the 32k specified? > > They will not be ignored, but they will be constrained by kernel.shmmax, which > is set to 33554432 by default. This value is, in my case, set to 0x7fffffff via /etc/sysctl.conf, which is shown as 2147483647 in /proc/sys/kernel/shmmax. It is still possible, that I hit this limit. So the question that probably needs to be asked, would be: Is the seen output as expected?
I have been using apc in production for a long time and never seen this issue, but then there is the referenced bug, which is still open. Difficult for me to say ...
i've seen this issue last week with redhat-linux. issue solved with set ttl = 0. do you have tried this?
(In reply to comment #8) > i've seen this issue last week with redhat-linux. issue solved with set ttl = > 0. > > do you have tried this? To remind you: I am still not able to reproduce the error with any code fragment, but after setting "apc.ttl=0" in apc.ini I have not seen the error so far. From my understanding, this configuration allows APC to remove any cached values at will - isn't this like a system with disabled APC?
No, it isn't. please have a look at the documentation: http://de2.php.net/manual/en/apc.configuration.php#ini.apc.ttl
Created attachment 273811 [details, diff] Patch changing the default settings for pecl-apc to avoid warnings Thank you for the link. So it seems, that the value of apc.ttl highly depends on the code to cache and traffic. Even for the case of raising the memory size to the possible maximum of your machine and setting ttl to 1, there is a possibility, that you will hit this warning occassionally. I think the safest setting would be to set the ttl to 0 (which is not disabling anything as Denny Reeh pointed out). If you want to improve the caching for your setup, you can increase it until you hit this warning. In the attached patch you will also see, that the mmap_file_mask is only set, if compiled with mmap support.
As I understand it, if you set ttl to 0, it will empty the entire cache when it is full, so the problem is still that the cache size is not large enough. Further, if you empty the pool every time your cache is full and this happens often, you will cause thrashing.
(In reply to comment #12) > As I understand it, if you set ttl to 0, it will empty the entire cache when it > is full, so the problem is still that the cache size is not large enough. > Further, if you empty the pool every time your cache is full and this happens > often, you will cause thrashing. Yes, that is my understanding, too. Since we dont know the needed cache size, we have basically two choices for the packaging process: Stay with the previous setting and get warnings for about 2hours for each php call that would normally be cached OR play it safe and empty the cache if it is full at the cost of performance. If you run an productive server, you will probably need to fine tune those settings anyway depending on your application you will run on it and your need for performance optimization. Otherwise setting ttl to 0 (and having a lower performance) should be the safer way.
The package will use the upstream defaults. I have not checked if we still follow those defaults, but I can recheck.
Created attachment 273821 [details, diff] Defaults according to INSTALL in APC-3.1.9.tgz You are right, the package should follow the upstream. I was just wondering, if a different setting would not make more sense. I just checked against the INSTALL file in http://pecl.php.net/get/APC-3.1.9.tgz as well as against http://php.net/manual/en/apc.configuration.php: Both use a ttl of 0 for default. The attached patch follows closely the INSTALL file with the addition of the "M" for shm_size and the addition of coredump_unmap.
Thanks for the patch. But I find it too painful to maintain ini files like that. I am looking into if it is trivial to just ship $FILESDIR/$PVR.ini instead.
Okay. Revbump added with more sane defaults. Reopen if I broke something.
