<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    放翁(文初)的一畝三分地

      BlogJava :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
      210 隨筆 :: 1 文章 :: 320 評論 :: 0 Trackbacks
     

    SIP的第四期結(jié)束了,因為控制策略的豐富,早先的的壓力測試結(jié)果已經(jīng)無法反映在高并發(fā)和高壓力下SIP的運行狀況,因此需要重新作壓力測試。跟在測試人員后面做了快一周的壓力測試,壓力測試的報告也正式出爐,本來也就算是告一段落,但第二天測試人員說要修改報告,由于這次作壓力測試的同學(xué)是第一次作,有一個指標(biāo)沒有注意,因此需要修改幾個測試結(jié)果。那個沒有注意的指標(biāo)就是load average,他和我一樣開始只是注意了CPU,內(nèi)存的使用狀況,而沒有太注意這個指標(biāo),這個指標(biāo)與他們通常的限制(10左右)有差別。重新測試的結(jié)果由于這個指標(biāo)被要求壓低,最后的報告顯然不如原來的好看。自己也沒有深入過壓力測試,但是覺得不搞明白對將來機器配置和擴(kuò)容都會有影響,因此去問了DBASA,得到的結(jié)果相差很大,看來不得不自己去找找問題的根本所在了。

           通過下面的幾個部分的了解,可以一步一步的找出Load Average在壓力測試中真正的作用。

    CPU時間片

           為了提高程序執(zhí)行效率,大家在很多應(yīng)用中都采用了多線程模式,這樣可以將原來的序列化執(zhí)行變?yōu)椴⑿袌?zhí)行,任務(wù)的分解以及并行執(zhí)行能夠極大地提高程序的運行效率。但這都是代碼級別的表現(xiàn),而硬件是如何支持的呢?那就要靠CPU的時間片模式來說明這一切。程序的任何指令的執(zhí)行往往都會要競爭CPU這個最寶貴的資源,不論你的程序分成了多少個線程去執(zhí)行不同的任務(wù),他們都必須排隊等待獲取這個資源來計算和處理命令。先看看單CPU的情況。下面兩圖描述了時間片模式和非時間片模式下的線程執(zhí)行的情況:


    1 非時間片線程執(zhí)行情況


    2 非時間片線程執(zhí)行情況

           在圖一中可以看到,任何線程如果都排隊等待CPU資源的獲取,那么所謂的多線程就沒有任何實際意義。圖二中的CPU Manager只是我虛擬的一個角色,由它來分配和管理CPU的使用狀況,此時多線程將會在運行過程中都有機會得到CPU資源,也真正實現(xiàn)了在單CPU的情況下實現(xiàn)多線程并行處理。

           CPU的情況只是單CPU的擴(kuò)展,當(dāng)所有的CPU都滿負(fù)荷運作的時候,就會對每一個CPU采用時間片的方式來提高效率。

           Linux的內(nèi)核處理過程中,每一個進(jìn)程默認(rèn)會有一個固定的時間片來執(zhí)行命令(默認(rèn)為1/100秒),這段時間內(nèi)進(jìn)程被分配到CPU,然后獨占使用。如果使用完,同時未到時間片的規(guī)定時間,那么就主動放棄CPU的占用,如果到時間片尚未完成工作,那么CPU的使用權(quán)也會被收回,進(jìn)程將會被中斷掛起等待下一個時間片。

    CPU利用率和Load Average的區(qū)別

           壓力測試不僅需要對業(yè)務(wù)場景的并發(fā)用戶等壓力參數(shù)作模擬,同時也需要在壓力測試過程中隨時關(guān)注機器的性能情況,來確保壓力測試的有效性。當(dāng)服務(wù)器長期處于一種超負(fù)荷的情況下運行,所能接收的壓力并不是我們所認(rèn)為的可接受的壓力。就好比項目經(jīng)理在給一個人估工作量的時候,每天都讓這個人工作12個小時,那么所制定的項目計劃就不是一個合理的計劃,那個人遲早會垮掉,而影響整體的項目進(jìn)度。

    CPU利用率在過去常常被我們這些外行認(rèn)為是判斷機器是否已經(jīng)到了滿負(fù)荷的一個標(biāo)準(zhǔn),看到50%-60%的使用率就認(rèn)為機器就已經(jīng)壓到了臨界了。CPU利用率,顧名思義就是對于CPU的使用狀況,這是對一個時間段內(nèi)CPU使用狀況的統(tǒng)計,通過這個指標(biāo)可以看出在某一個時間段內(nèi)CPU被占用的情況,如果被占用時間很高,那么就需要考慮CPU是否已經(jīng)處于超負(fù)荷運作,長期超負(fù)荷運作對于機器本身來說是一種損害,因此必須將CPU的利用率控制在一定的比例下,以保證機器的正常運作。

    Load AverageCPULoad,它所包含的信息不是CPU的使用率狀況,而是在一段時間內(nèi)CPU正在處理以及等待CPU處理的進(jìn)程數(shù)之和的統(tǒng)計信息,也就是CPU使用隊列的長度的統(tǒng)計信息。為什么要統(tǒng)計這個信息,這個信息的對于壓力測試的影響究竟是怎么樣的,那就通過一個類比來解釋CPU利用率和Load Average的區(qū)別以及對于壓力測試的指導(dǎo)意義。

    我們將CPU就類比為電話亭,每一個進(jìn)程都是一個需要打電話的人。現(xiàn)在一共有4個電話亭(就好比我們的機器有4核),有10個人需要打電話。現(xiàn)在使用電話的規(guī)則是管理員會按照順序給每一個人輪流分配1分鐘的使用電話時間,如果使用者在1分鐘內(nèi)使用完畢,那么可以立刻將電話使用權(quán)返還給管理員,如果到了1分鐘電話使用者還沒有使用完畢,那么需要重新排隊,等待再次分配使用。


    3 電話使用場景

           上圖中對于使用電話的用戶又作了一次分類,1min的代表這些使用者占用電話時間小于等于1min2min表示使用者占用電話時間小于等于2min,以此類推。根據(jù)電話使用規(guī)則,1min的用戶只需要得到一次分配即可完成通話,而其他兩類用戶需要排隊兩次到三次。

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

    每一個分配到電話的使用者使用電話時間的總和去除以統(tǒng)計的時間段。這里需要注意的是是使用電話的時間總和(sum(active use cpu time)),這與占用時間的總和(sum(occupy cpu time))是有區(qū)別的。(例如一個用戶得到了一分鐘的使用權(quán),在10秒鐘內(nèi)打了電話,然后去查詢號碼本花了20秒鐘,再用剩下的30秒打了另一個電話,那么占用了電話1分鐘,實際只是使用了40秒)

    電話的Average Load體現(xiàn)的是在某一統(tǒng)計時間段內(nèi),所有使用電話的人加上等待電話分配的人一個平均統(tǒng)計。

    電話利用率的統(tǒng)計能夠反映的是電話被使用的情況,當(dāng)電話長期處于被使用而沒有的到足夠的時間休息間歇,那么對于電話硬件來說是一種超負(fù)荷的運作,需要調(diào)整使用頻度。而電話Average Load卻從另一個角度來展現(xiàn)對于電話使用狀態(tài)的描述,Average Load越高說明對于電話資源的競爭越激烈,電話資源比較短缺。對于資源的申請和維護(hù)其實也是需要很大的成本,所以在這種高Average Load的情況下電話資源的長期“熱競爭”也是對于硬件的一種損害。

    低利用率的情況下是否會有高Load Average的情況產(chǎn)生呢?理解占有時間和使用時間就可以知道,當(dāng)分配時間片以后,是否使用完全取決于使用者,因此完全可能出現(xiàn)低利用率高Load Average的情況。由此來看,僅僅從CPU的使用率來判斷CPU是否處于一種超負(fù)荷的工作狀態(tài)還是不夠的,必須結(jié)合Load Average來全局的看CPU的使用情況和申請情況。

    所以回過頭來再看測試部對于Load Average的要求,在我們機器為8CPU的情況下,控制在10 Load左右,也就是每一個CPU正在處理一個請求,同時還有2個在等待處理。看了看網(wǎng)上很多人的介紹一般來說Load簡單的計算就是2* CPU個數(shù)減去1-2左右(這個只是網(wǎng)上看來的,未必是一個標(biāo)準(zhǔn))。

    補充幾點:

    1.對于CPU利用率和CPU Load Average的結(jié)果來判斷性能問題。首先低CPU利用率不表明CPU不是瓶頸,競爭CPU的隊列長期保持較長也是CPU超負(fù)荷的一種表現(xiàn)。對于應(yīng)用來說可能會去花時間在I/O,Socket等方面,那么可以考慮是否后這些硬件的速度影響了整體的效率。

    這里最好的樣板范例就是我在測試中發(fā)現(xiàn)的一個現(xiàn)象:SIP當(dāng)前在處理過程中,為了提高處理效率,將控制策略以及計數(shù)信息都放置在Memcached Cache里面,當(dāng)我將Memcached Cache配置擴(kuò)容一倍以后,CPU的利用率以及Load都有所下降,其實也就是在處理任務(wù)的過程中,等待Socket的返回對于CPU的競爭也產(chǎn)生了影響。

    2.未來多CPU編程的重要性。現(xiàn)在服務(wù)器的CPU都是多CPU了,我們的服務(wù)器處理能力已經(jīng)不再按照摩爾定律來發(fā)展。就我上面提到的電話亭場景來看,對于三種不同時間需求的用戶來說,采用不同的分配順序,我們可看到的Load Average就會有不同。假設(shè)我們統(tǒng)計Load的時間段為2分鐘,如果將電話分配的順序按照:1min的用戶,2min的用戶,3min的用戶來分配,那么我們的Load Average將會最低,采用其他順序?qū)胁煌慕Y(jié)果。所以未來的多CPU編程可以更好的提高CPU的利用率,讓程序跑的更快。

    以上所提到的內(nèi)容未必都是很準(zhǔn)確或者正確,如果有任何的偏差也請大家指出,可以糾正一些不清楚的概念。

    posted on 2008-06-30 17:35 岑文初 閱讀(37495) 評論(17)  編輯  收藏

    評論

    # re: 理解Load Average做好壓力測試 2008-06-30 22:44 yeshucheng
    通俗易懂,很不錯!
    很多場景可能真的要在像阿里這樣的公司才能親身體會深刻  回復(fù)  更多評論
      

    # re: 理解Load Average做好壓力測試 2008-10-29 15:32 xiao
    很好!
      回復(fù)  更多評論
      

    # re: 理解Load Average做好壓力測試 2009-05-15 22:15 鴨嘴
    好文章。  回復(fù)  更多評論
      

    # re: 理解Load Average做好壓力測試[未登錄] 2009-07-09 16:42 Brian
    好文好文好文  回復(fù)  更多評論
      

    # re: 理解Load Average做好壓力測試 2009-07-27 12:29 吾同樹
    很好,這次解決一些疑惑了,以前總是不明白CPU 利用率很底可是load average 卻一直很高的原因。  回復(fù)  更多評論
      

    # re: 理解Load Average做好壓力測試 2010-05-17 15:12 dreamail
    對于在I/O和Wait的進(jìn)程來說,應(yīng)該不在競爭隊列里的。
    不過確實好文,學(xué)習(xí)了。  回復(fù)  更多評論
      

    # re: 理解Load Average做好壓力測試 2011-01-06 14:43 sealcomeback
    寫的不錯,很專業(yè)  回復(fù)  更多評論
      

    # re: 理解Load Average做好壓力測試 2011-05-12 10:31 小丫頭
    好文章  回復(fù)  更多評論
      

    # re: 理解Load Average做好壓力測試 2011-07-01 17:02 f
    跟阿里有個P關(guān)系啊,2B@yeshucheng
      回復(fù)  更多評論
      

    # re: 理解Load Average做好壓力測試 2011-08-16 20:44 淘寶實習(xí)生
    很好的文章,放翁表達(dá)能力確實很強
    不過看了后,有兩個不是很明白的點,希望解答。
    首先,多線程模式并不是在單CPU模式下就提高不了效率了吧? 多線程提高性能個人感覺還是很明顯的,一是大部分應(yīng)用都會有較多IO/SOCKET等阻塞,此時多線程可以極大的提高性能,關(guān)鍵看IO和CPU計算的比例。
    二是,在cpu load average中,被IO和socket阻塞的線程,此時根據(jù)線程、進(jìn)程切換模型,他們應(yīng)該是屬于阻塞的,不在cpu load 隊列范圍內(nèi)吧?
    而且,以1min打電話的例子,如果20秒翻電話本(IO),貌似調(diào)度進(jìn)程中,此時會將CPU調(diào)度給另外一個進(jìn)程?
    可是,如果有多個任務(wù)(多個人在排隊打電話,),一有IO就調(diào)度(有人翻電話本時,就讓另外一個人先打)的話,那么CPU的消耗應(yīng)該只有調(diào)度線程的上下文切換開銷(進(jìn)出電話亭),那么CPU的利用率,應(yīng)該還是會比較高吧?

      回復(fù)  更多評論
      

    # re: 理解Load Average做好壓力測試[未登錄] 2011-12-13 08:54 will
    請問在Ubuntu下Gnome上有個監(jiān)視器,其中有內(nèi)存、CPU、Net、磁盤讀寫、Swap Space 及 System Load Average. 這里的System Load Average 是指什么呢?它一般在剛啟動后值會比較高,是指CPU的等待隊列還是 系統(tǒng)尚未加載的服務(wù)之類的等待隊列呢? 感覺有點像就是指CPU Load Average, 不知是不是這樣?  回復(fù)  更多評論
      

    # re: 理解Load Average做好壓力測試 2012-09-04 07:21 froth
    請問一下,load average中指cpu,還是指核心數(shù)?  回復(fù)  更多評論
      

    # re: 理解Load Average做好壓力測試 2013-03-29 09:20 測試
    一頭霧水,想看懂費勁  回復(fù)  更多評論
      

    # re: 理解Load Average做好壓力測試[未登錄] 2013-09-06 10:16 leo
    @淘寶實習(xí)生,對于第一個問題,放翁是站在cpu的角度來講的,意思就是說,在單個cpu情況下,管你多少個線程 ,只能串行化,一個一個來。站在業(yè)務(wù)的角度,多線程肯定是有必要的。
    對于第二個問題,你只說明了在某種特點的情況下,不足以表征整個問題。例如,cpu給我了時間片,我沒有執(zhí)行任務(wù),也是sleep掉,那么有可能其他線程也還是執(zhí)行不了  回復(fù)  更多評論
      

    # re: 理解Load Average做好壓力測試 2013-12-10 11:45 simia
    好像有些懂了,謝謝  回復(fù)  更多評論
      

    # re: 理解Load Average做好壓力測試 2014-11-17 17:40 Tomato
    “一有IO就調(diào)度(有人翻電話本時,就讓另外一個人先打)的話,“我認(rèn)為不會有這種情況發(fā)生,CPU在某個時間片內(nèi)處理數(shù)據(jù)的話,會先把數(shù)據(jù)加載到內(nèi)存的@淘寶實習(xí)生  回復(fù)  更多評論
      

    # re: 理解Load Average做好壓力測試 2015-08-18 18:10 show
    怎么看cpu的使用率和占用率  回復(fù)  更多評論
      


    只有注冊用戶登錄后才能發(fā)表評論。


    網(wǎng)站導(dǎo)航:
     
    主站蜘蛛池模板: 亚洲成a人片在线观看播放| 亚洲va久久久久| 永久免费av无码网站韩国毛片| 在线a亚洲老鸭窝天堂av高清| 免费A级毛片在线播放不收费| 免费观看91视频| 亚洲精品精华液一区二区| 亚洲?V无码成人精品区日韩| 免费无码又爽又刺激网站直播| 亚洲一级毛片免费看| 日韩亚洲国产综合久久久| 免费无码又爽又刺激高潮视频 | 亚洲AV无码一区二区三区牛牛| 亚洲国产精品专区在线观看| 国产成人免费高清激情明星| 无码天堂va亚洲va在线va| 久久精品国产亚洲av水果派| 亚洲乱码国产一区网址| 一二三四在线播放免费观看中文版视频 | 亚洲va久久久噜噜噜久久男同| 免费无码又爽又高潮视频| 人人揉揉香蕉大免费不卡| 亚洲成AV人片在WWW| 亚洲精品自拍视频| 亚洲伊人久久大香线蕉综合图片| 影音先锋在线免费观看| 99久热只有精品视频免费观看17| 成人免费观看男女羞羞视频| 亚洲国产精品久久久久秋霞影院| 国产亚洲精品精品国产亚洲综合| 免费观看a级毛片| 国产曰批免费视频播放免费s| 好吊色永久免费视频大全| 亚洲avav天堂av在线网毛片| 亚洲视频手机在线| 亚洲乱亚洲乱妇无码麻豆| 亚洲精品人成无码中文毛片| 日日操夜夜操免费视频| 老司机在线免费视频| 久久WWW免费人成一看片| 久久精品成人免费观看|