PHP+APC "Unable to allocate memory for pool." error

[Ben Alcala]

Latest RHEL 5.5 x86_64 PHP 5.2.16-1 and APC 3.1.6-2 RPMs are hitting this bug:

http://pecl.php.net/bugs/bug.php?id=16966

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

Triggered by Magento Community Edition and AMFphp Flash shopping cart.

[Jeffrey Ness (jeffrey-ness)]

After much investigation I have found the cause of this APC behavior.

The cause of this behavior is related to how we have APC configured within the /etc/php.d/apc.ini:

    ; Enable apc extension module
    extension = apc.so
    ; Options for the apc module
    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

Above you will see apc.ttl is set to 7200 seconds, or 2 hours. APC's documentation says this
setting is related to each cache objects 'time to live', and when it 'can' be removed to make room for new objects:

    http://www.php.net/manual/en/apc.configuration.php#ini.apc.ttl

    The number of seconds a cache entry is allowed to idle in a slot in case this cache entry slot is needed by another entry.
    Leaving this at zero means that APC's cache could potentially fill up with stale entries while newer entries won't be cached.
    In the event of a cache running out of available memory, the cache will be completely expunged if ttl is equal to 0. Otherwise,
    if the ttl is greater than 0, APC will attempt to remove expired entries.

In all cases the server reached there apc.shm_size (set at 32M by default) long before any object hit its apc.ttl.

What this meant was APC could not remove any object to make room for new objects, and thus a APC Warning was displayed:

    Warning: require_once() [function.require-once]: Unable to allocate memory for pool. in require_once()

In most cases APC was able to handle this by stepping aside and letting the PHP page be ran normally, however some cases
this would render a page unavailable, or splattered with PHP Warnings (I noticed Drupal and Magneto as the latter).

* Now for why we did not noticed this behavior in 3.0.19:

  In version 3.0.19 APC did not perform a 'Allocation' check, this is new behavior in the 3.1.x branch. In previous version
  APC would hit its max apc.shm_size and not cache anything further until apc.ttl was hit, and more room was made.

* The Solution:

  APC has a set of 'default' settings for everything we have been explicitly settings, this can be seen at the URL below:

      http://www.php.net/manual/en/apc.configuration.php

  You will notice apc.ttl (the cause of our issues) is defaulted to 0, what this means is:

       "In the event of a cache running out of available memory, the cache will be completely expunged if ttl is equal to 0"

 After settings apc.ttl to 0 (or letting it default) you will need to be aware of the apc.shm_size, for most users 32M
 will be plenty. However for the users that fill 32M quickly it may be come inefficient for APC to continue caching and
 clearing every couple seconds/minutes, in these cases apc.shm_size will need to be raised to an amount reasonable
 for that servers workload and configuration.

 What I would like to do is create a generic apc.ini with all settings commented out (allowing the Default to take effect),
 then 'if' any settings needs modified the user can edit the apc.ini by uncommenting the line they need.

[Jeffrey Ness (jeffrey-ness)]

This change has been pushed to IUS Testing for php52-pecl-apc and php53u-pecl-apc:

    http://bazaar.launchpad.net/~ius-coredev/ius/php52-pecl-apc/revision/18

[Jeffrey Ness (jeffrey-ness)]

Once this package has synced across the mirrors you can install the package using the command below:

 = php52 =

     yum install php52-pecl-apc --enablerepo=ius-testing

 = or for php53u =

     yum install php53u-pecl-apc --enablerepo=ius-testing

[Jeffrey Ness (jeffrey-ness)]

This release has been pushed to IUS Stable