SIP的第四期結(jié)束了，因?yàn)榭刂撇呗缘呢S富，早先的的壓力測(cè)試結(jié)果已經(jīng)無法反映在高并發(fā)和高壓力下SIP的運(yùn)行狀況，因此需要重新作壓力測(cè)試。跟在測(cè)試人員后面做了快一周的壓力測(cè)試，壓力測(cè)試的報(bào)告也正式出爐，本來也就算是告一段落，但第二天測(cè)試人員說要修改報(bào)告，由于這次作壓力測(cè)試的同學(xué)是第一次作，有一個(gè)指標(biāo)沒有注意，因此需要修改幾個(gè)測(cè)試結(jié)果。那個(gè)沒有注意的指標(biāo)就是load average，他和我一樣開始只是注意了CPU，內(nèi)存的使用狀況，而沒有太注意這個(gè)指標(biāo)，這個(gè)指標(biāo)與他們通常的限制（10左右）有差別。重新測(cè)試的結(jié)果由于這個(gè)指標(biāo)被要求壓低，最后的報(bào)告顯然不如原來的好看。自己也沒有深入過壓力測(cè)試，但是覺得不搞明白對(duì)將來機(jī)器配置和擴(kuò)容都會(huì)有影響，因此去問了DBA和SA，得到的結(jié)果相差很大，看來不得不自己去找找問題的根本所在了。
通過下面的幾個(gè)部分的了解，可以一步一步的找出Load Average在壓力測(cè)試中真正的作用。
CPU時(shí)間片
為了提高程序執(zhí)行效率，大家在很多應(yīng)用中都采用了多線程模式，這樣可以將原來的序列化執(zhí)行變?yōu)椴⑿袌?zhí)行，任務(wù)的分解以及并行執(zhí)行能夠極大地提高程序的運(yùn)行效率。但這都是代碼級(jí)別的表現(xiàn)，而硬件是如何支持的呢？那就要靠CPU的時(shí)間片模式來說明這一切。程序的任何指令的執(zhí)行往往都會(huì)要競(jìng)爭(zhēng)CPU這個(gè)最寶貴的資源，不論你的程序分成了多少個(gè)線程去執(zhí)行不同的任務(wù)，他們都必須排隊(duì)等待獲取這個(gè)資源來計(jì)算和處理命令。先看看單CPU的情況。下面兩圖描述了時(shí)間片模式和非時(shí)間片模式下的線程執(zhí)行的情況：
圖 1 非時(shí)間片線程執(zhí)行情況
圖 2 非時(shí)間片線程執(zhí)行情況
在圖一中可以看到，任何線程如果都排隊(duì)等待CPU資源的獲取，那么所謂的多線程就沒有任何實(shí)際意義。圖二中的CPU Manager只是我虛擬的一個(gè)角色，由它來分配和管理CPU的使用狀況，此時(shí)多線程將會(huì)在運(yùn)行過程中都有機(jī)會(huì)得到CPU資源，也真正實(shí)現(xiàn)了在單CPU的情況下實(shí)現(xiàn)多線程并行處理。
多CPU的情況只是單CPU的擴(kuò)展，當(dāng)所有的CPU都滿負(fù)荷運(yùn)作的時(shí)候，就會(huì)對(duì)每一個(gè)CPU采用時(shí)間片的方式來提高效率。
在Linux的內(nèi)核處理過程中，每一個(gè)進(jìn)程默認(rèn)會(huì)有一個(gè)固定的時(shí)間片來執(zhí)行命令（默認(rèn)為1/100秒），這段時(shí)間內(nèi)進(jìn)程被分配到CPU，然后獨(dú)占使用。如果使用完，同時(shí)未到時(shí)間片的規(guī)定時(shí)間，那么就主動(dòng)放棄CPU的占用，如果到時(shí)間片尚未完成工作，那么CPU的使用權(quán)也會(huì)被收回，進(jìn)程將會(huì)被中斷掛起等待下一個(gè)時(shí)間片。
CPU利用率和Load Average的區(qū)別
壓力測(cè)試不僅需要對(duì)業(yè)務(wù)場(chǎng)景的并發(fā)用戶等壓力參數(shù)作模擬，同時(shí)也需要在壓力測(cè)試過程中隨時(shí)關(guān)注機(jī)器的性能情況，來確保壓力測(cè)試的有效性。當(dāng)服務(wù)器長(zhǎng)期處于一種超負(fù)荷的情況下運(yùn)行，所能接收的壓力并不是我們所認(rèn)為的可接受的壓力。就好比項(xiàng)目經(jīng)理在給一個(gè)人估工作量的時(shí)候，每天都讓這個(gè)人工作12個(gè)小時(shí)，那么所制定的項(xiàng)目計(jì)劃就不是一個(gè)合理的計(jì)劃，那個(gè)人遲早會(huì)垮掉，而影響整體的項(xiàng)目進(jìn)度。
CPU利用率在過去常常被我們這些外行認(rèn)為是判斷機(jī)器是否已經(jīng)到了滿負(fù)荷的一個(gè)標(biāo)準(zhǔn)，看到50%-60%的使用率就認(rèn)為機(jī)器就已經(jīng)壓到了臨界了。CPU利用率，顧名思義就是對(duì)于CPU的使用狀況，這是對(duì)一個(gè)時(shí)間段內(nèi)CPU使用狀況的統(tǒng)計(jì)，通過這個(gè)指標(biāo)可以看出在某一個(gè)時(shí)間段內(nèi)CPU被占用的情況，如果被占用時(shí)間很高，那么就需要考慮CPU是否已經(jīng)處于超負(fù)荷運(yùn)作，長(zhǎng)期超負(fù)荷運(yùn)作對(duì)于機(jī)器本身來說是一種損害，因此必須將CPU的利用率控制在一定的比例下，以保證機(jī)器的正常運(yùn)作。
Load Average是CPU的Load，它所包含的信息不是CPU的使用率狀況，而是在一段時(shí)間內(nèi)CPU正在處理以及等待CPU處理的進(jìn)程數(shù)之和的統(tǒng)計(jì)信息，也就是CPU使用隊(duì)列的長(zhǎng)度的統(tǒng)計(jì)信息。為什么要統(tǒng)計(jì)這個(gè)信息，這個(gè)信息的對(duì)于壓力測(cè)試的影響究竟是怎么樣的，那就通過一個(gè)類比來解釋CPU利用率和Load Average的區(qū)別以及對(duì)于壓力測(cè)試的指導(dǎo)意義。
我們將CPU就類比為電話亭，每一個(gè)進(jìn)程都是一個(gè)需要打電話的人。現(xiàn)在一共有4個(gè)電話亭（就好比我們的機(jī)器有4核），有10個(gè)人需要打電話。現(xiàn)在使用電話的規(guī)則是管理員會(huì)按照順序給每一個(gè)人輪流分配1分鐘的使用電話時(shí)間，如果使用者在1分鐘內(nèi)使用完畢，那么可以立刻將電話使用權(quán)返還給管理員，如果到了1分鐘電話使用者還沒有使用完畢，那么需要重新排隊(duì)，等待再次分配使用。
圖 3 電話使用場(chǎng)景
上圖中對(duì)于使用電話的用戶又作了一次分類，1min的代表這些使用者占用電話時(shí)間小于等于1min，2min表示使用者占用電話時(shí)間小于等于2min，以此類推。根據(jù)電話使用規(guī)則，1min的用戶只需要得到一次分配即可完成通話，而其他兩類用戶需要排隊(duì)兩次到三次。
電話的利用率 = sum (active use cpu time)/period
每一個(gè)分配到電話的使用者使用電話時(shí)間的總和去除以統(tǒng)計(jì)的時(shí)間段。這里需要注意的是是使用電話的時(shí)間總和(sum(active use cpu time))，這與占用時(shí)間的總和(sum(occupy cpu time))是有區(qū)別的。（例如一個(gè)用戶得到了一分鐘的使用權(quán)，在10秒鐘內(nèi)打了電話，然后去查詢號(hào)碼本花了20秒鐘，再用剩下的30秒打了另一個(gè)電話，那么占用了電話1分鐘，實(shí)際只是使用了40秒）
電話的Average Load體現(xiàn)的是在某一統(tǒng)計(jì)時(shí)間段內(nèi)，所有使用電話的人加上等待電話分配的人一個(gè)平均統(tǒng)計(jì)。
電話利用率的統(tǒng)計(jì)能夠反映的是電話被使用的情況，當(dāng)電話長(zhǎng)期處于被使用而沒有的到足夠的時(shí)間休息間歇，那么對(duì)于電話硬件來說是一種超負(fù)荷的運(yùn)作，需要調(diào)整使用頻度。而電話Average Load卻從另一個(gè)角度來展現(xiàn)對(duì)于電話使用狀態(tài)的描述，Average Load越高說明對(duì)于電話資源的競(jìng)爭(zhēng)越激烈，電話資源比較短缺。對(duì)于資源的申請(qǐng)和維護(hù)其實(shí)也是需要很大的成本，所以在這種高Average Load的情況下電話資源的長(zhǎng)期“熱競(jìng)爭(zhēng)”也是對(duì)于硬件的一種損害。
低利用率的情況下是否會(huì)有高Load Average的情況產(chǎn)生呢？理解占有時(shí)間和使用時(shí)間就可以知道，當(dāng)分配時(shí)間片以后，是否使用完全取決于使用者，因此完全可能出現(xiàn)低利用率高Load Average的情況。由此來看，僅僅從CPU的使用率來判斷CPU是否處于一種超負(fù)荷的工作狀態(tài)還是不夠的，必須結(jié)合Load Average來全局的看CPU的使用情況和申請(qǐng)情況。
所以回過頭來再看測(cè)試部對(duì)于Load Average的要求，在我們機(jī)器為8個(gè)CPU的情況下，控制在10 Load左右，也就是每一個(gè)CPU正在處理一個(gè)請(qǐng)求，同時(shí)還有2個(gè)在等待處理。看了看網(wǎng)上很多人的介紹一般來說Load簡(jiǎn)單的計(jì)算就是2* CPU個(gè)數(shù)減去1-2左右（這個(gè)只是網(wǎng)上看來的，未必是一個(gè)標(biāo)準(zhǔn)）。
補(bǔ)充幾點(diǎn)：
1．對(duì)于CPU利用率和CPU Load Average的結(jié)果來判斷性能問題。首先低CPU利用率不表明CPU不是瓶頸，競(jìng)爭(zhēng)CPU的隊(duì)列長(zhǎng)期保持較長(zhǎng)也是CPU超負(fù)荷的一種表現(xiàn)。對(duì)于應(yīng)用來說可能會(huì)去花時(shí)間在I/O,Socket等方面，那么可以考慮是否后這些硬件的速度影響了整體的效率。
這里最好的樣板范例就是我在測(cè)試中發(fā)現(xiàn)的一個(gè)現(xiàn)象：SIP當(dāng)前在處理過程中，為了提高處理效率，將控制策略以及計(jì)數(shù)信息都放置在Memcached Cache里面，當(dāng)我將Memcached Cache配置擴(kuò)容一倍以后，CPU的利用率以及Load都有所下降，其實(shí)也就是在處理任務(wù)的過程中，等待Socket的返回對(duì)于CPU的競(jìng)爭(zhēng)也產(chǎn)生了影響。
2．未來多CPU編程的重要性。現(xiàn)在服務(wù)器的CPU都是多CPU了，我們的服務(wù)器處理能力已經(jīng)不再按照摩爾定律來發(fā)展。就我上面提到的電話亭場(chǎng)景來看，對(duì)于三種不同時(shí)間需求的用戶來說，采用不同的分配順序，我們可看到的Load Average就會(huì)有不同。假設(shè)我們統(tǒng)計(jì)Load的時(shí)間段為2分鐘，如果將電話分配的順序按照：1min的用戶，2min的用戶，3min的用戶來分配，那么我們的Load Average將會(huì)最低，采用其他順序?qū)?huì)有不同的結(jié)果。所以未來的多CPU編程可以更好的提高CPU的利用率，讓程序跑的更快。
以上所提到的內(nèi)容未必都是很準(zhǔn)確或者正確，如果有任何的偏差也請(qǐng)大家指出，可以糾正一些不清楚的概念。