私たちのアプリケーションは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]
さらに情報が必要な場合はお知らせください
前もって感謝します
同じ問題をグーグルで検索し、セッションに関連したではない解決策を見つけようとしています(私が除外したため)norto bad PHP code(私は複数のWebサイトでまったく同じバージョンのWordPressを実行していて、何も問題がないため... 1つは、可能な解決策はバグのある拡張機能(通常はmemcache/dですが、他の何かである可能性があります)を削除する必要があるという答えを見つけました。
この同じサイトを1台のUbuntuサーバーで問題なく動作させていたため、新しいサーバーに切り替えると、すぐにPHP 5.5から7への移行が問題の原因であることがわかりました。他のWebサイトは影響を受けなかったため、奇妙でした。次に、この新しいサーバーでは別の点が異なることを思い出しました。私は New Relic もインストールしました。これは、バックグラウンドで実行される拡張機能と小さなサーバーの両方です。処理のために多くの分析データをNew Relicに送信します。おそらく、これはPHP 5拡張機能ですが、驚くべきことにPHP 7 。
ここで少し注意が必要です。ある時点で、私はその特定のWebサイトのWordPressインストールにW3 Total Cacheをインストールしました。その後、そのサーバーのパフォーマンスが非常に優れているため、W3TCは不要であり、単にW3TCをアンインストールできるようになりました。これで非常にいいのですが... W3TCでNew Relicをオンにしていることも忘れていました(申し立てによると、追加の分析データが追加されてNew Relicに送信されます)。 W3TCをアンインストールすると、おそらくサーバーのNew Relic設定に「何か」が残っていて、W3TCインターフェースを介してデータを送信しようとしていました(W3TCにインターフェースがあると仮定して...そのレベルでどのように機能するのか本当にわかりません) )、そしてコードの特定のビットが欠落しているため、そのWebサイトのphp_fpmハンドラーが失敗することがあります...ときどきありませんall時間、ほとんどの場合、nginxは静的ページを送り返していたと想定しているためです。あるいは、100回程度の呼び出しの後に「リサイクル」に設定されたphp_fpmかもしれません。 dクラッシュオンストップ。何が起こっていても、それは間違いなくNew Relicに関連していた— PHPからNew Relic拡張機能を削除するとすぐに、そのWebサイトは正常に機能するように戻った。
これはそのような特定のシナリオなので、私はこれを答えとして書いています。将来の誰かが正確な問題についてグーグルで検索する可能性はほとんどありません。
Phpがセッション情報をファイルに書き込めない場合に発生する可能性があります。デフォルトでは/var/lib/php/session
設定を使用して変更できますsession_save_path
Xdebugをインストールし、/ etc/php/7.1/fpm/php.iniにいくつかのプロパティを追加し、nginxを再起動した後、この問題が発生しました。これはHomestead Laravelボックスで実行されています。
Php7.1-fpmサービスを再起動するだけで解決しました。
私たちの場合、それはGuzzle + New Relicが原因でした。 New Relic Agentの変更ログで、バージョン7.3にはGuzzleの修正がいくつかあったが、8.0を使用しても機能しなかったため、まだ問題があると述べています。私たちの場合、これはGuzzleを使用していた2つのスクリプトでのみ発生していました。 2つの解決策があることがわかりました。
newrelic.guzzle.enabled = false
in newrelic.ini
。この方法で External Services タブのデータは失われますが、とにかく必要ないかもしれません。私の場合、それはzend debug/xdebugに関連していました。一部のtcpパケットをIDE(phpstorm)に転送しますが、このポートでリッスンしていませんでした(デバッグはオフ)。解決策は、これらの拡張機能を無効にするか、デバッグポートでリッスンデバッグを有効にすることです。
私の場合、それは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でしたが、アンインストールすると正常に戻りました。
通常、syslog(/var/log/syslog
Linuxでは/var/log/system.log
(Mac OSの場合)。
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
私のsyslog上で、生成されたファイルには、どの拡張機能に問題があったかを知るためのすべてが含まれていました。
考えられる問題php7.3 + xdebug、Xdebug 2.7.0rc1または最新バージョンのxdebugでXdebug 2.7.0beta1を変更してください
私の場合、コードでバッファリング関数ob_start("buffer");
を無効にしました;)