IO/CPU密集型

服務器壓力較大時，如何判斷壓力來源？如何進行優化？什麼是IO密集型？啥是計算密集型？經過這篇瞭解一下架構設計時會遇到的性能分析的基礎知識吧。

基礎知識

首先說明，IO密集 與 計算密集 爲兩個相對概念，這個得從馮·諾依曼計算機結構體系提及。

運算器與控制器 又被稱爲中央處理器，即 CPU ( Center Process Unit )

存儲器又可分爲 內存與外存

CPU, 存儲器, 輸入(I)、輸出(O)設備等接口設備均經過 系統總線 鏈接在一塊兒。

啥是系統總線？大學學習的時候，都會提到這個名詞，彷彿它就是個概念而已，其實，系統總線(Bus)，就能夠粗略地理解爲總線就是主板好了。

在總線上通常有兩個獨立的單元不常在計算機原理中說起到，就是南、北橋芯片（即DIY時常說起的芯片組），具體的內容能夠百科一下。

北橋芯片，離CPU最近，通常都貼有散熱片，也稱爲主橋芯片(Host Bridge)，通常來講，芯片組的命名就是以北橋芯片的名稱來命名的。主要負責總線上的高速設備好比AGP、PCI-e、內存等與CPU的數據高速交換。

南橋芯片，相對北橋芯片，離CPU較遠，通常不會貼散熱片。主要負責中低速外部設備好比USB、PCI、IDE、Sata、網卡等，芯片中集成了中斷控制器、DMA控制器。

因而可知，負責給CPU提供數據的在總線上，還有兩個管家，一個大內總管(北橋)，一個外掌櫃(南橋)。

好的，彎子繞回來，說正題

如何斷定

待完成…

I/O bound (I/O 讀寫密集型) 指的是系統的CPU效能相對硬盤/內存的效能要好不少，此時，系統運做，大部分的情況是 CPU 在等 I/O (硬盤/內存) 的讀/寫，此時 CPU Loading 不高。

CPU bound (CPU 計算密集型) 指的是系統的 硬盤/內存 效能 相對 CPU 的效能 要好不少，此時，系統運做，大部分的情況是 CPU Loading 100%，CPU 要讀/寫 I/O (硬盤/內存)，I/O在很短的時間就能夠完成，而 CPU 還有許多運算要處理，CPU Loading 很高。

 

在多重程序系統中，大部份時間用來作計算、邏輯判斷等CPU動做的程序稱之CPU bound。例如一個計算圓周率至小數點一千位如下的程序，在執行的過程中。絕大部份時間用在三角函數和開根號的計算，即是屬於CPU bound的程序。It is because the performance characteristic of most protocol codec implementations is CPU-bound, which is the same with I/O processor threads.

根據以上分析，能夠認爲一般狀況下，大部分程序針對某個特定的性能metric而言，均可分爲CPU bound 和 I/O bound兩類。CPU bound的程序通常而言CPU佔用率至關高。這多是由於任務自己不太須要訪問I/O設備，也多是由於程序是多線程實現所以屏蔽掉了等待I/O的時間。而I/O bound的程序通常在達到性能極限時，CPU佔用率仍然較低。這多是由於任務自己須要大量I/O操做，而pipeline作得不是很好，沒有充分利用處理器能力。

 

如何優化

話說，網卡、硬盤都由南橋芯片控制，並屬於中、低速設備，因此，在服務器上進行網絡通信、網絡傳輸、磁盤讀寫均受南橋控制，此類即爲IO操做。IO密集型服務/業務便是以網絡請求壓力大、磁盤讀寫頻繁的操做類型，當進行這些IO密集型操做時，CPU的負載相對較低(現代計算機均集成了對硬件訪問控制的操做邏輯，使得CPU從這些操做中解放出來，提升核心資源的利用率)。

計算密集型，能夠理解爲在北橋芯片與CPU之間的通信較高的服務/業務，每每這類操做常見的都是以計算爲主的，而計算又是CPU/GPU的專長，沒據說過哪一個硬盤能夠進行計算(固然，聲卡或硬解壓卡應該屬於例外了，在南橋將媒體的數據流經過總線傳遞給聲卡或是硬解壓卡，而聲卡和硬解壓卡經過燒錄在卡上的解碼器進行硬件級別的編碼處理，最終總處理後的數據流經過卡上的接口傳給輸出設備，好比聲卡傳遞給音箱)。

對於服務器，經過開發的服務或是業務，能夠在項目之初就根據需求來對資源進行預先估算，大體屬於IO密集型仍是計算密集型的業務，並進行項目前期的資源預算等工做的開展，也包括前期的設計和後期的優化。

1. 項目立項過程當中，根據需求對應的資源負載類型，提出對服務資源的需求配置

IO密集型的需求，通常來講，若是是磁盤讀寫頻繁，經過對磁盤進行升級，提升磁盤的響應速度和傳輸效率或經過負載技術，將文件讀寫分散到多臺服務器中；若是是網絡請求負載較高，能夠經過負載均衡技術，水平擴展服務，提升負載能力；或使用代理緩存服務器，下降核心服務的負載壓力。

計算密集型的需求，首先能夠考慮使用計算能力更好的CPU，而後考慮經過消息隊列或其它降維算法，將計算分散的不一樣的計算結點，進行處理。

2. 項目開發時，進行合理的規劃和業務開發

對於IO密集型的需求，在開發過程當中，就要考慮儘量減小IO開銷，對磁盤讀寫頻繁的業務，能夠考慮經過內存緩存將熱數據緩存起來，減小磁盤的請求。

對於計算密集型的需求，在開發過程當中，須要注意計算算法的優化及結果重用，並儘量進行降維處理，好比經過某種算法將原業務需求的計算分散成可拆分的邏輯，並分散計算進行結果求解，最後進行組合(很像如今大數據處理裏的一些模式，能夠參考)，或經過消息隊列將大量的計算請求分發到其它的計算結點上去。

3. 項目上線後，對服務資源調配進得合理的優化

上線後對服務資源須要持續監控並根據業務推廣和實際狀況進行優化處理。

思路上致上也同上述狀況。

總結

待處理的數據離CPU越近，處理越快。

啓動線程數 = [ 任務執行時間 / ( 任務執行時間 - IO等待時間 ) ] x CPU內核數 最佳啓動線程數 和 CPU內核數量 成正比，和IO阻塞時間成反比。 若是CPU計算型任務，那麼線程數最多不超過CPU內核數，由於啓動再多線程，CPU也來不及調度； 相反若是是任務須要等待磁盤操做（即IO密集型），網絡響應，那麼多啓動線程有助於提升任務併發度，提升系統吞吐能力，改善系統性能。

引用參考

參考文檔

• 《 計算機的組成及結構 》
• 《 南北橋芯片的做用 》
• 《 南北橋芯片 》
• 《 南北橋 》
• 《 電腦主板的南北橋芯片，爲何要分南北橋？ 》
• 《 哈佛結構和馮·諾依曼結構的區別 》

擴展閱讀

• 《 馮諾依曼體系和哈佛體系 》
• 《 哈佛&馮諾依曼及其餘區別 》
• 《 人工智能的突破須要顛覆圖靈機嗎？ 》
• 《 圖靈機與現代計算機的關係 》
• 《 一個可以讓你明白圖靈機的例子 》
• 《 圖靈機 》
• 《 數據密集、計算密集、IO密集，hadoop如何應對？ 》
• 《 TPS、併發用戶數、吞吐量關係 》 參考連接: http://ju.outofmemory.cn/entry/214931