常に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= …