【案例】小心，apc可能导致php-fpm罢工！
视频汇总首页：http://edu.运维网.com/lecturer/index/user_id-4626073.html最近访问网站，发现出现了502错误。一般出现502错误，都是php-fpm 进程处理请求时出现异常导致的。
首先，查看了php-fpm 的进程数。发现php-fpm的进程数已经到达了php-fpm.conf中设置的最大值。最近流量没有大的变动，这么多php-fpm进程，肯定有问题。
然后，用pstack命令查看这些php-fpm进程都在干啥。
$ sudo pstack 11740Thread 3 (Thread 0x413bb940 (LWP 11741)):#00x0000003cf92d4018 in epoll_wait () from /lib64/libc.so.6#10x00007f4a0ffec116 in epoll_poll ()#20x00007f4a0ffea81d in ez_run () from /home/opt/easy/lib/libeasy.so.0#30x00007f4a0ffe5b63 in easy_io_on_thread_start ()#40x0000003cf9e064a7 in start_thread () from /lib64/libpthread.so.0#50x0000003cf92d3c2d in clone () from /lib64/libc.so.6Thread 2 (Thread 0x425a2940 (LWP 11742)):#00x0000003cf92d4018 in epoll_wait () from /lib64/libc.so.6#10x00007f4a0ffec116 in epoll_poll ()#20x00007f4a0ffea81d in ez_run () from /home/opt/easy/lib/libeasy.so.0#30x00007f4a0fff1772 in easy_baseth_on_start ()#40x0000003cf9e064a7 in start_thread () from /lib64/libpthread.so.0#50x0000003cf92d3c2d in clone () from /lib64/libc.so.6Thread 1 (Thread 0x7f4a17438710 (LWP 11740)):#00x0000003cf9e0d174 in __lll_lock_wait () from /lib64/libpthread.so.0#10x0000003cf9e08aca in _L_lock_1034 () from /lib64/libpthread.so.0#20x0000003cf9e0898c in pthread_mutex_lock () from /lib64/libpthread.so.0#30x00007f4a135eeb19 in apc_pthreadmutex_lock ()#40x00007f4a135e7fb8 in apc_cache_find_slot ()#50x00007f4a135e8323 in apc_cache_find ()#60x00007f4a135edd27 in my_compile_file ()#70x000000000050c651 in phar_compile_file ()#80x00000000006185ec in zend_execute_scripts ()#90x00000000005c778d in php_execute_script ()#10 0x00000000006a592d in main () 根据上面的堆栈信息，我们可以肯定php的apc模块申请互斥锁权限时，一直获取不到互斥锁权限，一直等待，导致卡死了。
接下来，我们查下，是什么导致apc模块一直拿不到互斥锁权限。我们使用gdb排查，最终查出互斥锁的权限被进程号11274的进程占用着。查杀步骤如下：
$ sudo gdb -p 26748(gdb) thread 2(gdb) bt#00x0000003cf9e0d174 in __lll_lock_wait () from /lib64/libpthread.so.0#10x0000003cf9e08aca in _L_lock_1034 () from /lib64/libpthread.so.0#20x0000003cf9e0898c in pthread_mutex_lock () from /lib64/libpthread.so.0#30x00007f4a135eeb19 in apc_pthreadmutex_lock (lock=0x7f4a0446e088) at /home/APC-3.1.9/apc_pthreadmutex.c:72#40x00007f4a135e7fb8 in apc_cache_find_slot (cache=0x27fc100, key= {data = {file = {device = 43379392, inode = 48}, user = {identifier = 0x295eac0 "/home/wanke/wanke_htdocs/openapi/index.php",>"/home/wanke/wanke_htdocs/openapi/index.php", fullpath_len = 48}}, h = 5063011506047779259, mtime = 1392709731, type = 3 '\003', md5 = "\002\000\000\000\000\000\000\032*'\000\000"}, t=1392709731) at /home/APC-3.1.9/apc_cache.c:640#50x00007f4a135e8323 in apc_cache_find (cache=0x7f4a0446e088, key= {data = {file = {device = 43379392, inode = 48}, user = {identifier = 0x295eac0 "/home/htdocs/openapi/index.php",>"/home/htdocs/openapi/index.php", fullpath_len = 48}}, h = 5063011506047779259, mtime = 1392709731, type = 3 '\003', md5 = "\002\000\000\000\000\000\000\032*'\000\000"}, t=0) at /home/APC-3.1.9/apc_cache.c:695#60x00007f4a135edd27 in my_compile_file (h=0x7fffe1896080, type=8) at /home/APC-3.1.9/apc_main.c:529#70x000000000050c651 in phar_compile_file ()#80x00000000006185ec in zend_execute_scripts ()#90x00000000005c778d in php_execute_script ()#10 0x00000000006a592d in main ()(gdb) print (pthread_mutex_t *) 0x7f4a0446e088$1 = (union {...} *) 0x7f4a0446e088(gdb) print $1.__data.__owner$11 = 11274(gdb) 那么为啥11274进程一直占用互斥锁权限，不释放呢？最终发现这个进程已经退出了。11274的进程为啥会退出呢？在php-fpm 的日志中找到了答案。
NOTICE: child 11274 started
WARNING: child 11274 exited on signal 11 (SIGSEGV) after 0.089068 seconds from start
显然，11274进程运行过程中遇到了段错误，导致进程异常退出了。继续追查，发现是php的hsf扩展在启动初始化的时候遇到内存问题，导致段错误。
现在原因已经很明确了，是因为php扩展hsf启动的时候发生内存错误，导致php-fpm进程异常退出。退出的进程当时拥有apc的互斥锁。但是退出时，由于是异常退出，没能释放互斥锁。导致php-fpm其他进程无法获取apc的互斥锁。导致死锁。
那么如何解决呢？
1.与惠新宸（apc维护者之一）沟通，他建议不要再使用apc，建议换成opcache。因为apc已经基本不再维护。之前也做过opcache和apc的对比。可以看下这篇文章。
php的 zend opcache VS apc 性能比较
2.hsf相关的问题，已经提交相关开发人员去完善。
3.如果你对apc情有独钟，不离不弃。那建议看看下面的文章，自己尝试修改下源码修复这个问题。
https://bugs.php.net/bug.php?id=46025
https://bugs.php.net/patch-display.php?bug_id=59281&patch=APC-3.1.9-bailout_deadlock.patch&revision=latest
页:
[1]