• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            大龍的博客

            常用鏈接

            統(tǒng)計

            最新評論

            Load Average (系統(tǒng)負載)(轉(zhuǎn))

            linux load average

              系統(tǒng)平均負載被定義為在特定時間間隔內(nèi)運行隊列中的平均進程數(shù)。如果一個進程滿足以下條件則其就會位于運行隊列中:
            - 它沒有在等待I/O操作的結(jié)果
            - 它沒有主動進入等待狀態(tài)(也就是沒有調(diào)用'wait')
            - 沒有被停止(例如:等待終止)

            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)被要求壓低,最后的報告顯然不如原來的好看。自己也沒有深入過壓力測試,但是覺得不搞明白對將來機器配置和擴容都會有影響,因此去問了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的擴展,當(dāng)所有的CPU都滿負荷運作的時候,就會對每一個CPU采用時間片的方式來提高效率。

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

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

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

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

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

            我們將CPU就類比為電話亭,每一個進程都是一個需要打電話的人。現(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)電話長期處于被使用而沒有的到足夠的時間休息間歇,那么對于電話硬件來說是一種超負荷的運作,需要調(diào)整使用頻度。而電話Average Load卻從另一個角度來展現(xiàn)對于電話使用狀態(tài)的描述,Average Load越高說明對于電話資源的競爭越激烈,電話資源比較短缺。對于資源的申請和維護其實也是需要很大的成本,所以在這種高Average Load的情況下電話資源的長期“熱競爭”也是對于硬件的一種損害。

            低利用率的情況下是否會有高Load Average的情況產(chǎn)生呢?理解占有時間和使用時間就可以知道,當(dāng)分配時間片以后,是否使用完全取決于使用者,因此完全可能出現(xiàn)低利用率高Load Average的情況。由此來看,僅僅從CPU的使用率來判斷CPU是否處于一種超負荷的工作狀態(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))。

             

            關(guān)于Linux系統(tǒng)load average負載的理解

             

              你可能對于 Linux 的負載均值(load averages)已有了充分的了解。負載均值在 uptime 或者 top 命令中可以看到,它們可能會顯示成這個樣子:

            load average: 0.09, 0.05, 0.01

            很多人會這樣理解負載均值:三個數(shù)分別代表不同時間段的系統(tǒng)平均負載(一分鐘、五 分鐘、以及十五分鐘),它們的數(shù)字當(dāng)然是越小越好。數(shù)字越高,說明服務(wù)器的負載越 大,這也可能是服務(wù)器出現(xiàn)某種問題的信號。

            而事實不完全如此,是什么因素構(gòu)成了負載均值的大小,以及如何區(qū)分它們目前的狀況是 “好”還是“糟糕”?什么時候應(yīng)該注意哪些不正常的數(shù)值?

            回答這些問題之前,首先需要了解下這些數(shù)值背后的些知識。我們先用最簡單的例子說明, 一臺只配備一塊單核處理器的服務(wù)器。

            行車過橋

            一 只單核的處理器可以形象得比喻成一條單車道。設(shè)想下,你現(xiàn)在需要收取這條道路的過橋 費 -- 忙于處理那些將要過橋的車輛。你首先當(dāng)然需要了解些信息,例如車輛的載重、以及 還有多少車輛正在等待過橋。如果前面沒有車輛在等待,那么你可以告訴后面的司機通過。 如果車輛眾多,那么需要告知他們可能需要稍等一會。

            因此,需要些特定的代號表示目前的車流情況,例如:

            • 0.00 表示目前橋面上沒有任何的車流。 實際上這種情況與 0.00 和 1.00 之間是相同的,總而言之很通暢,過往的車輛可以絲毫不用等待的通過。
            • 1.00 表示剛好是在這座橋的承受范圍內(nèi)。 這種情況不算糟糕,只是車流會有些堵,不過這種情況可能會造成交通越來越慢。
            • 超過 1.00,那么說明這座橋已經(jīng)超出負荷,交通嚴重的擁堵。 那么情況有多糟糕? 例如 2.00 的情況說明車流已經(jīng)超出了橋所能承受的一倍,那么將有多余過橋一倍的車輛正在焦急的等待。3.00 的話情況就更不妙了,說明這座橋基本上已經(jīng)快承受不了,還有超出橋負載兩倍多的車輛正在等待。

            http:

            上面的情況和處理器的負載情況非常相似。一輛汽車的過橋時間就好比是處理器處理某線程 的實際時間。Unix 系統(tǒng)定義的進程運行時長為所有處理器內(nèi)核的處理時間加上線程 在隊列中等待的時間。

            和收過橋費的管理員一樣,你當(dāng)然希望你的汽車(操作)不會被焦急的等待。所以,理想狀態(tài) 下,都希望負載平均值小于 1.00 。當(dāng)然不排除部分峰值會超過 1.00,但長此以往保持這 個狀態(tài),就說明會有問題,這時候你應(yīng)該會很焦急。

            “所以你說的理想負荷為 1.00 ?”

            嗯,這種情況其實并不完全正確。負荷 1.00 說明系統(tǒng)已經(jīng)沒有剩余的資源了。在實際情況中 ,有經(jīng)驗的系統(tǒng)管理員都會將這條線劃在 0.70:

            • “需要進行調(diào)查法則”: 如果長期你的系統(tǒng)負載在 0.70 上下,那么你需要在事情變得更糟糕之前,花些時間了解其原因。
            • “現(xiàn)在就要修復(fù)法則”:1.00 。 如果你的服務(wù)器系統(tǒng)負載長期徘徊于 1.00,那么就應(yīng)該馬上解決這個問題。否則,你將半夜接到你上司的電話,這可不是件令人愉快的事情。
            • “凌晨三點半鍛煉身體法則”:5.00。 如果你的服務(wù)器負載超過了 5.00 這個數(shù)字,那么你將失去你的睡眠,還得在會議中說明這情況發(fā)生的原因,總之千萬不要讓它發(fā)生。

            那么多個處理器呢?我的均值是 3.00,但是系統(tǒng)運行正常!

            哇喔,你有四個處理器的主機?那么它的負載均值在 3.00 是很正常的。

            在多處理器系統(tǒng)中,負載均值是基于內(nèi)核的數(shù)量決定的。以 100% 負載計算,1.00 表示單個處理器,而 2.00 則說明有兩個雙處理器,那么 4.00 就說明主機具有四個處理器。

            http:

            回到我們上面有關(guān)車輛過橋的比喻。1.00 我說過是“一條單車道的道路”。那么在單車道 1.00 情況中,說明這橋梁已經(jīng)被車塞滿了。而在雙處理器系統(tǒng)中,這意味著多出了一倍的 負載,也就是說還有 50% 的剩余系統(tǒng)資源 -- 因為還有另外條車道可以通行。

            所以,單處理器已經(jīng)在負載的情況下,雙處理器的負載滿額的情況是 2.00,它還有一倍的資源可以利用。

            多核與多處理器

            先脫離下主題,我們來討論下多核心處理器與多處理器的區(qū)別。從性能的角度上理解,一臺主 機擁有多核心的處理器與另臺擁有同樣數(shù)目的處理性能基本上可以認為是相差無幾。當(dāng)然實際 情況會復(fù)雜得多,不同數(shù)量的緩存、處理器的頻率等因素都可能造成性能的差異。

            但即便這些因素造成的實際性能稍有不同,其實系統(tǒng)還是以處理器的核心數(shù)量計算負載均值 。這使我們有了兩個新的法則:

            • “有多少核心即為有多少負荷”法則: 在多核處理中,你的系統(tǒng)均值不應(yīng)該高于處理器核心的總數(shù)量。
            • “核心的核心”法則: 核心分布在分別幾個單個物理處理中并不重要,其實兩顆四核的處理器 等于 四個雙核處理器 等于 八個單處理器。所以,它應(yīng)該有八個處理器內(nèi)核。

            審視我們自己

            讓我們再來看看 uptime 的輸出

            ~ $ uptime
            23:05 up 14 days, 6:08, 7 users, load averages: 0.65 0.42 0.36

            這是個雙核處理器,從結(jié)果也說明有很多的空閑資源。實際情況是即便它的峰值會到 1.7,我也從來沒有考慮過它的負載問題。

            那么,怎么會有三個數(shù)字的確讓人困擾。我們知道,0.65、0.42、0.36 分別說明上一分鐘、最后五分鐘以及最后十五分鐘的系統(tǒng)負載均值。那么這又帶來了一個問題:

            我們以哪個數(shù)字為準(zhǔn)?一分鐘?五分鐘?還是十五分鐘?

            其 實對于這些數(shù)字我們已經(jīng)談?wù)摿撕芏啵艺J為你應(yīng)該著眼于五分鐘或者十五分鐘的平均數(shù) 值。坦白講,如果前一分鐘的負載情況是 1.00,那么仍可以說明認定服務(wù)器情況還是正常的。 但是如果十五分鐘的數(shù)值仍然保持在 1.00,那么就值得注意了(根據(jù)我的經(jīng)驗,這時候你應(yīng) 該增加的處理器數(shù)量了)。

            那么我如何得知我的系統(tǒng)裝備了多少核心的處理器?

            在 Linux 下,可以使用

            cat /proc/cpuinfo

            獲取你系統(tǒng)上的每個處理器的信息。如果你只想得到數(shù)字,那么就使用下面的命令:

            grep 'model name' /proc/cpuinfo | wc -l

            load average 的定義

            在特定時間間隔內(nèi)運行隊列中的平均進程數(shù)。

             

            2 w 命令查看 load average

            load average: 1.00,  0.7,   0.8

                          1分鐘  5 分鐘  15分鐘

            其中分別代表1分鐘,5分鐘,15分鐘系統(tǒng)的平均負載。則三個數(shù)字,會重點觀察5分鐘,15分鐘對應(yīng)的數(shù)值,這反映了系統(tǒng)一段時間的工作狀況。此值低于1.00為正常(注釋1),長時間等于1.00需要引起注意,大于5.00說明系統(tǒng)出現(xiàn)嚴重的 cpu資源不足,隨時可能出問題,屬于critical級別。

             

            3 load average 與cpu 利用率的區(qū)別

            3.1  cpu 利用率的查看,top命令

            3.2 什么是cpu利用率

            單位時間內(nèi)進程使用cpu時間的百分比

            3.3 load average  與cpu 利用率的區(qū)別

            load average=占用cpu進程+排隊進程數(shù)

            cpu利用率=單位時間內(nèi)進程使用cpu時間的百分比

            load average 表示的是cpu還有多少件事情要處理,cpu利用率表示:一個進程別cpu處理時,占用時間片(注釋2)的比值。

             

             

            注釋1:這里指的是1個cpu所對應(yīng)的負載值。

            注釋2:Linux的內(nèi)核處理過程中,每一個進程默認會有一個固定的時間片來執(zhí)行命令(默認為1/100秒),這段時間稱為時間片


            posted on 2011-10-17 15:04 大龍 閱讀(515) 評論(0)  編輯 收藏 引用


            只有注冊用戶登錄后才能發(fā)表評論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            一本久久a久久精品vr综合| 久久午夜夜伦鲁鲁片免费无码影视| 久久精品久久久久观看99水蜜桃| 性高朝久久久久久久久久| 久久99国产精品尤物| 久久久久青草线蕉综合超碰| 伊人久久综合成人网| 四虎国产精品免费久久5151| 天天爽天天狠久久久综合麻豆| 久久久久国产精品三级网| 久久九九有精品国产23百花影院| 久久国产午夜精品一区二区三区| 日韩欧美亚洲综合久久| 久久精品无码专区免费东京热| 欧美精品乱码99久久蜜桃| 成人国内精品久久久久影院| 91精品国产综合久久婷婷| 久久久久久久综合综合狠狠| 色综合久久综合中文综合网| 久久久久国产精品三级网| 99麻豆久久久国产精品免费| 丁香色欲久久久久久综合网| 久久99精品国产麻豆婷婷| 久久国产精品国语对白| 色诱久久久久综合网ywww| 婷婷伊人久久大香线蕉AV| 香港aa三级久久三级老师2021国产三级精品三级在 | 久久国产精品视频| 东京热TOKYO综合久久精品| 久久99热这里只频精品6| 国产日韩欧美久久| 国产精品成人99久久久久| 久久久一本精品99久久精品88| 国产成人久久精品一区二区三区| 久久综合狠狠综合久久97色| 无码乱码观看精品久久| 精品久久久久国产免费| 久久免费美女视频| 国产精品99久久精品爆乳| 国产伊人久久| 久久久久国产精品三级网 |