I wanted to document this for others who might use the APC backend and encounter strange apache lockups, crashes as I did. If you have a very large cache, such that clearing it may exceed the max. execution time for a PHP script, you could be left with a lot of apache workers hanging around and an unresponsive server. The only apparent solution is to run APC version 3.1 or higher.

There are more details at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572529
http://t3.dotgnu.info/blog/php/user-cache-timebomb.html

Comments

andypost’s picture

andypost
he/him
Primary language Russian
commented
Category: support » task

Suppose this should be pointed at readme.txt

andypost’s picture

andypost
he/him
Primary language Russian
commented

Marked as duplicate #802300: memcached lock not freed

miro_dietiker’s picture

miro_dietiker
Location Switzerland
commented

Note that we still have instability in latest APC after a certain runtime.
Seems like this is related to some fragmentation issues, since loading time is first lightning fast and later becomes slower till apache is completely locked.

In that lock state apache still responses for plain non-php files. As soon as we try to request a php file that e.g. tries to access apc (e.g. apc.php) the process locks. This results in forking many many processes (apache and mysql) and finally having a "mysql: too many connections" situation in drupal.. In meantime there will also be a locking time where no answer will be provided till that final result.

We finally decided to switch away from APC as user key/value cache. APC as php opcode cache is great and works stable.