我们使用APC 3.1.9运行PHP 5.3.8，并使用操作码caching以及用户caching。 目前，当caching大小增加时，我们正在经历崩溃。 它看起来像APC中的某种内存泄漏，因为caching文件中cachingvariables大小的值不会累加到总caching大小。 总caching大小要大得多，比如1GB，而加起来的值就是400MB。
这是消息日志的状态：
Dec 19 10:17:54 quarto kernel：pid 97940（httpd），uid 1004：退出信号11（核心转储）
所以我用gdb检查了coredump：
(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 zend_hash.c中的行号（983）对应于一个动作（p = ht-> arBuckets [nIndex];），它在一个散列表中寻址一个显然不再存在的键。 这或多或less地支持我的内存泄漏理论，在apccaching填满非法信息的地方…
任何人都有线索？
在用apc_add切换每个apc_store调用之后，“僵尸”内存的问题消失了。 可能与apc_fetch和apc_store中的竞态条件有关，如http://notmysock.org/blog/php/user-cache-timebomb.html所述 。
build议使用apc_add，尤其是这些调用是用户生成的。
我们在这里看到了与随机内存泄漏相同的问题，在这种情况下，您提供的信息会引发一个错误，并且您可以select等待修复，自行修复代码或解决此问题。
另外要注意，我只看到这发生与使用USERcaching，而不是操作码，我已经抵消了这里通过使用memcache，而不是（如果使用Zend框架更改到应用程序是相当容易的）。