我们的应用程序在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扩展,该网站就恢复了正常工作.
因为这是一个特定的场景,我只是把它写成一个答案,因为将来有人会搜索确切的问题.
