昨天nagios報警warning，沒來得及留下報警截圖，nagios值設定的值是
當1分鐘多於15個進程等待,5分鐘多於10個,15分鐘多於5個則爲warning狀態
當1分鐘多於30個進程等待,5分鐘多於25個,15分鐘多於20個則爲critical狀態
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
MySQL主服務器load average 驟增
雖然沒來得及排查出來最後又下去了，但是在增長的時候沒有最後落實這個錯誤，着實很難過，在網上看許多資料，大部分都是一樣的解釋，轉載的，抄襲的，心中也是錯亂，最終就是一個問題在困擾，這三個數值，是本身內核計算完CPU單核的值，還是未除以CPU核數之前的值，這個問題在許多論壇和博文裏，有不同的說法，但是大部分還是傾向於是除完的，實在無解，半夜求解同學胖偉，騷偉已翻牆，跑到國外技術網站，給了我這麼一段話。
我蹩腳的翻譯過來（不對的地方請多指正）
在多處理器系統上
負載相對於可用的處理器內核的數量是相對的
“100%利用”標誌負載爲1，只是標誌在一個單一的核心繫統
2標誌是在雙核，4是標誌在四核等
因此，有一個 14 load average值和 24個 內核的負載平均，你的服務器是遠離超載的
（一天的心結·······釋然）
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
以下是從不同地方攝取精華並重新整理已方便自己以後查閱
load average
以下命令均可獲取load average系統平均負載
]# top
]# uptime
]# w
]# cat /proc/loadavg
/proc文件系統是一個虛擬的文件系統，不佔用磁盤空間，它反映了當前操作系統在內存中的運行情況，查看/proc下的文件可以瞭解到系統的運行狀態。查看系統平均負載使用“cat /proc/loadavg”命令，輸出結果如下
前三個數字是1、5、15分鐘內的平均進程數。後面的 1/331 一個的分子是正在運行的進程數，分母是進程總數；另一個是最近運行的進程ID號。
top獲取：
系統平均負載被定義爲：在特定時間間隔內運行隊列中(在CPU上運行或者等待運行多少進程)的平均進
程數。
如果一個進程滿足以下條件則其就會位於運行隊列中：
上圖橢圓部分3個數值分別表示系統在過去1分鐘、5分鐘、15分鐘內運行進程隊列中的平均進程數量。
運行隊列嘛，沒有等待IO，沒有WAIT，沒有KILL的進程通通都進這個隊列。
- 它沒有在等待I/O操作的結果
- 它沒有主動進入等待狀態(也就是沒有調用'wait')
- 沒有被停止(例如：等待終止)
我們可以這樣認爲，就是 正在運行的進程 + 準備好等待運行的進程 在特定時間內（1分鐘，5分鐘，10分鐘）的平均進程數
但是具體平均時候分母的值是按秒還是什麼單位運算的？我也搞不清楚，大概就是這樣算出來的值，不影響對系統初步性能瓶頸判斷，此處先略過
在Linux中，進程分爲三種狀態， 一種是阻塞的進程blocked process，
一種是可運行的進程runnable process，
另外就是正在運行的進程running process。當進程阻塞時，進程會等待I/O設備的數據或者系統調用。
進程可運行狀態時，它處在一個運行隊列run queue中，與其他可運行進程爭奪CPU時間。 系統的load是指正在運行running one和準備好運行runnable one的進程的總數。比如現在系統有2個正在運行的進程，3個可運行進程，那麼系統的load就是5，load average就是一定時間內的load數量均值
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
看到一篇文章小汽車的舉例說的很不錯，但是更深層次的我覺得有個打電話的寫的更加詳細，現以小汽車舉例
爲了更好地理解系統負載，我們用交通流量來做類比。
單核CPU可以想象成單車道
比如每個圓圈都是小汽車，第一種是滿負荷但CPU時間片不用排隊等待正好夠用，第二種是%50空閒，第三個是超負荷50%，後面的就有隊列等待了
1.單核CPU， 數字在0.00-1.00之間正常
0.00-1.00 之間的數字表示此時路況非常良好，沒有擁堵，車輛可以毫無阻礙地通過。
1.00 表示道路還算正常，但有可能會惡化並造成擁堵。此時系統已經沒有多餘的資源了，管理員需要進行優化。
1.00以上 表示路況不太好了，如果到達2.00表示有橋上車輛一倍數目的車輛正在等待。這種情況你必須進行檢查了。
2.多核CPU - 多車道 數字/CPU核數 在0.00-1.00之間正常
用雙核舉例，雙核的負載已經比單核提高一倍了，那多核的也是同理。
多核CPU的話，滿負荷狀態的數字爲 "1.00 * CPU核數"，即雙核CPU爲2.00，四核CPU爲4.00。
3、安全的系統平均負載
這裏沒有完全的定論，一般來講70%左右的負載也就是0.7左右應該是沒問題的，要根據實際生產環境中實際需求來進行浮動設定
4、應該看哪一個數字，1分鐘，5分鐘還是15分鐘？
和收過橋費的管理員一樣，你當然希望你的汽車(操作)不會被焦急的等待。所以，理想狀態 下，都
希望負載平均值小於 1.00 。當然不排除部分峯值會超過 1.00，但長此以往保持這 個狀態，就說明會
有問題，這時候你應該會很焦急。
“所以你說的理想負荷爲 1.00 ?”
嗯，這種情況其實並不完全正確。負荷 1.00 說明系統已經沒有剩餘的資源了。在實際情況中 ，有
經驗的系統管理員都會將這條線劃在 0.70：
“需要進行調查法則”： 如果長期你的系統負載在 0.70 上下，那麼你需要在事情變得更糟糕之
前，花些時間瞭解其原因。
“現在就要修復法則”：1.00 。 如果你的服務器系統負載長期徘徊於 1.00，那麼就應該馬上解決
這個問題。否則，你將半夜接到你上司的電話，這可不是件令人愉快的事情。
“凌晨三點半鍛鍊身體法則”：5.00。 如果你的服務器負載超過了 5.00 這個數字，那麼你將失去
你的睡眠，還得在會議中說明這情況發生的原因，總之千萬不要讓它發生。
先脫離下主題，我們來討論下多核心處理器與多處理器的區別。從性能的角度上理解，一臺主 機擁
有多核心的處理器與另臺擁有同樣數目的處理性能基本上可以認爲是相差無幾。當然實際 情況會複雜得
多，不同數量的緩存、處理器的頻率等因素都可能造成性能的差異。
但即便這些因素造成的實際性能稍有不同，其實系統還是以處理器的核心數量計算負載均值 。這使
我們有了兩個新的法則：
“有多少核心即爲有多少負荷”法則： 在多核處理中，你的系統均值不應該高於處理器核心的總數
量。
“核心的核心”法則： 核心分佈在分別幾個單個物理處理中並不重要，其實兩顆四核的處理器 等
於 四個雙核處理器 等於 八個單處理器。所以，它應該有八個處理器內核。
5、怎樣知道我的CPU是幾核呢？
使用以下命令可以直接獲得CPU核心數目
查看物理CPU的個數
#cat /proc/cpuinfo |grep "physical id"|sort |uniq|wc –l
查看邏輯CPU的個數
#cat /proc/cpuinfo |grep "processor"|wc –l
查看CPU是幾核
#cat /proc/cpuinfo |grep "cores"|uniq
查看CPU的主頻
#cat /proc/cpuinfo |grep MHz|uniq
直接獲得CPU核心數 （該命令即可全部算出多少核）
#grep 'model name' /proc/cpuinfo | wc -l
取得CPU核心數目N，觀察後面2個數字，用數字/N，如果得到的值小於0.7即可無憂。
一般來講我們觀察五分鐘或者十五分鐘的平均數值。坦
白講，如果前一分鐘的負載情況是 1.00，那麼仍可以說明認定服務器情況還是正常的。 但是如果十五
分鐘的數值仍然保持在 1.00，那麼就值得注意了要考慮是否這應該增加的處理器數量
了
整理到這裏，想起了一個好文章，大概也講的是CPU利用率和load Average的區別
鏈接爲http://wenku.baidu.com/view/6597f58884254b35eefd34f7.html
寫的很好，爲我們更深層次的理解該指標有一定意義，我摘一些精華部分出來供以後自己學習
CPU利用率和Load Average的區別
CPU利用率在過去常常被我們這些外行認爲是判斷機器是否已經到了滿負荷的一個標準，看到50%-60%的使用率就認爲機器就已經壓到了臨界了。CPU利用率，顧名思義就是對於CPU的使用狀況，這是對一個時間段內CPU使用狀況的統計，通過這個指標可以看出在某一個時間段內CPU被佔用的情況，如果被佔用時間很高，那麼就需要考慮CPU是否已經處於超負荷運作，長期超負荷運作對於機器本身來說是一種損害，因此必須將CPU的利用率控制在一定的比例下，以保證機器的正常運作。
Load Average是CPU的Load，它所包含的信息不是CPU的使用率狀況，而是在一段時間內CPU正在處理以及等待CPU處理的進程數之和的統計信息，也就是CPU使用隊列的長度的統計信息。爲什麼要統計這個信息，這個信息的對於壓力
測試的影響究竟是怎麼樣的，那就通過一個類比來解釋CPU利用率和Load Average的區別以及對於壓力測試的指導意義。
我們將CPU就類比爲電話亭，每一個進程都是一個需要打電話的人。現在一共有4個電話亭（就好比我們的機器有4核），有10個人需要打電話。現在使用電話的規則是管理員會按照順序給每一個人輪流分配1分鐘的使用電話時間，如果使用者在1分鐘內使用完畢，那麼可以立刻將電話使用權返還給管理員，如果到了1分鐘電話使用者還沒有使用完畢，那麼需要重新排隊，等待再次分配使用。
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
在理解了load Average各值得含義之後，我們用top命令來了解系統的整體狀態
#top
1. 12:28爲當前系統運行時間
2. up 系統運行時間爲287天9小時28分鐘
3. user 當前登錄用戶數
4. load average 0.00 0.00 0.00 系統負載，任務隊列不同時間段平均長度，分別爲1分鐘，5分鐘，15分鐘前到現在
5. Tasks 156 total, 當前進程總數
6. 2 running 正在運行的進程數
7 . 154 sleeping 睡眠的進程數
8. 0 stop 停止的進程數
9. 0zombie 殭屍進程數
10 Cpu(s): 0.0%us, 用戶空間佔用CPU百分比
11 0.2%sy, 內核空間佔用CPU百分比
0.0%ni, 用戶進程空間內改變過優先級的進程佔用CPU百分比
99.8%id 空閒CPU
0.0%wa 等待輸入輸出的CPU時間百分比
0.0%hi 硬中斷
0.0%si 軟中斷
0.0%st 實時
備註：(英文解釋)
us: is meaning of "user CPU time" sy: is meaning of "system CPU time" ni: is meaning of" nice CPU time" id: is meaning of "idle" wa: is meaning of "iowait" hi：is meaning of "hardware irq"
si : is meaning of "software irq" st : is meaning of "steal time
12. Mem 32694788k total， (32G) 內存總容量
29566452k used， （28G）使用的物理內存總量
3128336k free， (3G) 空閒內存總量
347952k buffers， (340M) 用做內核緩存的內存量
13.Swap 16416760k total (16G) 交換分區總量
199504k used （195M） 使用的交換分區總量
1621725k free （1.5G） 空閒的交換分區總量
19508208 cached （19G） 緩衝的交換區總量
備註：Linux內存計算方法
多數的linux系統在free命令後會發現free（剩餘）的內存很少，而自己又沒有開過多的程序或服務。linux的內存管理機制與windows的有所不同。具體的機制我們無需知道，我們需要知道的是，linux的內存管理機制的思想包括（不敢說就是）內存利用率最大化。內核會把剩餘的內存申請爲cached，而cached不屬於free範疇。當系統運行時間較久，會發現cached很大，對於有頻繁文件讀寫操作的系統，這種現象會更加明顯。
直觀的看，此時free的內存會非常小，但並不代表可用的內存小，當一個程序需要申請較大的內存時，如果free的內存不夠，內核會把部分cached的內存回收，回收的內存再分配給應用程序。所以對於linux系統，可用於分配的內存不只是free的內存，還包括cached的內存（其實還包括buffers）。即：
可用內存;=free的內存+cached的內存+buffers的內存
所以，真正的內存利用率 = 可用內存 / 總內存（注意此處 可用內存 由上述公式計算而來，其實這個計算結果在free命令回顯中已有，即回顯結果第三行"-/+ buffers/cached"，此行第二個數值即爲加上了buffers和cached之後的內存，即爲上述公式所算的可用內存
我們free一下
方框裏的是真正可用內存，也是上面3個橢圓free+buffers+cached的和
Cache：高速緩存，是位於CPU與主內存間的一種容量較小但速度很高的存儲器。由於CPU的速度遠高於主內存，CPU直接從內存中存取數據要等待一定時間週期，Cache中保存着CPU剛用過或循環使用的一部分數據，當CPU再次使用該部分數據時可從Cache中直接調用,這樣就減少了CPU的等待時間,提高了系統的效率。Cache又分爲一級Cache(L1 Cache)和二級Cache(L2 Cache)，L1 Cache集成在CPU內部，L2 Cache早期一般是焊在主板上,現在也都集成在CPU內部，常見的容量有256KB或512KB L2 Cache。
Buffer：緩衝區，一個用於存儲速度不同步的設備或優先級不同的設備之間傳輸數據的區域。通過緩衝區，可以使進程之間的相互等待變少，從而使從速度慢的設備讀入數據時，速度快的設備的操作進程不發生間斷。
Free中的buffer和cache：（它們都是佔用內存）：
buffer : 作爲buffer cache的內存，是塊設備的讀寫緩衝區
cache: 作爲page cache的內存, 文件系統的cache
如果 cache 的值很大，說明cache住的文件數很多。如果頻繁訪問到的文件都能被cache住，那麼磁盤的讀IO bi會非常小。
cache是高速緩存，用於CPU和內存之間的緩衝；
buffer是I/O緩存，用於內存和硬盤的緩衝
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
PID：進程ID
USER: 真實用戶名稱
PR: 優先級
NI: Nice值，負值表示高優先級，正值表示低優先級
VIRT:進程使用的虛擬內存總量，單位kb VIRT=SWAP+RES
RES:進程使用的、未被換出的物理內存大小，單位kb RES=CODE+DATA
SHR:共享內存大小，單位kb
S:進程狀態 D=不可中斷的睡眠狀態 R=運行 S=睡眠 T=跟蹤/停止 Z=殭屍進程
%CPU 上次更新到現在的CPU時間佔用百分比
%MEM 進程使用的物理內存百分比
TIME+ 進程使用的CPU時間總計，單位1/100秒
COMMAND 命令名/命令行 進程名稱
------------------------------------------------------------------------------------------------------------------以上是查看top顯示的狀態，需要依據來做優化，但是top顯示的是表象，我們可以通過iostat vmstat命令進一步觀察
查看系統負載 vmstat
1.procs
r 列表示運行和等待cpu時間片的進程數，如果長期大於1，說明cpu不足，需要增加cpu（難道load也是來這裏採集的數據？）
b 列表示在等待資源的進程數，比如正在等待I/O、或者內存交換等
2.memory
swpd 切換到內存交換區的內存數量(k表示)。如果swpd的值不爲0，或者比較大，比如超過了100m，只要si、so的
值長期爲0，系統性能還是正常
free 當前的空閒頁面列表中內存數量(k表示)
buff 作爲buffer cache的內存數量，一般對塊設備的讀寫才需要緩衝。
cache: 作爲page cache的內存數量，一般作爲文件系統的cache，如果cache較大，說明用到cache的文件較多，
如果此時IO中bi比較小，說明文件系統效率比較好。
3.swap
si 由內存進入內存交換區數量。
so由內存交換區進入內存數量。
4.io
IO
bi 從塊設備讀入數據的總量（讀磁盤）（每秒kb）。
bo 塊設備寫入數據的總量（寫磁盤）（每秒kb）
這裏我們設置的bi+bo參考值爲1000，如果超過1000，而且wa值較大應該考慮均衡磁盤負載，可以結合iostat輸出
來分析。
5.system
system 顯示採集間隔內發生的中斷數
in 列表示在某一時間間隔中觀測到的每秒設備中斷數。
cs列表示每秒產生的上下文切換次數，如當 cs 比磁盤 I/O 和網絡信息包速率高得多，都應進行進一步調查。
6.cpu
cpu 表示cpu的使用狀態
us 列顯示了用戶方式下所花費 CPU 時間的百分比。us的值比較高時，說明用戶進程消耗的cpu時間多，但是如果
長期大於50%，需要考慮優化用戶的程序。
sy 列顯示了內核進程所花費的cpu時間的百分比。這裏us + sy的參考值爲80%，如果us+sy 大於 80%說明可能存在
CPU不足。
wa 列顯示了IO等待所佔用的CPU時間的百分比。這裏wa的參考值爲30%，如果wa超過30%，說明IO等待嚴重，這
可能是磁盤大量隨機訪問造成的，也可能磁盤或者磁盤訪問控制器的帶寬瓶頸造成的(主要是塊操作)。
id 列顯示了cpu處在空閒狀態的時間百分比
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
iostat 查看磁盤負載iostat
每隔2秒統計一次磁盤IO信息，直到按Ctrl+C終止程序，d選項表示統計磁盤信息， k表示以每秒KB的形式顯
示，t要求打印出時間信息，2 表示每隔 2 秒輸出一次。第一次輸出的磁盤IO負載狀況提供了關於自從系統啓動以
來的統計信息。隨後的每一次輸出則是每個間隔之間的平均IO負載狀況。
iostat -x 1 2 意思是刷屏信息顯示2次，時間間隔爲1秒
1.rrqm/s:每秒進行merge(合併)的讀操作數目
2.wrqm/s: 每秒進行 merge 的寫操作數目。即 delta(wmerge)/s
3.r/s: 每秒完成的讀 I/O 設備次數。即 delta(rio)/s
4.w/s: 每秒完成的寫 I/O 設備次數。即 delta(wio)/s
5.rsec/s: 每秒讀扇區數。即 delta(rsect)/s
6.wsec/s: 每秒寫扇區數。即 delta(wsect)/s
9.avgrq-sz:平均每次設備I/O操作的數據大小 (扇區)。delta(rsect+wsect)/delta(rio+wio)
11avgqu-sz:平均I/O隊列長度。即 delta(aveq)/s/1000 (因爲aveq的單位爲毫秒)。
12.await: 平均每次設備I/O操作的等待時間 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)
13.svctm: 平均每次設備I/O操作的服務時間 (毫秒)。即 delta(use)/delta(rio+wio)
14.%util: 一秒中有百分之多少的時間用於 I/O 操作，或者說一秒中有多少時間 I/O 隊列是非空的。即
delta(use)/s/1000 (因爲use的單位爲毫秒)
如果 %util 接近 100%，說明產生的I/O請求太多，I/O系統已經滿負荷，該磁盤
可能存在瓶頸。
%idle（空閒）小於70% IO壓力就較大了,一般讀取速度有較多的wait.
同時可以結合vmstat 查看查看b參數(等待資源的進程數)和wa參數(IO等待所佔用的CPU時間的百分比,高過30%時
IO壓力高)