リクエストの頻度が下がると、なぜ応答時間が爆発するのですか
修正：応答時間（%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の答えmayは正解ですが、低負荷の期間がバックアッププロセスによって完全に占有されることはありそうにありません（つまり、期間は正確に一致しています）。
別の説明は、単にキャッシュすることです。特定のスクリプト/データベース/最近使用されていないものは、オペレーティングシステムの残りの部分のメモリを解放するために、関連するキャッシュデータが削除されている可能性があります。これは、データベースのインデックス、ファイルに関連するO/Sバッファー、またはその他の類似物です。最後のクエリからしばらく経過している場合、クエリはこの情報を再構成する必要があります。忙しい期間では、最後のクエリが頻繁に行われるため、これは発生しません。これは、ビジー期間中に低い応答時間and長い応答時間が表示される理由も説明します。
あなたが見ているものは、私には、統計的な問題である可能性があるように見えます。そうではないかもしれませんが、@ BillThorの答えは正しいかもしれませんが、完全を期すためにこれを投稿します。
応答時間のグラフはパーセンタイルベースです。 800〜1000リクエストのサンプルプールは、これに適したサンプル数です。50〜100リクエストのプールは、それほど多くない場合があります。
遅いリクエストの数がリクエストボリュームの線形関数ではなく、リクエストが1桁増加してもスローリクエストが1桁増加しないと想定した場合、リクエストのボリュームが大きくなると、平均リクエスト時間が短い。
嘘、大きな嘘、統計があります。
私の仮説：リクエストには3つの異なるカテゴリがあります。
- リクエストの大部分を含む通常の可変ストリーム。これらはすべて200〜300μs以内に完了します。
- 毎分約20リクエストの一定の速度での小ストリーム（夜間でも）。それぞれの完了には約2.500μsかかります。
- 毎分約10リクエストの一定のレートでの小さなストリーム（夜間でも）。いずれも4.000μsをはるかに上回ります。
夜間は、1分あたり50件のリクエストが20 + 20 + 10に対応します。したがって、50％パーセンタイルの結果はストリーム2の結果に強く依存します。95％パーセンタイルはストリーム3に依存するため、グラフに表示することもできません。
日中、ストリーム2 + 3は95％パーセンタイルの上に十分に隠れています。
よく見るほど、データ収集に問題があると思う傾向があります。
まず、TPSで非常に奇妙なことが起こっています。全体的なパターンは正常に見えますが、午後9時頃にvery鋭いブレークが発生し、その後再び午前7時に発生します。通常のグラフは、オフピーク時間への移行中、はるかにスムーズになります。
これは、プロファイルに変更があり、おそらく2つの異なるタイプのクライアントがあることを示しています。
- 大容量で午前7時から午後9時までの間のみ動作するもの、および
- もう1つは、おそらく24時間、低音量で動作します。
2番目のヒントは18時頃です。ほとんどの場合、前後にはhighボリュームプロファイル、つまり高TPSと低レイテンシがあります。しかし18:00頃に、800-1000 RPMから400 RPM未満に突然低下します。何が原因でしょうか？
3番目のヒントは、5パーセンタイルの応答時間の減少です。私は実際には2つの理由で最小応答時間（ただし、5パーセンタイルの方が良いかもしれません）を確認することを好みます。これは、サービス時間を示します（つまり、応答時間）マイナスキューイング）、および応答時間はワイブル分布に従う傾向があります。つまり、モード（または最も一般的な値）は最小値をわずかに上回っています。
したがって、5パーセンタイルのステップダウンは、シリーズが突然中断したことを示しており、分散と平均応答時間の両方が大幅に増加したにもかかわらず、サービス時間は実際に減少しました。
次のステップ
この段階で、ログを詳しく調べて、18：00の少量サンプルとその前後の大量サンプルの違いを見つけます。
私は探します：
- 地理的位置の違い（待ち時間が$ request_timeに影響している場合）
- uRLの違い（なしである必要があります）
- hTTPメソッドの違い（POST/GET）（なしである必要があります）
- 同じIPからのリクエストの繰り返し
- その他の違い...
ところで、18：00の「イベント」は、データセンターの輻輳/アクティビティとは何の関係もないことを示す十分な証拠です。そのためには、混雑によってTPSが低下する必要があります。これは18:00に発生する可能性がありますが、午後9時から午前7時までの10時間、持続的かつスムーズにTPSの低下を引き起こす可能性は非常に低いです。