為什么超過80%的資源利用率會成為任何系統的噩夢

在 Skipjaq ，我們關注應用在最高可持續負載狀態下的性能表現。在此狀態下，應用的負載不至于過飽和乃至崩潰，但也沒有絲毫空閑，可以說是該應用性能最真實的體現。我們尤其關注的是，應用在臨近極限情況下會產生怎樣的延時。

在最近的一次有關Web應用延時的團隊討論當中，我提到一個通用準則：延時在服務利用率（utilisation）超過80%之后會呈現明顯的惡化。再說得確切一點，是服務等待時間（wait time）的惡化導致了延時（latency）的惡化。

John D. Cook 為此撰寫過一篇 很長的文章 進行說明，不過我想再補充一些更深入的說明，以便于沒接觸過隊列理論（queuing theory）的讀者們理解。

服務即隊列

80%這個數字來自于隊列理論。首先，我們看一下為什么Web應用服務符合隊列理論的模型。

假設我們正要測量一個Web應用（服務）的延時，該應用運行在單臺服務器上。請求到達服務并被處理掉。如果在一個新請求進入的時候，該服務仍然在處理之前的其他請求，則新請求就需要排隊等待。出于簡化的考慮，我們假設該隊列可以無限延長，并且任何進入隊列的請求都僅在服務完成其處理之后才離開隊列。

對于本場景而言，最簡單的隊列模型是M/M/1模型。M/M/1是 Kendall標記法 ，此處的通用形式是A/S/c，其中A代表到達過程，S代表服務時間分布，c代表服務器的數量。

在本處簡化的場景中，我們只有一臺服務器，所以 c = 1。模型中的M代表馬可夫（Markov）。馬可夫式的到達過程描述了一個 泊松過程 ：每兩個請求到達的間隔時間呈指數分布，其參數為 ；馬可夫式的服務時間分布也描述了一個泊松過程：完成一次服務的時間呈指數分布，其參數為 。

隊列利用率

我們所說的服務利用率，其定義為：服務用于處理請求所花費的時間百分比。對于上述M/M/1隊列而言，服務利用率的計算方式為：

隊列在 時處于穩定態，這符合直覺：如果單位時間內的新增請求數大于被處理完畢的請求數，則隊列將會無限延長。

延時的計算

利特爾法則 是從隊列理論推演出的最有趣的結論之一。簡單來說，在一個穩定系統當中，客戶的平均數量（L）等于其到達率（ ）與每個客戶在系統中平均耗時（W）的乘積：

對于每一位客戶而言，其在系統中的平均耗時就相當于是該客戶所感受到的延時。該數值由服務時間和等待時間兩部分組成。直覺上，平均服務時間基本上是固定的，所以延時的變動主要取決于等待時間的變動。

我們現在關心的是延時，所以讓我們把公式轉換到另一邊：

也就是說，如果我們知道系統中的平均客戶數量，我們就能夠計算出等待時間。在一個M/M/1隊列中，客戶數量的平均數的計算方式為：

具體的推導過程不在本文中贅述，感興趣的讀者可以參閱 這篇文章 。

上面說過，服務利用率 ，所以：

這樣，我們就有了一個有關延時與到達率、服務完成率之間關聯性的簡化公式。現在我們進一步想要得到延時與利用率之間的關聯公式，這就需要套用 到上面的公式中：

綜上所述，我們已經假設服務時間是固定的，即： 是常量。所以，延時與 成比例關系。將該公式畫成圖表：

可以明顯看到延時在利用率超過80%之后就開始飆升。利用率越接近100%，延時越傾向于無限大。

結論

延時在服務利用率超過80%之后迅速惡化。所以為了避免在生產環境手忙腳亂的處理延時問題，我們應當監控系統利用率，確保其不超過80%的危險范圍。

給系統進行性能測試的時候，讓系統負載到80%以上的結果往往都是延時無法達標，而讓系統負載到接近100%則意味著你要等很久才能拿到測試結果！

英文原文： Relating Service Utilisation to Latency