Apache-2.4
為什麼請求頻率下降時響應時間會爆炸？
更正：響應時間 (
%D) 是 μs 而不是 ms！1這並沒有改變這種模式的怪異之處，但這意味著它實際上具有更少的破壞性。
為什麼響應時間與請求頻率成反比？
當處理請求不那麼忙時，伺服器不應該更快地響應嗎？
有什麼建議可以讓 Apache “利用”更少的負載嗎？
這種模式是周期性的。這意味著如果印像數下降到每分鐘約 200 個請求以下，它就會顯示出來——這種情況從深夜到清晨發生（由於自然的使用者活動）。
請求是非常簡單的 POST，發送少於 1000 個字元的 JSON - 此 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 問題有效。它們不太可能解決記憶體或網路活動的問題。將備份活動移至單獨的網路可以減少網路爭用。一些備份軟體可以配置為限制將使用的頻寬。這可以解決或減少網路爭用問題。
根據觸發批處理的方式，您可以限制並行執行的批處理數量。這實際上可能會提高批處理過程的性能，因為它們可能會遇到相同的資源爭用。