ius-coredev team mailing list archive

[Jeffrey Ness <696742@xxxxxxxxxxxxxxxxxx>]

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.


** Changed in: ius
     Assignee: (unassigned) => Jeffrey Ness (jeffrey-ness)

-- 
You received this bug notification because you are a member of IUS Core
Development, which is subscribed to IUS Community Project.
https://bugs.launchpad.net/bugs/696742

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

Status in IUS Community Project:
  New

Bug description:
  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.