We're running PHP 5.3.8 with APC 3.1.9 and are using opcode cache as well as the user cache. Currently we are experiencing regular crashes when cache size increases. It looks like some kind of memory leak in APC, because the values in Cached Files en Cached Variables in size don't add up to the total cache size. The total cache size is much larger, like 1GB while the values added up make something like 400MB.
This is what the message log states:
Dec 19 10:17:54 quarto kernel: pid 97940 (httpd), uid 1004: exited on signal 11 (core dumped)
So I inspected the coredump with gdb:
(gdb) backtrace
#0 0x000000080202cc3c in zend_hash_index_find (ht=0x805251ef0, h=34490315800, pData=0x7fffffffc378) at /usr/local/directadmin/custombuild/php-5.3.8/Zend/zend_hash.c:983
#1 0x0000000805132637 in my_copy_zval () from /usr/local/lib/php/extensions/no-debug-non-zts-20090626/apc.so
#2 0x00000008051322fb in my_copy_zval_ptr () from /usr/local/lib/php/extensions/no-debug-non-zts-20090626/apc.so
#3 0x0000000805133aea in my_copy_hashtable_ex () from /usr/local/lib/php/extensions/no-debug-non-zts-20090626/apc.so
The line number (983) in zend_hash.c corresponds to an action (p = ht->arBuckets[nIndex];) where it addresses a key in a hashtable which apparently does not exist any more. This more or less supports my theory of a memory leak somewhere, where the apc cache fills up with illegal information…
Anyone got a clue?
Best Answer
After switching every apc_store call with apc_add the problem with 'zombie' memory disappeared. Probably has something to do with a race condition with apc_fetch and apc_store as discussed on http://notmysock.org/blog/php/user-cache-timebomb.html.
It's advised to use apc_add instead, especially these calls are user generated.