我们的应用程序在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]
如果需要更多信息，请告诉我
提前致谢
在谷歌上搜索同样的问题，并努力寻找与会话无关的解决方案（因为我已经排除了这一点），也没有找到错误的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扩展，该网站就恢复了正常工作。
因为这是一个特定的场景，我只是把它写成一个答案，因为将来有人会搜索确切的问题。
可能有问题php7.3 + xdebug，请在Xdebug 2.7.0rc1或最新版本xdebug上更改Xdebug 2.7.0beta1
如果php无法将会话信息写入文件，可能会发生默认情况下它是/var/lib/php/session您可以使用配置session_save_path更改它
就我而言，它是由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
我在安装xdebug之后遇到了这个问题，在/etc/php/7.1/fpm/php.ini中添加了一些属性并重新启动了nginx。这是在Homestead Laravel盒子上运行的。
只需重新启动php7.1-fpm服务就可以解决它。
在我的情况下，它与zend debug / xdebug有关。它将一些tcp数据包转发到IDE（phpstorm），它没有监听此端口（调试已关闭）。解决方案是禁用这些扩展或在调试端口上启用调试侦听。
在我们的例子中，它是由Guzzle + New Relic引起的。在New Relic Agent更新日志中，他们已经提到在版本7.3中有一些Guzzle修复，但即使使用8.0也没有用，所以仍然有问题。在我们的例子中，这只发生在我们使用Guzzle的两个脚本中。我们发现有两种解决方案：
newrelic.guzzle.enabled = false设置newrelic.ini。您将以这种方式丢失External Services标签中的数据，但无论如何您可能不需要它。在我的情况下，我已经在我的代码中停用了缓冲功能ob_start("buffer");;）
在我的情况下，它是xdebug，卸载后它恢复正常。
您可以通过查看系统日志（Linux上的/var/log/syslog，mac os上的/var/log/system.log）找到有关这些崩溃的更多详细信息。
我的syslog上有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，生成的文件包含了解哪个扩展有问题的所有内容。