APC不斷崩潰

我們使用 APC 3.1.9 執行 PHP 5.3.8，並使用操作碼記憶體和使用者記憶體。目前，當記憶體大小增加時，我們經常遇到崩潰。它看起來像是 APC 中的某種記憶體洩漏，因為 Cached Files en Cached Variables 中的大小值加起來不等於總記憶體大小。總記憶體大小要大得多，比如 1GB，而加起來的值大約是 400MB。

這是消息日誌的狀態：

Dec 19 10:17:54 quarto kernel: pid 97940 (httpd), uid 1004: exited on signal 11 (core dumped)

所以我用 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 $$;) 它在雜湊表中處理一個顯然不再存在的鍵。這或多或少地支持了我關於某處記憶體洩漏的理論，其中 apc 記憶體充滿了非法資訊…… 有人有線索嗎？

在使用 apc_add 切換每個 apc_store 呼叫後，“殭屍”記憶體的問題就消失了。可能與http://notmysock.org/blog/php/user-cache-timebomb.html上討論的 apc_fetch 和 apc_store 的競爭條件有關。

建議改用 apc_add，尤其是這些呼叫是使用者生成的。

我們在這裡看到了與隨機記憶體洩漏相同的問題，在這種情況下，根據您提供的資訊，我會提出一個錯誤，然後您可以選擇等待修復、自己修復程式碼或解決它。

另請注意，我只看到使用 USER 記憶體而不是操作碼會發生這種情況，我在這里通過使用 memcache 來抵消這一點（如果使用 Zend 框架，對應用程序的更改相當容易）。

引用自：https://serverfault.com/questions/342295