理解Load Average作好壓力測試

理解Load Average作好壓力測試

SIP的第四期結束了，由於控制策略的豐富，早先的的壓力測試結果已經沒法反映在高併發和高壓力下SIP的運行情況，所以須要從新做壓力測試。跟在測試人員後面作了快一週的壓力測試，壓力測試的報告也正式出爐，原本也就算是告一段落，但次日測試人員說要修改報告，因爲此次做壓力測試的同窗是第一次做，有一個指標沒有注意，所以須要修改幾個測試結果。那個沒有注意的指標就是load average，他和我同樣開始只是注意了CPU，內存的使用情況，而沒有太注意這個指標，這個指標與他們一般的限制（10左右）有差異。從新測試的結果因爲這個指標被要求壓低，最後的報告顯然不如原來的好看。本身也沒有深刻過壓力測試，可是以爲不搞明白對未來機器配置和擴容都會有影響，所以去問了DBA和SA，獲得的結果相差很大，看來不得不本身去找找問題的根本所在了。

經過下面的幾個部分的瞭解，能夠一步一步的找出Load Average在壓力測試中真正的做用。

CPU時間片

爲了提升程序執行效率，你們在不少應用中都採用了多線程模式，這樣能夠將原來的序列化執行變爲並行執行，任務的分解以及並行執行可以極大地提升程序的運行效率。但這都是代碼級別的表現，而硬件是如何支持的呢？那就要靠CPU的時間片模式來講明這一切。程序的任何指令的執行每每都會要競爭CPU這個最寶貴的資源，不論你的程序分紅了多少個線程去執行不一樣的任務，他們都必須排隊等待獲取這個資源來計算和處理命令。先看看單CPU的狀況。下面兩圖描述了時間片模式和非時間片模式下的線程執行的狀況：

圖 1 非時間片線程執行狀況

圖 2 非時間片線程執行狀況

在圖一中能夠看到，任何線程若是都排隊等待CPU資源的獲取，那麼所謂的多線程就沒有任何實際意義。圖二中的CPU Manager只是我虛擬的一個角色，由它來分配和管理CPU的使用情況，此時多線程將會在運行過程當中都有機會獲得CPU資源，也真正實現了在單CPU的狀況下實現多線程並行處理。

多CPU的狀況只是單CPU的擴展，當全部的CPU都滿負荷運做的時候，就會對每個CPU採用時間片的方式來提升效率。

   在Linux的內核處理過程當中，每個進程默認會有一個固定的時間片來執行命令（默認爲1/100秒），這段時間內進程被分配到CPU，而後獨佔使用。若是使用完，同時未到時間片的規定時間，那麼就主動放棄CPU的佔用，若是到時間片還沒有完成工做，那麼CPU的使用權也會被收回，進程將會被中斷掛起等待下一個時間片。

CPU利用率和Load Average的區別

壓力測試不只須要對業務場景的併發用戶等壓力參數做模擬，同時也須要在壓力測試過程當中隨時關注機器的性能狀況，來確保壓力測試的有效性。當服務器長期處於一種超負荷的狀況下運行，所能接收的壓力並非咱們所認爲的可接受的壓力。就比如項目經理在給一我的估工做量的時候，天天都讓這我的工做12個小時，那麼所制定的項目計劃就不是一個合理的計劃，那我的早晚會垮掉，而影響總體的項目進度。

CPU利用率在過去經常被咱們這些外行認爲是判斷機器是否已經到了滿負荷的一個標準，看到50%-60%的使用率就認爲機器就已經壓到了臨界了。CPU利用率，顧名思義就是對於CPU的使用情況，這是對一個時間段內CPU使用情況的統計，經過這個指標能夠看出在某一個時間段內CPU被佔用的狀況，若是被佔用時間很高，那麼就須要考慮CPU是否已經處於超負荷運做，長期超負荷運做對於機器自己來講是一種損害，所以必須將CPU的利用率控制在必定的比例下，以保證機器的正常運做。

Load Average是CPU的Load，它所包含的信息不是CPU的使用率情況，而是在一段時間內CPU正在處理以及等待CPU處理的進程數之和的統計信息，也就是CPU使用隊列的長度的統計信息。爲何要統計這個信息，這個信息的對於壓力測試的影響到底是怎麼樣的，那就經過一個類比來解釋CPU利用率和Load Average的區別以及對於壓力測試的指導意義。

咱們將CPU就類比爲電話亭，每個進程都是一個須要打電話的人。如今一共有4個電話亭（就比如咱們的機器有4核），有10我的須要打電話。如今使用電話的規則是管理員會按照順序給每個人輪流分配1分鐘的使用電話時間，若是使用者在1分鐘內使用完畢，那麼能夠馬上將電話使用權返還給管理員，若是到了1分鐘電話使用者尚未使用完畢，那麼須要從新排隊，等待再次分配使用。

圖 3 電話使用場景

上圖中對於使用電話的用戶又做了一次分類，1min的表明這些使用者佔用電話時間小於等於1min，2min表示使用者佔用電話時間小於等於2min，以此類推。根據電話使用規則，1min的用戶只須要獲得一次分配便可完成通話，而其餘兩類用戶須要排隊兩次到三次。

電話的利用率 = sum (active use cpu time)/period

每個分配到電話的使用者使用電話時間的總和去除以統計的時間段。這裏須要注意的是是使用電話的時間總和(sum(active use cpu time))，這與佔用時間的總和(sum(occupy cpu time))是有區別的。（例如一個用戶獲得了一分鐘的使用權，在10秒鐘內打了電話，而後去查詢號碼本花了20秒鐘，再用剩下的30秒打了另外一個電話，那麼佔用了電話1分鐘，實際只是使用了40秒）

電話的Average Load體現的是在某一統計時間段內，全部使用電話的人加上等待電話分配的人一個平均統計。

電話利用率的統計可以反映的是電話被使用的狀況，當電話長期處於被使用而沒有的到足夠的時間休息間歇，那麼對於電話硬件來講是一種超負荷的運做，須要調整使用頻度。而電話Average Load卻從另外一個角度來展示對於電話使用狀態的描述，Average Load越高說明對於電話資源的競爭越激烈，電話資源比較短缺。對於資源的申請和維護其實也是須要很大的成本，因此在這種高Average Load的狀況下電話資源的長期「熱競爭」也是對於硬件的一種損害。

低利用率的狀況下是否會有高Load Average的狀況產生呢？理解佔有時間和使用時間就能夠知道，當分配時間片之後，是否使用徹底取決於使用者，所以徹底可能出現低利用率高Load Average的狀況。由此來看，僅僅從CPU的使用率來判斷CPU是否處於一種超負荷的工做狀態仍是不夠的，必須結合Load Average來全局的看CPU的使用狀況和申請狀況。

因此回過頭來再看測試部對於Load Average的要求，在咱們機器爲8個CPU的狀況下，控制在10 Load左右，也就是每個CPU正在處理一個請求，同時還有2個在等待處理。看了看網上不少人的介紹通常來講Load簡單的計算就是2* CPU個數減去1-2左右（這個只是網上看來的，未必是一個標準）。

補充幾點：

1．對於CPU利用率和CPU Load Average的結果來判斷性能問題。首先低CPU利用率不代表CPU不是瓶頸，競爭CPU的隊列長期保持較長也是CPU超負荷的一種表現。對於應用來講可能會去花時間在I/O,Socket等方面，那麼能夠考慮是否後這些硬件的速度影響了總體的效率。

這裏最好的樣板範例就是我在測試中發現的一個現象：SIP當前在處理過程當中，爲了提升處理效率，將控制策略以及計數信息都放置在Memcached Cache裏面，當我將Memcached Cache配置擴容一倍之後，CPU的利用率以及Load都有所降低，其實也就是在處理任務的過程當中，等待Socket的返回對於CPU的競爭也產生了影響。

2．將來多CPU編程的重要性。如今服務器的CPU都是多CPU了，咱們的服務器處理能力已經再也不按照摩爾定律來發展。就我上面提到的電話亭場景來看，對於三種不一樣時間需求的用戶來講，採用不一樣的分配順序，咱們可看到的Load Average就會有不一樣。假設咱們統計Load的時間段爲2分鐘，若是將電話分配的順序按照：1min的用戶，2min的用戶，3min的用戶來分配，那麼咱們的Load Average將會最低，採用其餘順序將會有不一樣的結果。因此將來的多CPU編程能夠更好的提升CPU的利用率，讓程序跑的更快。

以上所提到的內容未必都是很準確或者正確，若是有任何的誤差也請你們指出，能夠糾正一些不清楚的概念。