常にPHP-FPMをリロードする必要があります

nginxとPHP-FPMを実行しているかなり負荷の高いサーバーがあります。このサーバーには、PHP-FPMとnginxを実行する6つのWebサイトがあります。ソフトウェアはすべてvBulletin 3.8およびWordPressです。データベースは別のサーバーにあります。

現在、これらは非常に人気のあるWebサイトであるため、通常、一度に7〜8,000人の訪問者がオンラインになり、各ページの大部分がデータベースにアクセスします。これが問題の原因だと思います。

MySQLサーバーには非常に多くの大規模なデータベースがあり、クエリは正直なところソフトウェアではるかに優れている可能性があるため、MySQLは時折PHPに結果を返せず、最終的にはカスケード効果を生み出すと思いますPHP-FPMをリロードするまですべてが停止します。それを行った後、物事は再び正常に動作し始めます。

このトラブルシューティングで問題が発生する理由は、ログから何も実際に識別できないためです。MySQLのスロークエリログでは、ダウンタイムが発生しても何も関心がありません。nginxログには、読み取り要求がタイムアウトしたか、接続がタイムアウトした（PHP-FPMへ）と言っている何千ものエントリがあります。また、PHP-FPMログには、「実行がタイムアウト（31秒）で終了しました」という行がたくさんあります。

したがって、この時点では、どこで問題を探すべきか完全にわかりません。明らかに、これらのスクリプトは時々十分な速さで実行されないため、何が起きているのでしょう（通常は1秒未満でロードされますが、ロード時間が急増する原因が発生します）。これは1日に何度も発生し、私たちにとって非常に大きな問題となっています。

今のところ、クラッシュの問題を処理するために、10分ごとにphp5-fpmのリロードを処理するcrontabを用意しています。もちろん、PHPがリロードすると、nginxは502ゲートウェイエラーをスローするため、あまり解決策にはなりません。

それが重要な場合、PHPはAPCキャッシュを実行しています。特定の状況下でAPCがハングする可能性があることをいくつかのスポットで読みました。

任意のポインターが役立ちます。このマシンをいつも心配する必要はありません。

もちろん、より多くの情報を提供できます。必要なものをお知らせください。

更新： apc.phpをWebルートにコピーし、アクセスして統計を確認しました。物事はよさそうだ。次に、リンクをクリックして[ユーザーの統計]に移動し、サーバーがすぐにハングするようにしました。php-fpmをリロードしてから、ユーザーの統計ページをリロードしましたが、うまくいきました。しばらく待ってから、再度リロードし、サーバーが再びハングしました。

したがって、これは間違いなくAPC関連のようです。質問は-どのように修正すればよいですか？

APC構成：

[apc]
apc.enabled="1"
apc.stat = "1"
apc.max_file_size = "2M"
apc.localcache = "1"
apc.localcache.size = "256"
apc.shm_segments = "1"
apc.ttl = "3600"
apc.user_ttl = "7200"
apc.gc_ttl = "3600"
apc.cache_by_default = "1"
apc.filters = ""
apc.write_lock = "1"
apc.num_files_hint= "10000"
apc.user_entries_hint="10000"
apc.shm_size = "1G"
apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.include_once_override = "0"
apc.file_update_protection="2"
apc.canonicalize = "1"
apc.report_autofilter="0"
apc.stat_ctime="0"

更新2：ここでこれについていくつかの進歩を遂げました。WordPressキャッシュプラグイン（W3 Total Cache）がクラッシュの原因であることが判明しました。理由はまだわかりませんが、無効にすると、リロード、スローダウン、クラッシュなしでPHPを4時間近く実行しています。私たちはまだvBulletinフォーラムでAPCを使用していますが、問題はまったくありません。APCがクラッシュする理由を特定する方法はありますか？WordPressのインストールで使用したいのですが、壊れやすいシステムを犠牲にする必要はありません。

あなたはphp-fpmを使用しているので、php-fpmの子供の生存期間をより積極的にすることをお勧めします。短命のスレッド/子供と安定性の間のスイートスポットを見つける必要があります。php-fpmのデフォルトは、本番システムであるIMHOにとって寛大な方法です。

実稼働プールのpm.max_requestsの数を減らします。デフォルトは200だと思います。50から始めて、それがあなたをどこに連れて行くのか見てみましょう。

それに失敗/補完する場合、これらのグローバルオプションを試すこともできます（デフォルトではすべて無効になっています）：

emergency_restart_threshold=3
emergency_restart_interval=1m
process_control_timeout=5s

これは何を意味するのでしょうか？3つのPHP-FPM子プロセスが1分以内にSIGSEGVまたはSIGBUSで終了（クラッシュ）した場合、PHP-FPMは自動的に再起動することになっています。子プロセスは、マスターからの信号に対する反応を5秒間待機します。

これにより、PHPワーカースレッドのプールが素晴らしく、新鮮できれいになります。ワーカーがリクエストを提供できる時間が長くなるほど、不安定になります。また、メモリリークのリスクが高くなります。

ここで私がここで言及したすべての設定オプションと他のものの素晴らしい概要は次のとおりです：http : //myjeeva.com/php-fpm-configuration-101.html

これらのヒントがお役に立てば幸いです！微調整して観察することを忘れないでください。残念ながら、これらすべての経験則はないようです。PHPの動作と安定性に影響を与える変数が多すぎます。