web-dev-qa-db-ja.com

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

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

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

MySQLサーバーには非常に多くの大規模なデータベースがあり、クエリは正直に言ってソフトウェアの方がはるかに優れている可能性があるため、MySQLがPHP in aタイムリーな方法でカスケード効果を作成すると、最終的にはPHP-FPMをリロードするまですべてが停止し、その後、問題なく機能し始めます。

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

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

今のところ、10分ごとにphp5-fpmのリロードを処理するcrontabを持っているだけで、クラッシュの問題に対処できます。もちろん、PHPリロードすると、nginxは502ゲートウェイエラーをスローするので、あまり解決策ではありません。

PHPはAPCキャッシュを実行しています（問題がある場合）。 APCが特定の状況下でハングアップする可能性があることをいくつか読んだことがあります。

どんなポインタも役に立ちます。いつもこのマシンを気にする必要はありません。

もちろん、より多くの情報を提供できます。必要なものを教えてください。

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

したがって、これは間違いなく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"

pdate 2：これについて、ここでいくつかの進歩がありました。 WordPressキャッシュプラグイン（W3 Total Cache））がクラッシュの原因であることがわかりました。理由はまだわかりませんが、無効になっているため、実行中ですPHPリロードなし、スローダウンなし、クラッシュなしで4時間近くなりました。vBulletinフォーラムでは引き続きAPCを使用しており、まったく問題はありません。特定できる方法はありますか[〜＃〜]なぜ[〜＃〜] APCがクラッシュしますか？WordPressインストールで使用したいのですが、壊れやすいシステムを犠牲にしてはいけません。

mysqlnginxphp-fpm
27
Kevin

あなたは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の動作と安定性に影響を与える変数が多すぎます。

28
Rouben