linux系統負載相關的概念和度量

系統負載有 CPU利用率 和 LoadAverage這2個概念。
cpu利用率:cpu utilization,是進程(task)被內核調度進程實際分配了CPU資源後,在時間片內使用CPU進行工做運算的時間。它用來描述CPU被使用的狀況。
CPU利用率能夠用top mpstat sar命令來查看。html

LoadAverage : 反映的是系統中全部進程對CPU資源的「爭用」程度。LoadAverage是在一段時間內CPU正在處理以及等待CPU處理的進程數之和的統計信息,也就是CPU使用隊列的長度的統計信息。
LoadAverage能夠用uptime命令來查看。java

CPU利用率和Load Average的區別linux

壓力測試不只須要對業務場景的併發用戶等壓力參數做模擬,同時也須要在壓力測試過程當中隨時關注機器的性能狀況,來確保壓力測試的有效性。當服務器長期處於一種超負荷的狀況下運行,所能接收的壓力並非咱們所認爲的可接受的壓力。就比如項目經理在給一我的估工做量的時候,天天都讓這我的工做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分鐘電話使用者尚未使用完畢,那麼須要從新排隊,等待再次分配使用。

上圖中對於使用電話的用戶又做了一次分類,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)系統 Load 高不必定是性能有問題,系統 Load 高也或許是由於在進行 CPU 密集型的計算(好比編譯)。
(2)系統 Load 高不必定是 CPU 能力問題或數量不夠,Load 高只是表明須要運行的隊列累積過多了。但隊列中的任務實際多是耗 CPU的,也多是耗 I/O 乃至其它因素的。
(3)系統長期 Load 高,不必定要首選增長 CPU,增長 CPU 個別時候會臨時看到系統 Load 降低,但治標不治本。
(4)對於CPU利用率和CPU Load Average的結果來判斷性能問題。首先低CPU利用率不代表CPU不是瓶頸,競爭CPU的隊列長期保持較長也是CPU超負荷的一種表現。對於應用來講可能會去花時間在I/O,Socket等方面,那麼能夠考慮是否後這些硬件的速度影響了總體的效率。
(5)這裏最好的樣板範例就是我在測試中發現的一個現象:SIP當前在處理過程當中,爲了提升處理效率,將控制策略以及計數信息都放置在Memcached Cache裏面,當我將Memcached Cache配置擴容一倍之後,CPU的利用率以及Load都有所降低,其實也就是在處理任務的過程當中,等待Socket的返回對於CPU的競爭也產生了影響。
(6)將來多CPU編程的重要性。如今服務器的CPU都是多CPU了,咱們的服務器處理能力已經再也不按照摩爾定律來發展。就我上面提到的電話亭場景來看,對於三種不一樣時間需求的用戶來講,採用不一樣的分配順序,咱們可看到的Load Average就會有不一樣。假設咱們統計Load的時間段爲2分鐘,若是將電話分配的順序按照:1min的用戶,2min的用戶,3min的用戶來分配,那麼咱們的Load Average將會最低,採用其餘順序將會有不一樣的結果。因此將來的多CPU編程能夠更好的提升CPU的利用率,讓程序跑的更快。編程

參考連接:
http://www.blogjava.net/cenwenchu/archive/2008/06/30/211712.html
https://www.cyberciti.biz/tips/how-do-i-find-out-linux-cpu-utilization.html服務器

相關文章
相關標籤/搜索