Apacheタイムアウトをデバッグする方法は？

を使用して、Apache 2.2サーバー（Ubuntu Server 10.04、8x2GHz、12Gb RAM）でPHP Webアプリケーションを実行しpreforkます。Apacheは毎日約10万から20万のリクエストを受け取り、そのうち約100から200がタイムアウト制限に達するため（1000に1つ程度）、他のほとんどすべてのリクエストはタイムアウト以下で処理されます。

これが起こる理由を知るにはどうすればよいですか？または、すべてのリクエストの一部がタイムアウトするのは正常ですか？

これは私がこれまでにやったことです：

ご覧のように、タイムアウト制限とより合理的な要求の間にある要求はほとんどありません。現在、タイムアウト制限は50秒に設定されていますが、以前は300に設定されていましたが、タイムアウトが発生してから他のリクエストとのギャップが大きくなるという状況は変わりませんでした。

タイムアウトするAJAXリクエストはすべてリクエストですが、その大部分はリクエストであるため、おそらく偶然でしょう。Apacheの戻りコードは200ですが、タイムアウトの制限に明らかに達しました。それらは広範囲の異なるIPからのものです。

タイムアウトするリクエストを見てきましたが、1秒もかからずに同じリクエストを処理する場合、特別なことは何もありません。

さまざまなリソースを調べて、原因を見つけることはできるが、運はないかどうかを確認しようとしました。常に十分な空きメモリがあり（最小は約3GB空き）、負荷は1.4に達することがあり、CPU使用率は40％になりますが、負荷とCPU使用率が低い場合にタイムアウトの多くが発生します。ディスクの書き込み/読み取りは、日中ほぼ一定です。MySQLスロークエリログにはエントリがありません（1秒を超えるものをログに記録するように設定されています）。

青はCPU使用率で、ピークは40％、マルーンは負荷が1.4の負荷です。そのため、CPU使用率/負荷が低い場合でもタイムアウトが発生することがわかります（10秒のスパイクはCPU使用率によく対応しますが、別の問題であり、それらの原因を突き止めることを期待しています）。

Apacheエラーログにエラーはなく、200を超えるアクティブなApacheプロセスに到達するのを見たことはありません。

サーバー設定：

Timeout 50 
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 2

<IfModule mpm_prefork_module>
    ServerLimit     350
    StartServers        20
    MinSpareServers     75
    MaxSpareServers     150
    MaxClients          320
    MaxRequestsPerChild 5000
</IfModule>

更新：

Ubuntu 12.04.1にアップデートしました。念のため、変更はありません。mod_reqtimeoutに設定を追加しました：

RequestReadTimeout header=20-40,minrate=500
RequestReadTimeout body=10,minrate=500

現在、ほとんどすべてのタイムアウトは10秒で発生し、1つまたは2つは20秒で発生します。ほとんどの場合、受信に問題のあるリクエストボディを取得しているということです。要求の本文は、数百バイトを超えてはなりません。1秒ごとにネットワークトラフィックを監視しましたが、1Mbit / sを超えることはなく、サーバーが1Gbit / sの回線上にあるように思えるので、rxerrsまたはrxdorpsが表示されません。 HopelessN00bについて投稿しました。ユーザー接続が悪い場合がありますか？

1時間ごとのスパイクの場合（上のグラフでは1時間を33分経過しているが、現在は12分経過している）、私は定期的に実行されているものがあるかどうかを確認しようとしました（ cronsなど）が見つかりませんでした。PHPガベージコレクションは1時間に2回実行されますが、スパイク時ではなく、それを無効にしてみましたが、違いはありません。

dstatを--top-cpuおよびtopとともに使用して、スパイク発生時のプロセスを確認しました。表示されるのは、apacheが数秒間一生懸命に動作することだけですが、他のプロセスは重要なCPUを使用していません。

スパイクの拡大グラフを作成しました：

私には、Apacheが数秒間停止し、停止中に着信したリクエストを処理するために懸命に働くように見えます。そのような停止の原因は何ですか、それとも誤解していますか？

最初のグラフを見て最初に気づいたのは、1時間ごとのスローダウン（時間の40分前後で発生）が問題の原因である可能性があることです。OS /データベースのタスクスケジューラをご覧ください。

提供したデータに基づいて、次のステップは、応答時間の頻度（Y軸の応答数とXの期間）を確認することです。ただし、タイムアウトを示すURL（または、一度に1つのURLのみ） ）。典型的なシステムでは、これは正規分布またはポアソン分布に従う必要があります-タイムアウトしているリクエストは単にテールの一部である場合があります-この場合、一般的なチューニングに努力を集中する必要があります。OTOHディストリビューションがバイモーダルの場合、コードのどこかで競合を探す必要があります。

これについては別の考えがあります。1日に大量のリクエストを受け取り、ピーク時間中にのみタイムアウトになるようです（投稿した写真から）。

Server Faultブログに投稿がありますPer Second Measurements Don't Cut It。これらのリクエストの一部が、ServerFaultチームと同じ問題に直面している可能性はありますか？

1 Gbit / sのインターフェイスでは、10〜30 MBit / sのレートでかなり頻繁にパケットを破棄しており、パフォーマンスが低下していることがわかりました。これは、10〜30 MBit / sのレートが実際には5秒あたりに転送されるビット数が1秒のレートに変換されるためです。Wiresharkを詳しく調べて、1ミリ秒のIOグラフを使用すると、いわゆる1 Gbit / sインターフェイスの1ミリ秒あたり1メガビットのレートが頻繁にバーストすることがわかりました。