php-fpm子进程退出信号11

时间：2015-07-29 11:22:19

标签： php linux nginx docker memcached

我们的应用程序在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配置为使用2GB内存。

这是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]

如果需要更多信息，请告诉我

提前致谢

10 个答案:

答案 0 :(得分：15)

在谷歌上搜索同样的问题，并努力寻找一个不与会话相关的解决方案（因为我已经排除了）也到错误的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接口发送数据（假设W3TC有一个接口......我真的不知道它是如何工作的级别），并且，因为缺少特定的代码，该网站的php_fpm处理程序将失败...有些时候。不是所有时间，因为我假设在大多数情况下，nginx正在发回静态页面。或者也许是php_fpm，在100次调用之后设置为'recycle'，会停止崩溃。无论究竟发生了什么，它肯定与New Relic有关 - 只要我从PHP中移除了New Relic扩展，该网站就恢复了正常工作。

因为这是一个特定的场景，所以我只是把它作为一个答案来写，因为将来有人会搜索确切的问题。

答案 1 :(得分：2)

如果php无法将会话信息写入文件，可能会发生这种情况 默认情况下为/var/lib/php/session 您可以使用配置session_save_path

进行更改

https://serverfault.com/questions/427596/phpmyadmin-having-problems-on-nginx-and-php-fpm-on-rhel-6/429445

答案 2 :(得分：1)

就我而言，它是由New Relic PHP Agent引起的。因此，对于导致崩溃的特定功能，我添加了此代码以禁用New Relic 

if (function_exists('newrelic_ignore_transaction')) {
    newrelic_ignore_transaction();
}

参考：https://discuss.newrelic.com/t/how-to-disable-a-specific-transaction-in-php-agent/42384/2

答案 3 :(得分：1)

安装xdebug后我遇到了这个问题，在/etc/php/7.1/fpm/php.ini中添加了一些属性并重新启动了nginx。这是在Homestead Laravel盒子上运行的。

只需重新启动php7.1-fpm服务就可以解决它。

答案 4 :(得分：1)

在我的情况下，它与 zend debug / xdebug 有关。它将一些tcp数据包转发到IDE（phpstorm），它没有监听此端口（调试已关闭）。解决方案是禁用这些扩展或在调试端口上启用调试侦听。

答案 5 :(得分：1)

在我们的案例中，它是由Guzzle + New Relic引起的。在New Relic Agent更新日志中，他们已经提到在版本7.3中有一些Guzzle修复，但即使使用8.0也没有工作，所以仍然有问题。在我们的例子中，这只发生在我们使用Guzzle的两个脚本中。我们发现有两种解决方案：

  1. 在newrelic.guzzle.enabled = false中设置newrelic.ini。您将以External Services标签以这种方式丢失数据，但无论如何您可能都不需要它。
  2. 将New Relic Agent降级到版本6.x，以某种方式也可以使用
  3. 如果您正在阅读此版本，当他们发布了更新版本的8.0版本时，您也可以尝试将新版本的代理更新为最新版本，也许他们会修复该版本

答案 6 :(得分：0)

通常可以通过查看syslog（linux上的/var/log/syslog，mac os上的/var/log/system.log）来查找有关这些崩溃的更多详细信息。

我的系统日志中有Sep 14 11:16:26 bob ReportCrash[89504]: Saved crash report for php-fpm[13757] version 0 to /Users/bob/Library/Logs/DiagnosticReports/php-fpm_2017-09-14-111626_MacBob.crash，生成的文件包含了解哪个扩展有问题的所有内容。

答案 7 :(得分：0)

在我的情况下，我已经在我的代码中停用了缓冲函数ob_start("buffer");;）

答案 8 :(得分：0)

在我的情况下，它是xdebug，卸载后又恢复了正常。

答案 9 :(得分：-1)

可能出现的问题的 php7.3 + Xdebug的，请改变Xdebug的2.7.0rc1或最新版本的Xdebug 2.7.0beta1的XDebug

相关问题
最新问题