web-dev-qa-db-ja.com

PHP 100％CPUに到達し、月曜日から金曜日まで同時にRAM

私たちはここ英国で小学校向けの学習プラットフォームを運営しており、すべて非常に順調に運営されています。ただし、月曜日から金曜日の午後4時頃に、同じ問題が発生します。1-2PHPスレッドは100％CPUに急上昇し、サーバーまでRAMを徐々に使い果たします。倒れる。

リクエストの98％以上がHTTPSであり、これらはレイヤー7ロードバランサーに送られ、SSLデータを復号化し、X-HTTP-Forwarded-Forヘッダーを追加して、データをアプリケーションサーバーに転送します（現時点では2つあります）アプリケーションサーバーのポート80にはVarnishがあり、ロードバランサーからのリクエストを受け取り、ポート81のNginxにリクエストを渡します。Nginxは、使用する必要のある「vhost」を特定し、PHPソケットでリッスンしているPHP-CGI（spawn-fcgiで管理）まで処理します。 Memcachedのインスタンスも実行されており、MySQLは別のサーバー/スレーブセットアップで実行されます。

通常、負荷はいずれかのアプリケーションサーバーで1日を通して0.8以下になりますが、午後4時頃に問題が発生します。問題が発生したときに、実際のスレッドのいくつかでstraceを実行することができましたが、常に同じことがわかります。

stat("/usr/share/zoneinfo/Europe/London", {st_mode=S_IFREG|0644,st_size=3661, ...}) = 0
stat("/usr/share/zoneinfo/Europe/London", {st_mode=S_IFREG|0644,st_size=3661, ...}) = 0

これは無限に繰り返され、プロセスをSEGKILLするか、oomkillerがプロセスを強制終了するまで停止しません。その時点で実行するようにスケジュールされているcronジョブはなく、実行中のPHPプロセスに関連付けられているNginxリクエストを正確に確認する方法がありません。

先週5.3.8からアップグレードしたPHP 5.3.14を実行して、古いバージョンが問題である可能性を排除しています。この問題は数か月続いており、何が原因であるかわかりません。ソフトウェアは非常に頻繁に展開されるため、問題が発生した可能性のある特定のリリースを追跡することは困難です。特に、この問題が最初に発生した日付がわからないためです。 Varnishはバージョン3.0.1、Nginxは1.0.6（私は今、約1年前だと理解しています）、サーバーはCentOSリリース5.7（最終版）を実行しており、3.07GhzのIntel i3540と8GBのRAMを搭載しています。

Debianメーリングリストに非常によく似たものについての議論があります、あなたはそれを見つけることができます ここ 。

過去にこのようなものを見たことがありますか、誰かアイデアや提案がありますか？ NginxリクエストをPHPスレッドに直接リンクする方法はありますか？ PHPプロセスが何をしているかを確認するためのより良い方法はありますか？ （PHPを再コンパイルする必要がありますが、GDBが言及されているのを見ました）

ありがとう！

phpcentosnginxtimezonespawn-fcgi
2
Daniel Samuels

私は問題が何であるかを知りました、それはInternetExplorerでした。 CSSに.htcファイルへの誤った参照があり、何らかの理由でPHP処理に送信されていました。PHPは知りませんでした.htcファイルをどうするか、そしてサーバー上で利用可能なすべてのリソースを使い果たしてしまいました。

1
Daniel Samuels

コメントからの追加情報があれば、負荷の急上昇中に問題が発生したと安全に推測できると思います-オンラインユーザーの数は毎日ピークに達します。正確な時刻は決まっておらず、他の時間に発生することもあれば、cronジョブを占有するリソースなどを効果的に除外する日もあります。

クレイジーに聞こえるかもしれませんが、MySQLの最大接続制限を増やすことから始めます-接続制限を超えたときにPHP FCGIとして実行されると、発生している問題とは異なり、奇妙なことが起こります。

0
c2h5oh