說在前面：

在linux作業系統中，我們一般檢視系統的cpu負載情況常用的命令可以是uptime，top，還有vmstat等這些個都是可以有的。每個工具所提供的資訊各不相同，

我這裡要討論的僅說cpu部分。使用uptime命令，可以得到作業系統在過去1分鐘，5分鐘和15分鐘的cpu平均負載值，也就是傳說中的 load average，這個和top命令右上角那個地方顯示出來的東東是想通的，那麼這個load average到底是個什麼樣的東西呢，其實它表示的就是在cpu裡面執行的程序數量，不過這裡的程序和使用命令來檢視到的程序可不太一樣。在一定時間內 cpu所能處理和承載的程序數量是有限的，這個數值與cpu的效能有直接關係，或者說這個數值標誌著cpu的效能高低，反應到實際的計算機使用上來就是更 高效能的cpu可以在同一時間處理更多程序內容，所以說，一般當你去電腦城買個人電腦的時候導購就會問你電腦的大致用途，其實他們這個時候是在幫你計算你 所需要的電腦效能，其中就包括計算cpu的最大負載值，當然他們一般都不會這麼去算，而是根據價格，因為價格高的cpu往往效能就更好，緊接著，他們會問 你大概的預算，其實當了解到你買電腦的用途之後他們自己心裡已經幫你預算好了，如果你的預算高於他們的預算，那麼恭喜那位賣電腦的，他可以多賺點了。所以 買電腦一定要根據實際需求，比如說cpu支援很高的負載，而你在實際使用中卻根本達不到那麼高的負載，那不就成了殺雞用殺豬刀麼。

說到底，cpu在單位時間內所能處理的程序數越高，那它的效能應該就越高。但是關於這個負載，網上資料有很多種說法，有的說是負載不應該超 過cpu的核心數量，有的說不應該超過cpu核心數量的2倍，有的說不應該超過cpu核心數量的3倍，為什麼會有這麼多種說法呢，其實大家都是擔心一個相 同的問題----怕cpu扛不住，這裡超不超過幾倍不要緊，最主要的判斷標準是你的cpu在達到一定程度負載的時候是不是系統和應用程式依然執行良好，也 就是說判斷標準還與實際的應用有關，如果cpu的負載都超了核心數好幾倍但是軟體執行還依然順暢，那這個也是可以有的。這裡就得說說cpu的執行隊列了， 有關執行佇列的狀態引數可以通過vmstat命令來檢視，這裡不多做解釋，它有兩項，一項是run，一項是blocked，也就是vmstat檢視到的最 前面的兩排，run代表正在cpu裡面執行的，blocked代表由於磁碟或其他方面的瓶頸導致他在cpu裡面等待的，這兩個數值其實和使用uptime 或者top命令檢視到的系統負載值是很有關係的，基本上，系統在某個時間的負載值就等同於run的值加上blocked的值，但是這裡直接這樣用加法來表 示也是不對的，系統負載值是一個平均值，可以是小數，而執行佇列的數目是整數。在cpu處於空閒的情況下，run+blocked一般接近0，偶爾蹦出個 1啊2啊的，所以空閒狀態下的負載均值一般都是0.幾。

但是，當系統的負載逐漸升高，也就是說cpu裡執行的東東逐漸變多，那麼反應到負載均值上其數值也會跟著逐漸增大，而且可以是很大很大，完全超出 cpu核心數的好多倍，比如我前幾天用一臺8核機器做測試的時候用top命令檢視到的負載值居然達到了將近600，這已經遠遠超出了cpu可承受的範圍， 那為什麼已經超出了可接受範圍這個負載均值還可以漲到那麼高呢，這是因為在cpu裡，同一時間可以執行的程序數量有限的，也就是說，vmstat檢視到的 run值最大不能超過某個數，但是blocked卻可以繼續變大，因為程序已經blocked掉了，它幾乎佔用不了多少cpu資源，而正在run的就不一 樣了，一個cpu同一時間能run多少完全取決於它的物理效能，所以當你的機器負載不斷升高，你用top命令檢視到的負載值也會不斷升高，而當負載達到一 定高度時，cpu能處理的執行佇列也達到上限，run的值不再增加，這時，blocked的值會繼續增加，理論上，blocked可以一直增加到直到系統 崩潰。

總結：在評估cpu的效能優劣時完全照搬網上說的幾倍幾倍是不準確的，還得你自己動手看看vmstat顯示的run值和blocked值，當出現明 顯較多的blocked的時候，就說明cpu產生了瓶頸。而top命令和uptime命令顯示的負載均值，只能作為判斷系統過去某個時間段的狀態的參照， 與cpu的效能關係不大。

關於CPU，有3個重要的概念：上下文切換（context switchs），執行佇列（Run queue）和使用率（utilization）。

上下文切換：

目前流行的CPU在同一時間內只能執行一個執行緒，超執行緒的處理器可以在同一時間執行多個執行緒（包括多核CPU），Linux核心會把多核的處理器當作多個單獨的CPU來識別。
　一個標準的Linux核心可以支援執行50～50000個程序執行，對於普通的CPU，核心會排程和執行這些程序。每個程序都會分到CPU的時間片來執行，當一個程序用完時間片或者被更高優先順序的程序搶佔後，它會備份到CPU的執行佇列中，同時其他程序在CPU上執行。這個程序切換的過程被稱作上下文切換。過多的上下文切換會造成系統很大的開銷。

[work106 ~]$ vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 4  0 1874084 3341144 296868 16677400 0 0 0 9 0 0 7 1 91 0 0 cs表示上下文切換的數量 

執行佇列

每個CPU都會維持一個執行佇列，理想情況下，排程器會不斷讓佇列中的程序執行。程序不是處在sleep狀態就是run able狀態。如果CPU過載，就會出現排程器跟不上系統的要求，導致可執行的程序會填滿佇列。佇列愈大，程式執行時間就愈長。

[work106 ~]$ uptime
 11:44:52 up 839 days, 19:55, 2 users, load average: 11.11, 10.33, 9.94 "load average" 用來表示執行佇列，用top 命令我們可以看到CPU一分鐘，5分鐘和15分鐘內的執行佇列的大小。這個值越大表明系統負荷越大。 

[work106 ~]$ vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 4  0 1874084 3341144 296868 16677400 0 0 0 9 0 0 7 1 91 0 0 r表示執行佇列的大小，r的參考值是：小於4，佇列大於4時，表明系統的cpu或記憶體可能有問題，如果r經常大於4，且id經常少於40，表示cpu的負荷很重。當佇列變長時，佇列中程序在等待cpu排程執行時所花的時間會變長. id參考值： 大於40，如果r經常大於4，且id經常小於40，表示cpu的負荷很重。 wa 參考值：小於25%，超過25%的wa的值可以表示磁碟子系統可能沒有被正確平衡，也可能是磁碟密集工作負載的結果，系統的磁碟或其它I/o可能有問題，可以通過iostat/SAR –C命令進一步分解分析 

關於時間片和動態優先順序

時間片對於CPU來說是很關鍵的引數，如果時間片太長，就會使系統的互動效能變差，使用者感覺不到並行。如果太短，又會造成系統頻繁的上下文切換，使效能下降。對於IO Bound的系統來講並不需要太長的時間片，因為系統主要是IO操作；而對於CPU Bound的系統來說需要長的時間片以保持cache的有效性。
　　每一個程序啟動的時候系統都會給出一個預設的優先順序，但在執行過程中，系統會根據程序的執行狀況不斷調整優先順序，核心會升高或降低程序的優先順序（每次增加或降低5），判斷標準是根據程序處於sleep狀態的時間。
　　IO Bound程序大部分時間在sleep狀態，所以核心會調高它的優先順序，CPU Bound程序會被核心懲罰降低優先順序。因此，如果一個系統上即執行IO Bound程序，又執行CPU Bound程序，會發現，IO Bound程序的效能不會下降，而CPU Bound程序效能會不斷下降。

經驗總結：

top - 12:00:20 up 839 days, 20:11, 2 users, load average: 10.54, 10.15, 9.87 Tasks: 228 total, 1 running, 227 sleeping, 0 stopped, 0 zombie Cpu(s): 66.0%us, 7.9%sy, 0.0%ni, 25.5%id, 0.5%wa, 0.0%hi, 0.2%si, 0.0%st 

1. 對於每一個CPU來說執行佇列不要超過3，例如，如果是雙核CPU就不要超過6；
2. 如果CPU在滿負荷執行，應該符合下列分佈，
   a) User Time：65%～70%, us過大，說明有使用者程序佔用很多cpu時間，需要進一步的分析其它軟硬體因素。
   b) System Time：30%～35%，sy過大，說明系統管理方面花了很多時間，說明該系統中某個子系統產生了瓶頸，需要進一步分析其它軟硬體因素。
   c) User Time+System Time ,合理值範圍是 60-85%，如果在一個多使用者系統中us+sy時間超過85%，則程序可能要花時間在執行佇列中等待，響應時間和業務吞吐量會受損害
   d) Idle：0%～5%, CPU完全空閒的百分比
3. 對於上下文切換要結合CPU使用率來看，如果CPU使用滿足上述分佈，大量的上下文切換也是可以接受的。
4. 出現cpu計數器不在範圍時，不一定是由於cpu資源不夠，因為其他資源的也會引起，例如記憶體不夠時，cpu會忙記憶體管理的事，表面上可能是cpu的利用為100%