リクエストの頻度が下がると、応答時間が爆発するのはなぜですか？

修正：応答時間（%D）はmsではなくμsです！1

これはこのパターンの奇妙さについては何も変わりませんが、それはそれが実際にそれほど壊滅的でないことを意味します。

応答時間が要求頻度と逆相関するのはなぜですか？

サーバーは、リクエストの処理に忙しくないときに、より速く応答するべきではありませんか？

Apacheをより少ない負荷で「活用」する方法はありますか？

このパターンは周期的です。つまり、インプレッションが1分あたり約200リクエストを下回った場合に表示されます。これは、深夜から早朝まで（自然なユーザーアクティビティにより）発生します。

要求は、1000文字未満のJSONを送信する非常に単純なPOSTです-このJSONは保存されます（テキストファイルに追加されます）-それだけです。返信は「-」です。

グラフに表示されるデータは、Apache自体で記録されました。

LogFormat "%{%Y-%m-%d+%H:%M:%S}t %k %D %I %O" performance
CustomLog "/var/log/apache2/performance.log" performance

これは、データセンターでの一般的な動作です。応答時間が遅い時間は、一般にバッチウィンドウと呼ばれる時間に対応します。これは、ユーザーアクティビティが少なく、バッチプロセスを実行できると予想される期間です。この期間中にバックアップも行われます。これらのアクティビティは、サーバーやネットワークのリソースに負担をかけ、パフォーマンスの問題を引き起こす可能性があります。

問題を引き起こす可能性のあるリソースがいくつかあります。

• 高CPU負荷。これにより、Apacheはリクエストを処理するためのタイムスライスを待機する可能性があります。
• 高いメモリ使用量。これにより、Apacheがリソースをディスクから読み取らずに提供できるようにするバッファーをフラッシュできます。また、Apacheワーカーのページング/スワッピングを引き起こす可能性もあります。
• 高いディスクアクティビティ。これにより、ディスクI / Oアクティビティがキューに入れられ、コンテンツの提供に対応する遅延が発生する場合があります。
• 高いネットワークアクティビティ。これにより、パケットが送信のためにキューに入れられ、再試行が増え、サービスが低下する可能性があります。

私はsarこのように発行された調査に使用します。 毎日のデータファイルにデータをatsar収集するために使用できsarます。これらは、パフォーマンスが正常な日中のシステムの動作がどのようなものかを確認し、パフォーマンスが変動する場合は無視できます。

muninリソース使用率を収集およびグラフ化するシステムまたは他のシステムを監視している場合、そこにいくつかのインジケータがあります。私はまだsarもっと正確だと思います。

以下のようなツールがあるniceとionice、その影響を最小限に抑えるためにバッチ処理に適用することができます。CPUまたはI / Oの問題に対してのみ有効です。メモリまたはネットワークアクティビティの問題を解決する可能性は低いです。

バックアップアクティビティを別のネットワークに移動し、ネットワークの競合を減らします。一部のバックアップソフトウェアは、使用される帯域幅を制限するように構成できます。これにより、ネットワークの競合を解決できます。

バッチプロセスのトリガー方法によっては、並行して実行するバッチプロセスの数を制限できる場合があります。これにより、バッチプロセスで同じリソース競合が発生する可能性が高いため、実際にはバッチプロセスのパフォーマンスが向上する可能性があります。

リクエスト送信者が前のリクエストが完了するのを待ってから新しいリクエストを送信する場合、この関係は別の方向で発生する可能性があります。その場合、クライアント側のキューイングにより、（何らかの理由で）要求時間が長くなるとトラフィックが低下します。

またはそれはあなたの測定のアーチファクトであり得る-ショー上のグラフは次の場合に要求を完了とは対照的に、要求の到着要求処理時間（有限の容量と仮定：D）を大きくなるにつれて、速度が低下します。

@BillThorの答えは正しいかもしれませんが、低負荷の期間がバックアッププロセスによって完全に占有される可能性は低いようです（つまり、期間が正確に一致する）。

別の説明は、単にキャッシュです。特定のスクリプト/データベース/最近使用されていないものがあれば、残りのオペレーティングシステム用にメモリを解放するために、関連するキャッシュデータが削除された可能性があります。これは、データベースのインデックス、ファイルに関連するO / Sバッファ、または同様のものです。クエリは、最後のクエリからしばらく経っている場合、この情報を再構成する必要があります。繁忙期には、最後のクエリが頻繁に行われるため、これは発生しません。あなたは、低応答時間見ている理由も説明するだろうと忙しい期間に高い応答時間を。

そこにあなたが見ているものは、それが統計的な問題であるように見えます。@BillThorの答えは正しくないかもしれませんが、完全を期すためにこれを投稿します。

応答時間のグラフは、パーセンタイルに基づいています。800-1000リクエストのサンプルプールは、このための適切なサンプルカウントです。50-100リクエストのプールはそれほど多くありません。

スローリクエストの数がリクエストボリュームの線形関数ではなく、リクエストの桁違いの増加がスローリクエストの桁違いの増加にならないと仮定すると、リクエストのボリュームが大きくなります平均リクエスト時間が短くなります。

嘘、大きな嘘、統計があります。

私の仮説：リクエストには次の3つのカテゴリがあります。

1. 要求の大部分を含む通常の可変ストリームと、これらはすべて200〜300μs以内に完了します。
2. 毎分約20リクエストの一定レートでの小さなストリーム（夜間でも）。それぞれが完了するのに約2.500μsかかります。
3. 毎分約10リクエスト（夜間でも）の一定レートの小さなストリーム。それぞれ、4.000μsを大きく上回ります。

夜間、1分あたり50件のリクエストは、20 + 20 + 10に相当します。したがって、50％パーセンタイルの結果はストリーム2の結果に強く依存します。また、95％パーセンタイルはストリーム3に依存するため、グラフに表示することさえできません。

日中、ストリーム2 + 3は95％パーセンタイルより上に隠れています。

よく見ると、データ収集に問題があると思うようになります。

まず、TPSで実際に奇妙なことが起こっています。全体的なパターンは正常に見えますが、午後9時ごろに非常に鋭い切れ目があり、午前7時ごろに再び切れ目があります。通常のグラフは、オフピーク時間への移行中にはるかにスムーズになります。

これは、プロファイルに変更があり、おそらく2つの異なるタイプのクライアントがあることを示しています。

1. 午前7時から午後9時までの間のみ、大量に、
2. おそらく24時間体制で、より低い音量で動作する別の方法です。

2番目のヒントは約18:00です。前後のほとんどの時間に、高いボリュームプロファイル、つまり高いTPSと低いレイテンシがあります。しかし、18：00頃に800-1000 RPMから400 RPM未満に突然低下します。何がそれを引き起こす可能性がありますか？

3番目のヒントは、5パーセンタイル応答時間のステップダウンです。私は実際に最小応答時間を見るのを好みます（ただし、5パーセンタイルは多分良いです）：サービス時間（応答時間からキューイングを引いた時間）を教えてくれ、応答時間はワイブル分布に従う傾向があります。 （または最も一般的な値）は最小値のすぐ上です。

5パーセンタイルのステップダウンは、シリーズに突然の中断があり、分散と平均応答時間が大幅に増加したにもかかわらず、実際にサービス時間が低下したことを示しています。

次のステップ

この段階で、ログを詳しく調べて、18：00の少量のサンプルとその前後の大量のサンプルの違いを確認します。

私が探します：

• 地理的な場所の違い（待ち時間が$ request_timeに影響している場合）
• URLの違い（ないはずです）
• HTTPメソッドの違い（POST / GET）（ないはずです）
• 同じIPからの繰り返しリクエスト
• その他の違い...

ところで、18：00の「イベント」は、データセンターの輻輳/アクティビティとは何の関係もないという十分な証拠です。そのためには、輻輳によりTPSが低下する必要があります。これは18:00に発生する可能性がありますが、午後9時から午前7時までの10時間は持続的でスムーズにTPSを低下させることはほとんどありません。