技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> 系统运维 --> 小心,apc可能导致php-fpm罢工!

小心,apc可能导致php-fpm罢工!

浏览:1758次  出处信息

   最近线上产品出现了502错误。一般出现502错误,都是php-fpm 进程处理请求时出现异常导致的。

   首先,查看了php-fpm 的进程数。发现php-fpm的进程数已经到达了php-fpm.conf中设置的最大值。最近流量没有特别的变动,这么多php-fpm进程,肯定有问题。

   然后,用pstack命令查看这些php-fpm进程都在干啥。

   [hailong.xhl@s010002.cm8 ~]$ sudo pstack 11740

   Thread 3 (Thread 0x413bb940 (LWP 11741)):

   #0  0x0000003cf92d4018 in epoll_wait () from /lib64/libc.so.6

   #1  0x00007f4a0ffec116 in epoll_poll ()

   #2  0x00007f4a0ffea81d in ez_run () from /home/admin/opt/easy/lib/libeasy.so.0

   #3  0x00007f4a0ffe5b63 in easy_io_on_thread_start ()

   #4  0x0000003cf9e064a7 in start_thread () from /lib64/libpthread.so.0

   #5  0x0000003cf92d3c2d in clone () from /lib64/libc.so.6

   Thread 2 (Thread 0x425a2940 (LWP 11742)):

   #0  0x0000003cf92d4018 in epoll_wait () from /lib64/libc.so.6

   #1  0x00007f4a0ffec116 in epoll_poll ()

   #2  0x00007f4a0ffea81d in ez_run () from /home/admin/opt/easy/lib/libeasy.so.0

   #3  0x00007f4a0fff1772 in easy_baseth_on_start ()

   #4  0x0000003cf9e064a7 in start_thread () from /lib64/libpthread.so.0

   #5  0x0000003cf92d3c2d in clone () from /lib64/libc.so.6

   Thread 1 (Thread 0x7f4a17438710 (LWP 11740)):

   #0  0x0000003cf9e0d174 in __lll_lock_wait () from /lib64/libpthread.so.0

   #1  0x0000003cf9e08aca in _L_lock_1034 () from /lib64/libpthread.so.0

   #2  0x0000003cf9e0898c in pthread_mutex_lock () from /lib64/libpthread.so.0

   #3  0x00007f4a135eeb19 in apc_pthreadmutex_lock ()

   #4  0x00007f4a135e7fb8 in apc_cache_find_slot ()

   #5  0x00007f4a135e8323 in apc_cache_find ()

   #6  0x00007f4a135edd27 in my_compile_file ()

   #7  0x000000000050c651 in phar_compile_file ()

   #8  0x00000000006185ec in zend_execute_scripts ()

   #9  0x00000000005c778d in php_execute_script ()

   #10 0x00000000006a592d in main ()

   根据上面的堆栈信息,我们可以肯定php的apc模块申请互斥锁权限时,一直获取不到互斥锁权限,一直等待,导致卡死了。

   接下来,我们查下,是什么导致apc模块一直拿不到互斥锁权限。我们使用gdb排查,最终查出互斥锁的权限被进程号11274的进程占用着。查杀步骤如下:

   [hailong.xhl@s010002.cm8 ~]$ sudo gdb -p 26748

   (gdb) thread 2

   (gdb) bt

   #0  0x0000003cf9e0d174 in __lll_lock_wait () from /lib64/libpthread.so.0

   #1  0x0000003cf9e08aca in _L_lock_1034 () from /lib64/libpthread.so.0

   #2  0x0000003cf9e0898c in pthread_mutex_lock () from /lib64/libpthread.so.0

   #3  0x00007f4a135eeb19 in apc_pthreadmutex_lock (lock=0x7f4a0446e088) at /home/admin/APC-3.1.9/apc_pthreadmutex.c:72

   #4  0x00007f4a135e7fb8 in apc_cache_find_slot (cache=0x27fc100, key=

         {data = {file = {device = 43379392, inode = 48}, user = {identifier = 0x295eac0 “/home/admin/wanke/wanke_htdocs/openapi/index.php”, identifier_len = 48}, fpfile = {fullpath = 0x295eac0 “/home/admin/wanke/wanke_htdocs/openapi/index.php”, fullpath_len = 48}}, h = 5063011506047779259, mtime = 1392709731, type = 3 ’03′, md5 = “0200000000000032*’0000″}, t=1392709731) at /home/admin/APC-3.1.9/apc_cache.c:640

   #5  0x00007f4a135e8323 in apc_cache_find (cache=0x7f4a0446e088, key=

         {data = {file = {device = 43379392, inode = 48}, user = {identifier = 0x295eac0 “/home/admin/xxxx/index.php”, identifier_len = 48}, fpfile = {fullpath = 0x295eac0 “/home/adminxxxxindex.php”, fullpath_len = 48}}, h = 5063011506047779259, mtime = 1392709731, type = 3 ’03′, md5 = “0200000000000032*’0000″}, t=0) at /home/admin/APC-3.1.9/apc_cache.c:695

   #6  0x00007f4a135edd27 in my_compile_file (h=0x7fffe1896080, type=8) at /home/admin/APC-3.1.9/apc_main.c:529

   #7  0x000000000050c651 in phar_compile_file ()

   #8  0x00000000006185ec in zend_execute_scripts ()

   #9  0x00000000005c778d 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 的日志中找到了答案。

   [18-Feb-2014 15:48:45] NOTICE: [pool www] child 11274 started

   [18-Feb-2014 15:48:45] WARNING: [pool www] 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. 使用APC来保护PHP代码    (阅读:4487)
  2. 多nginx单php-fpm的配置方法    (阅读:3315)
  3. Linux 安装 Nginx PHP fpm    (阅读:2608)
  4. 关于PHP加速器APC的使用    (阅读:1920)
  5. 关于APC的性能优化,请看下面这段话    (阅读:1789)
  6. PHP5.2.x + APC的一个bug的定位    (阅读:1619)
QQ技术交流群:445447336,欢迎加入!
扫一扫订阅我的微信号:IT技术博客大学习
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1