Load與CPU利用率

      這兩個(gè)指標(biāo)是衡量CPU繁忙程度的關(guān)鍵指標(biāo)。load表示當(dāng)前系統(tǒng)正在運(yùn)行和等待運(yùn)行的進(jìn)程隊(duì)列長(zhǎng)度。load越高，表示對(duì)cpu資源競(jìng)爭(zhēng)越激烈，處理器越多，可以支持load越高。 CPU利用率表示一定時(shí)間內(nèi)使用CPU的效率，使用CPU的時(shí)間與占用CPU的時(shí)間的比值。 處理器核數(shù)增加，可以支持的load越高，處理能力越強(qiáng)；而CPU利用率主要與軟件的實(shí)現(xiàn)有關(guān)，具體而言，與軟件實(shí)現(xiàn)的并發(fā)度(開(kāi)啟線程數(shù)目，串行度)有關(guān)。

同步與異步(編程模型)

     同步方式下，阻塞的線程比例會(huì)很高，而阻塞線程不被操作系統(tǒng)調(diào)度，不占有CPU，導(dǎo)致單位時(shí)間內(nèi)，使用CPU降低，因此IO密集型的應(yīng)用，CPU利用率普遍比較低。但是同步和異步的方式本身，不會(huì)對(duì)CPU使用率造成差別，傳統(tǒng)的一線程一請(qǐng)求模式可以通過(guò)增加線程的方式提高CPU的利用率， 并且在線程數(shù)不是太多的情況下比異步方式性能更好，但異步方式的好處在于線程不會(huì)因?yàn)镮O而處于阻塞狀態(tài)（增加阻塞狀態(tài)線程的比例）， 最終能夠用更少的線程達(dá)到高吞吐量，線程過(guò)多會(huì)因?yàn)榫€程間切換和內(nèi)存開(kāi)銷而產(chǎn)生瓶頸。

QPS與RT

QPS：系統(tǒng)每秒處理的請(qǐng)求數(shù)，衡量系統(tǒng)吞吐量的指標(biāo)。

RT：一個(gè)請(qǐng)求的響應(yīng)時(shí)間，也可以是一段時(shí)間的平均值。

     對(duì)于一個(gè)具體的系統(tǒng)而言，自然是希望RT越低越好，QPS越高越好。為了更高的QPS，最簡(jiǎn)單的辦法是增加處理線程數(shù)，提高程序的并發(fā)度。但是線程數(shù)增加到一定程度，會(huì)由于各種原因：上下文開(kāi)銷增大，線程棧占用更多的內(nèi)存，CPU-CACHE的命中率下降導(dǎo)致QPS無(wú)法繼續(xù)上升，而且RT也會(huì)繼續(xù)增加，導(dǎo)致不滿足業(yè)務(wù)需求，因此會(huì)有一個(gè)最佳線程數(shù)概念。

最佳線程數(shù)：剛好消耗完服務(wù)器瓶頸資源的臨界線程數(shù)(得到最大QPS的線程數(shù))

QPS、RT與最佳線程數(shù)關(guān)系

RT = CPU Time + Wait Time

最佳線程數(shù)=((Wait Time + CPU Time)/CPU Time) * CPU cores * CPU利用率

單線程模型：QPS=1000/RT

多線程模型：QPS = 最佳線程數(shù)*1000/RT

                        = (1000/CPU Time)*(CPU cores * CPU利用率)

如何得到最佳線程數(shù)

       通過(guò)逐步添加線程數(shù)，當(dāng)剛好消耗完服務(wù)器的資源時(shí)，則到達(dá)最佳壓測(cè)線程數(shù)，此時(shí)會(huì)有以下特征： 線程數(shù)繼續(xù)遞增，QPS不變，RT變長(zhǎng)，繼續(xù)增加，則QPS開(kāi)始下降，資源瓶頸，可以是CPU，可以是內(nèi)存，也可以是IO或同步鎖。公式是冷冰冰的，但實(shí)際運(yùn)行的系統(tǒng)沒(méi)那么簡(jiǎn)單，否則系統(tǒng)工程師也不必費(fèi)勁去找系統(tǒng)瓶頸去調(diào)優(yōu)了。 隨著線程數(shù)上升，導(dǎo)致上下文開(kāi)銷增大，線程棧占用更多的內(nèi)存，CPU-CACHE的命中率下降， 可能達(dá)到最佳線程數(shù)之前，RT已經(jīng)不符合業(yè)務(wù)的期望，滿足一定RT的QPS才是有意義的。

線程池與QPS

      前面提到，隨著線程數(shù)的遞增，導(dǎo)致上下文開(kāi)銷增大，線程棧占用更多的內(nèi)存，CPU-CACHE的命中率下降，從而影響系統(tǒng)的 整體性能。通過(guò)線程池(一個(gè)線程服務(wù)多個(gè)請(qǐng)求)可以有效地降低線程數(shù)量，緩解上述問(wèn)題。 所以現(xiàn)在無(wú)論是DB服務(wù)器(比如MySQL)，還是應(yīng)用服務(wù)器(比如nginx)，實(shí)質(zhì)都是有線程池的。采用線程池，特別對(duì)于高并發(fā) 場(chǎng)景有很大的意義，線程數(shù)量也可以維持在較低的水平。采用線程池模型，使得較少的線程服務(wù)請(qǐng)求，可以提高CPU利用率， 同時(shí)緩解RT的上升。下圖是mysql啟用線程池與關(guān)閉線程池在純讀和讀寫兩種場(chǎng)景下，系統(tǒng)吞吐量的對(duì)比。

CPU密集型應(yīng)用

    主要消耗在CPU，減少單次請(qǐng)求的CPU使用時(shí)間(比如函數(shù)調(diào)用量變少)，加大并發(fā)度(多線程，充分利用多核)， 單位時(shí)間內(nèi)可以處理更多的請(qǐng)求，可以提升QPS。當(dāng)線程數(shù)加到一定程度時(shí)，大大超過(guò)CPU核數(shù)，導(dǎo)致大量的 上下文切換，增大RT。

IO密集型應(yīng)用

1.這種應(yīng)用比如數(shù)據(jù)庫(kù)，主要時(shí)間消耗在IO，假設(shè)CPU利用率沒(méi)有達(dá)到瓶頸，單位時(shí)間內(nèi)請(qǐng)求數(shù)目一定

(1)減少IO操作(減少讀寫IO次數(shù))，可以減少RT，則QPS基本不變；

(2)減少CPU操作(減少函數(shù)調(diào)用)，可以降低CPU利用率；同時(shí)可以減少RT，但不如減少IO明顯。 

2.在RT滿足應(yīng)用需求的情況下，比如每秒10w次請(qǐng)求，RT是10ms，則QPS就是10w，有意義的QPS一定與RT相關(guān)。理論上，繼續(xù)加 大請(qǐng)求數(shù)，QPS還可以繼續(xù)往上，同時(shí)RT也會(huì)繼續(xù)往上。當(dāng)超過(guò)1s時(shí)，則請(qǐng)求再多，也無(wú)法提升QPS。因?yàn)橐粋€(gè)請(qǐng)求在1s內(nèi)無(wú)法處理完畢。

軟中斷與硬中斷

      中斷是指由于接收到外圍硬件(相對(duì)于CPU與內(nèi)存而言)的異步信號(hào)或者來(lái)自軟件的同步信號(hào)而進(jìn)行相應(yīng)的硬件/軟件處理。硬中斷是指外圍硬件發(fā)給CPU或者內(nèi)存的異步信號(hào)就是硬中斷信號(hào)；而軟中斷是軟件本身發(fā)給操作系統(tǒng)內(nèi)核的信號(hào)，通常由硬中斷處理程序或系統(tǒng)調(diào)用對(duì)操作系統(tǒng)內(nèi)核的中斷。區(qū)別軟中斷和硬中斷的一個(gè)關(guān)鍵點(diǎn)：是否有中斷控制器參與，外設(shè)偵測(cè)到變化，通過(guò)中斷控制器來(lái)中斷CPU，是一種隨機(jī)的行為。軟中斷直接以一個(gè)CPU指令，調(diào)用相應(yīng)的中斷處理程序，是程序可以控制的。一般來(lái)說(shuō)，磁盤IO和網(wǎng)卡IO中斷處理都包含硬中斷和軟中斷兩個(gè)部分，硬中斷處理那些可以短時(shí)間完成的工作，而將需要較長(zhǎng)時(shí)間處理的事情交給軟中斷處理。舉個(gè)栗子，比如網(wǎng)卡中斷，當(dāng)網(wǎng)卡收到一個(gè)數(shù)據(jù)包后，通知操作系統(tǒng)外設(shè)狀態(tài)變化，這時(shí)候就是發(fā)起了一個(gè)硬中斷。操作系統(tǒng)處理中斷，調(diào)用網(wǎng)卡中斷處理程序會(huì)把數(shù)據(jù)復(fù)制到緩沖區(qū)，并設(shè)置一個(gè)標(biāo)記位，然后告訴網(wǎng)卡可以繼續(xù)接收數(shù)據(jù)了。操作系統(tǒng)中斷返回時(shí)，會(huì)檢查標(biāo)記位，若有，則回調(diào)軟中斷的處理函數(shù)。 

網(wǎng)卡吞吐量?jī)?yōu)化

      由于目前CPU都是多核，可以將網(wǎng)卡設(shè)置為多隊(duì)列，提高網(wǎng)卡處理效率。當(dāng)某個(gè)隊(duì)列收到報(bào)文時(shí)，觸發(fā)相應(yīng)的中斷，收到中斷的核，對(duì)其進(jìn)行處理。為了避免不同的核處理同一個(gè)隊(duì)列的報(bào)文引起混亂，將每個(gè)隊(duì)列綁定到唯一的一個(gè)核心上。

參考文檔

http://blog.csdn.net/pxz_002/article/details/7327668

http://www.CUOXin.com/cchust/p/3354570.html

http://iamzhongyong.CUOxin.com/blog/1924745 

http://blog.csdn.net/zhangskd/article/details/21992933