php-fpm 子进程在信号 11 上退出

Question

我们的应用程序在 AWS 上的 Docker 容器中运行:

• 操作系统:Ubuntu 14.04.2 LTS(可信赖的塔尔)
• Nginx版本:nginx/1.4.6 (Ubuntu)
• Memcached版本:memcached 1.4.14
• PHP 版本:PHP 5.5.9-1ubuntu4.11 (cli)(构建时间:2015 年 7 月 2 日 15:23:08)
• 系统内存:7.5 GB

我们得到空白页和 404 错误的频率较低。在查看日志时，我发现 php-child 进程被杀死，似乎内存主要由 memcache 和 php-fpm 进程使用，并且可用内存非常低。

memcache 配置为使用 2 GB 内存。

这里是 php www.conf

pm = dynamic
pm.max_children = 30
pm.start_servers = 9
pm.min_spare_servers = 4
pm.max_spare_servers = 14
rlimit_files = 131072
rlimit_core = unlimited

错误日志

/var/log/nginx/php5-fpm.log
[29-Jul-2015 14:37:09] WARNING: [pool www] child 259 exited on signal 11 (SIGSEGV - core dumped) after 1339.412219 seconds from start

/var/log/nginx/error.log

2015/07/29 14:37:09 [error] 141#0: *2810 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: x.x.x.x, server: _, request: "GET /suggestions/business?q=Selectfrom HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "example.com", referrer: "http://example.com/"

/var/log/nginx/php5-fpm.log
[29-Jul-2015 14:37:09] NOTICE: [pool www] child 375 started


/var/log/nginx/php5-fpm.log:[29-Jul-2015 14:37:56] WARNING: [pool www] child 290 exited on signal 11 (SIGSEGV - core dumped) after 1078.606356 seconds from start

核心转储

Core was generated by php-fpm: pool www.Program terminated with signal SIGSEGV, Segmentation fault.#0  0x00007f41ccaea13a in memcached_io_readline(memcached_server_st*, char*, unsigned long, unsigned long&) () from /usr/lib/x86_64-linux-gnu/libmemcached.so.10

dmesg

[Wed Jul 29 14:26:15 2015] php5-fpm[12193]: segfault at 7f41c9e8e2da ip 00007f41ccaea13a sp 00007ffcc5730ce0 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]
[Wed Jul 29 14:28:26 2015] php5-fpm[12211]: segfault at 7f41c966b2da ip 00007f41ccaea13a sp 00007ffcc5730ce0 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]
[Wed Jul 29 14:29:16 2015] php5-fpm[12371]: segfault at 7f41c9e972da ip 00007f41ccaea13a sp 00007ffcc5730b70 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]
[Wed Jul 29 14:35:36 2015] php5-fpm[12469]: segfault at 7f41c96961e9 ip 00007f41ccaea13a sp 00007ffcc5730ce0 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]
[Wed Jul 29 14:35:43 2015] php5-fpm[12142]: segfault at 7f41c9e6c2bd ip 00007f41ccaea13a sp 00007ffcc5730b70 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]
[Wed Jul 29 14:37:07 2015] php5-fpm[11917]: segfault at 7f41c9dd22bd ip 00007f41ccaea13a sp 00007ffcc5730ce0 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]
[Wed Jul 29 14:37:54 2015] php5-fpm[12083]: segfault at 7f41c9db72bd ip 00007f41ccaea13a sp 00007ffcc5730ce0 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]

Answer 1

同时在谷歌上搜索同样的问题，并努力寻找与 session (因为我已经排除)不与错误的 PHP 代码相关的解决方案也不 (因为我有几个网站运行完全相同版本的 WordPress，没有一个有问题......除了一个)，我得到一个答案，告诉我可能的解决方案确实涉及删除一些错误的扩展名(通常是 memcache/d，但可以是别的东西)。

由于我的同一个站点在一台 Ubuntu 服务器上完美运行，当切换到更新的服务器时，我立即怀疑是从 PHP 5.5 迁移到 7 导致了问题。这很奇怪，因为没有其他网站受到影响。然后我想起在这个新服务器上还有一点不同:我还安装了New Relic。 .这既是一个扩展程序，也是一个小型服务器，在后台运行并将大量分析数据发送到 New Relic 进行处理。据称，它是一个 PHP 5 扩展，但令人惊讶的是，它在 PHP 7 上也能很好地加载。

现在棘手的地方来了。在某个时候，我已经为该特定网站的 WordPress 安装安装了 W3 Total Cache。随后，我看到那台服务器的性能如此出色以至于 W3TC 是不必要的，并且只是坚持使用更简单的配置。所以我可以卸载 W3TC。这一切都很好，但是……我忘记了我也在 W3TC 上打开了 New Relic(据称，它添加了一些额外的分析数据以发送到 New Relic)。卸载 W3TC 时，我的服务器中的 New Relic 配置中可能还有“一些东西”，它仍在尝试通过 W3TC 接口(interface)发送数据(假设 W3TC 有一个接口(interface)......我真的不知道它是如何工作的级别)，并且由于缺少特定的代码，该网站的 php_fpm 处理程序会失败......有时。不是所有时间，因为我假设，在大多数情况下，nginx 正在发回静态页面。或者也许 php_fpm，在 100 次左右调用后设置为“回收”，会在停止时崩溃。不管到底发生了什么，它肯定与 New Relic 有关——我从 PHP 中删除了 New Relic 扩展后，该网站就恢复了正常工作。

因为这是一个特殊的场景，我只是写这个作为答案，以防将来有人在谷歌上搜索确切的问题。