dstat -cdlmnpsy --tcp 5 --------->每5秒取值( system：int，csw分別為系統的中斷次數（interrupt）和上下文切換（context switch）hiq，siq分別為硬中斷和軟中斷次數)
(netstat -anlp|grep LIST|grep -v unix|wc -l)
(mii-tool --verbose em2)
(ethtool em2)
(
lspci|grep -i ether
dmesg |grep -i eth
)
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
top -d 1-------------------->每1秒取值，最活躍的進程
vmstat 2 8----------------->每2秒取值，取8次，關注項有：r,us,id,io(bi,bo)
iostat -x 1 5 --------------->每1秒取值，取5次，關注項有：await,%util
sar 1 6 --------------------->每1秒取值，取6次，關注項有： %iowait
dd if=/dev/sdc of=test bs=64k count=4k oflag=dsync------------->
記錄了4096+0 的讀入
記錄了4096+0 的寫出
268435456字節(268 MB)已復制，3.77072 秒，71.2 MB/秒
=================
http://www.wenzizone.cn/?p=416
iostat和iowait[轉]
%iowait並不能反應磁盤瓶頸
iowait實際測量的是cpu時間：
%iowait = (cpu idle time)/(all cpu time)
這個文章說明：高速cpu會造成很高的iowait值，但這並不代表磁盤是系統的瓶頸。唯一能說明磁盤是系統瓶頸的方法，就是很高的read/write時間，一般來說超過20ms，就代表了不太正常的磁盤性能。為什么是20ms呢？一般來說，一次讀寫就是一次尋到+一次旋轉延遲+數據傳輸的時間。由於，現代硬盤數據傳輸就是幾微秒或者幾十微秒的事情，遠遠小於尋道時間2~20ms和旋轉延遲4~8ms，所以只計算這兩個時間就差不多了，也就是15~20ms。只要大於20ms，就必須考慮是否交給磁盤讀寫的次數太多，導致磁盤性能降低了。
作者的文章以AIX系統為例，使用其工具filemon來檢測磁盤每次讀寫平均耗時。在Linux下，可以通過iostat命令還查看磁盤性能。其中的svctm一項，反應了磁盤的負載情況，如果該項大於15ms，並且util%接近100%，那就說明，磁盤現在是整個系統性能的瓶頸了。
來自：http://blog.morebits.org/?p=125
iostat來對linux硬盤IO性能進行了解
轉載自：扶凱: http://www.php-oa.com/2009/02/03/iostat.html
以前一直不太會用這個參數。現在認真研究了一下iostat，因為剛好有台重要的服務器壓力高,所以放上來分析一下.下面這台就是IO有壓力過大的服務器
$iostat -x 1
Linux 2.6.33-fukai (fukai-laptop) _i686_ (2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
5.47 0.50 8.96 48.26 0.00 36.82
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 6.00 273.00 99.00 7.00 2240.00 2240.00 42.26 1.12 10.57 7.96 84.40
sdb 0.00 4.00 0.00 350.00 0.00 2068.00 5.91 0.55 1.58 0.54 18.80
rrqm/s: 每秒進行 merge 的讀操作數目。即 delta(rmerge)/s
wrqm/s: 每秒進行 merge 的寫操作數目。即 delta(wmerge)/s
r/s: 每秒完成的讀 I/O 設備次數。即 delta(rio)/s
w/s: 每秒完成的寫 I/O 設備次數。即 delta(wio)/s
rsec/s: 每秒讀扇區數。即 delta(rsect)/s
wsec/s: 每秒寫扇區數。即 delta(wsect)/s
rkB/s: 每秒讀K字節數。是 rsect/s 的一半，因為每扇區大小為512字節。(需要計算)
wkB/s: 每秒寫K字節數。是 wsect/s 的一半。(需要計算)
avgrq-sz: 平均每次設備I/O操作的數據大小 (扇區)。delta(rsect+wsect)/delta(rio+wio)
avgqu-sz: 平均I/O隊列長度。即 delta(aveq)/s/1000 (因為aveq的單位為毫秒)。
await: 平均每次設備I/O操作的等待時間 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)
svctm: 平均每次設備I/O操作的服務時間 (毫秒)。即 delta(use)/delta(rio+wio)
%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壓力高)
另外 await 的參數也要多和 svctm 來參考。差的過高就一定有 IO 的問題。
avgqu-sz 也是個做 IO 調優時需要注意的地方，這個就是直接每次操作的數據的大小，如果次數多，但數據拿的小的話，其實 IO 也會很小.如果數據拿的大，才IO 的數據會高。也可以通過 avgqu-sz × ( r/s or w/s ) = rsec/s or wsec/s.也就是講，讀定速度是這個來決定的。
另外還可以參考
svctm 一般要小於 await (因為同時等待的請求的等待時間被重復計算了)，svctm 的大小一般和磁盤性能有關，CPU/內存的負荷也會對其有影響，請求過多也會間接導致 svctm 的增加。await 的大小一般取決於服務時間(svctm) 以及 I/O 隊列的長度和 I/O 請求的發出模式。如果 svctm 比較接近 await，說明 I/O 幾乎沒有等待時間；如果 await 遠大於 svctm，說明 I/O 隊列太長，應用得到的響應時間變慢，如果響應時間超過了用戶可以容許的范圍，這時可以考慮更換更快的磁盤，調整內核 elevator 算法，優化應用，或者升級 CPU。
隊列長度(avgqu-sz)也可作為衡量系統 I/O 負荷的指標，但由於 avgqu-sz 是按照單位時間的平均值，所以不能反映瞬間的 I/O 洪水。
別人一個不錯的例子(I/O 系統 vs. 超市排隊)
舉一個例子，我們在超市排隊 checkout 時，怎么決定該去哪個交款台呢? 首當是看排的隊人數，5個人總比20人要快吧? 除了數人頭，我們也常常看看前面人購買的東西多少，如果前面有個采購了一星期食品的大媽，那么可以考慮換個隊排了。還有就是收銀員的速度了，如果碰上了連 錢都點不清楚的新手，那就有的等了。另外，時機也很重要，可能 5 分鍾前還人滿為患的收款台，現在已是人去樓空，這時候交款可是很爽啊，當然，前提是那過去的 5 分鍾里所做的事情比排隊要有意義 (不過我還沒發現什么事情比排隊還無聊的)。
I/O 系統也和超市排隊有很多類似之處:
r/s+w/s 類似於交款人的總數
平均隊列長度(avgqu-sz)類似於單位時間里平均排隊人的個數
平均服務時間(svctm)類似於收銀員的收款速度
平均等待時間(await)類似於平均每人的等待時間
平均I/O數據(avgrq-sz)類似於平均每人所買的東西多少
I/O 操作率 (%util)類似於收款台前有人排隊的時間比例。
我們可以根據這些數據分析出 I/O 請求的模式，以及 I/O 的速度和響應時間。
下面是別人寫的這個參數輸出的分析
# iostat -x 1
avg-cpu: %user %nice %sys %idle
16.24 0.00 4.31 79.44
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/cciss/c0d0 0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
上面的 iostat 輸出表明秒有 28.57 次設備 I/O 操作: 總IO(io)/s = r/s(讀) +w/s(寫) = 1.02+27.55 = 28.57 (次/秒) 其中寫操作占了主體 (w:r = 27:1)。
平均每次設備 I/O 操作只需要 5ms 就可以完成，但每個 I/O 請求卻需要等上 78ms，為什么? 因為發出的 I/O 請求太多 (每秒鍾約 29 個)，假設這些請求是同時發出的，那么平均等待時間可以這樣計算:
平均等待時間 = 單個 I/O 服務時間 * ( 1 + 2 + … + 請求總數-1) / 請求總數
應用到上面的例子: 平均等待時間 = 5ms * (1+2+…+28)/29 = 70ms，和 iostat 給出的78ms 的平均等待時間很接近。這反過來表明 I/O 是同時發起的。
每秒發出的 I/O 請求很多 (約 29 個)，平均隊列卻不長 (只有 2 個 左右)，這表明這 29 個請求的到來並不均勻，大部分時間 I/O 是空閑的。
一秒中有 14.29% 的時間 I/O 隊列中是有請求的，也就是說，85.71% 的時間里 I/O 系統無事可做，所有 29 個 I/O 請求都在142毫秒之內處理掉了。
delta(ruse+wuse)/delta(io) = await = 78.21 => delta(ruse+wuse)/s =78.21 * delta(io)/s = 78.21*28.57 = 2232.8，表明每秒內的I/O請求總共需要等待2232.8ms。所以平均隊列長度應為 2232.8ms/1000ms = 2.23，而 iostat 給出的平均隊列長度 (avgqu-sz) 卻為 22.35，為什么?! 因為 iostat 中有 bug，avgqu-sz 值應為 2.23，而不是 22.35。
什么是inode？
來自：http://www.dbconf.net/inode-related-issues.html
inode是Linux/Unix系文件系統[如ext]中的一個概念，當一個文件系統格式化了以后，他一定會有 inode table 與 data area 兩個區塊。Block 是記錄文件內容數據的地區，而 inode 則是記錄該文件的屬性、及該文件放置在哪一個 Block 之內的信息。而且每個文件至少需要一個inode。
如何查詢一個文件系統的inode使用情況：
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda1 2366400 186064 2180336 8% /
none 63327 1 63326 1% /dev/shm
使用df -i可以看到文件系統的inode總數、使用數、剩余量和使用百分比。
如何查看每個文件系統的inode大小：
[root@gc_server ~]# dumpe2fs -h /dev/sda1|grep node
dumpe2fs 1.35 (28-Feb-2004)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Inode count: 2366400
Free inodes: 2177496
Inodes per group: 16320
Inode blocks per group: 510
First inode: 11
Inode size: 128
Journal inode: 8
First orphan inode: 150509
Journal backup: inode blocks
定義inode大小：
inode大小決定了一個文件系統中的inode總量，在創建文件系統的時候可以指定inode的大小，創建之后不可修改：
mkfs.ext3 -I 128 /dev/sdb5 //自定inode的大小為128byte
inode會引起什么問題：
可能出現磁盤空閑空間充足的情況下，新建文件時提示磁盤空間滿。
inode數量過多由什么引起：
一般是小文件過多，如果一個文件大小比文件系統的塊大小還小，如文件系統的block size為4k，而文件只有2k，則有2k的空間被浪費，也就是blocks per inode ratio過小，從而有可能會出現磁盤空間未滿，而inode數消耗殆盡的情況。
如何規划：
因為inode大小一般而言略大於block大小為宜，所以：
1、 當 block 越小、inodes 越多，可利用空間越多，但是大文件寫入效率較差：適合文件數量多但是文件容量小的系統，例如 BBS 或者新聞群組 news 這方面的服務之系統；
2、 當 block 越大 、 inodes 數越少，大文件寫入效率較佳，但浪費的空間較多：適合文件容量大的系統。
IO調度器
IO調度器的總體目標是希望讓磁頭能夠總是往一個方向移動,移動到底了再往反方向走,這恰恰就是現實生活中的電梯模型,所以IO調度器也被叫做電梯.(elevator)而相應的算法也就被叫做電梯算法.而Linux中IO調度的電梯算法有好幾種,一個叫做as(Anticipatory),一個叫做cfq(Complete Fairness Queueing),一個叫做deadline,還有一個叫做noop(No Operation).具體使用哪種算法我們可以在啟動的時候通過內核參數elevator來指定.
另一方面我們也可以單獨的為某個設備指定它所采用的IO調度算法,這就通過修改在/sys/block/sda/queue/目錄下面的scheduler文件.比如我們可以先看一下我的這塊硬盤:
[root@localhost ~]# cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq]
可以看到我們這里采用的是cfq.
Linux IO調度器相關算法介紹
IO調度器（IO Scheduler）是操作系統用來決定塊設備上IO操作提交順序的方法。存在的目的有兩個，一是提高IO吞吐量，二是降低IO響應時間。然而IO吞吐量和IO響應時間往往是矛盾的，為了盡量平衡這兩者，IO調度器提供了多種調度算法來適應不同的IO請求場景。其中，對數據庫這種隨機讀寫的場景最有利的算法是DEANLINE。接着我們按照從簡單到復雜的順序，迅速掃一下Linux 2.6內核提供的幾種IO調度算法。
1、NOOP
NOOP算法的全寫為No Operation。該算法實現了最最簡單的FIFO隊列，所有IO請求大致按照先來后到的順序進行操作。之所以說“大致”，原因是NOOP在FIFO的基礎上還做了相鄰IO請求的合並，並不是完完全全按照先進先出的規則滿足IO請求。
假設有如下的io請求序列：
100，500，101，10，56，1000
NOOP將會按照如下順序滿足：
100(101)，500，10，56，1000
2、CFQ
CFQ算法的全寫為Completely Fair Queuing。該算法的特點是按照IO請求的地址進行排序，而不是按照先來后到的順序來進行響應。
假設有如下的io請求序列：
100，500，101，10，56，1000
CFQ將會按照如下順序滿足：
100，101，500，1000，10，56
在傳統的SAS盤上，磁盤尋道花去了絕大多數的IO響應時間。CFQ的出發點是對IO地址進行排序，以盡量少的磁盤旋轉次數來滿足盡可能多的IO請求。在CFQ算法下，SAS盤的吞吐量大大提高了。但是相比於NOOP的缺點是，先來的IO請求並不一定能被滿足，可能會出現餓死的情況。
3、DEADLINE
DEADLINE在CFQ的基礎上，解決了IO請求餓死的極端情況。除了CFQ本身具有的IO排序隊列之外，DEADLINE額外分別為讀IO和寫IO提供了FIFO隊列。讀FIFO隊列的最大等待時間為500ms，寫FIFO隊列的最大等待時間為5s。FIFO隊列內的IO請求優先級要比CFQ隊列中的高，，而讀FIFO隊列的優先級又比寫FIFO隊列的優先級高。優先級可以表示如下：
FIFO(Read) > FIFO(Write) > CFQ
4、ANTICIPATORY
CFQ和DEADLINE考慮的焦點在於滿足零散IO請求上。對於連續的IO請求，比如順序讀，並沒有做優化。為了滿足隨機IO和順序IO混合的場景，Linux還支持ANTICIPATORY調度算法。ANTICIPATORY的在DEADLINE的基礎上，為每個讀IO都設置了6ms的等待時間窗口。如果在這6ms內OS收到了相鄰位置的讀IO請求，就可以立即滿足。
IO調度器算法的選擇，既取決於硬件特征，也取決於應用場景。
在傳統的SAS盤上，CFQ、DEADLINE、ANTICIPATORY都是不錯的選擇；對於專屬的數據庫服務器，DEADLINE的吞吐量和響應時間都表現良好。然而在新興的固態硬盤比如SSD、Fusion IO上，最簡單的NOOP反而可能是最好的算法，因為其他三個算法的優化是基於縮短尋道時間的，而固態硬盤沒有所謂的尋道時間且IO響應時間非常短。
查看和修改IO調度器的算法非常簡單。假設我們要對sda進行操作，如下所示：
cat /sys/block/sda/queue/scheduler
echo “cfq” > /sys/block/sda/queue/scheduler
來自：http://www.sar4.com/2011/02/25/iostat%E5%92%8Ciowait.html
=============
http://www.centoscn.com/CentOS/2014/0827/3586.html
http://lhflinux.blog.51cto.com/1961662/518868
執行 dstat 命令的時候，默認他會 收集-cpu-、-disk-、-net-、－paging-、-system-的數據，一秒鍾收集一次。默認輸入 dstat 等於輸入了dstat -cdngy 1或dstat -a 1；
在1024×768的屏幕上正好全部顯示出來
別名 alias dstat='dstat -cdlmnpsy'
http://opsmysql.blog.51cto.com/2238445/1202135
使用說明
1.使用語法
dstat [-afv][options..] [delay [count]]
簡單執行 dstat 命令：
在不帶任務參數的情況它只會collectlcpu、disk、net、paging、system這些數據, 默認是 1s 收集一次. 默認輸入dstat等於輸入了dstat -cdngy 1或dstat-a 1.
2.dstat 使用參數
-c, -cpu 顯示CPU情況
-C 0,3,totalinclude cpu0, cpu3 and total
-d, -disk 顯示磁盤情況
-D total,hdainclude hda and total
-g, -page enable pagestats
-i, -int enableinterrupt stats
-I 5,eth2 includeint5 and interrupt used by eth2
-l, -load enable loadstats
-m, -mem 顯示內存情況
-n, -net 顯示網絡情況
-N eth1,total 可以指定網絡接口
-p, -proc enableprocess stats
-s, -swap 顯示swap情況
-S swap1,total 可以指定多個swap
-t, -time enable timecounter
-y, -sys enablesystem stats
-ipc 報告IPC消息隊列和信號量的使用情況
-lock enable lockstats
-raw enable raw stats
-tcp enable tcp stats
-udp enable udp stats
-unix enable unixstats
-M stat1,stat2 enableexternal stats
-mods stat1,stat2
-a, -all 使用-cdngy 缺省的就是這樣顯示
-f, -full 使用 -C, -D, -I, -N and -S 顯示
-v, -vmstat 使用-pmgdsc -D 顯示
-integer show integervalues
-nocolor disablecolors (implies -noupdate)
-noheaders 只顯示一次表頭以后就不顯示了,使用重定向寫入文件時很有用
-noupdate disableintermediate updates
-output file 寫入到CVS文件中
上面這些參數大多都容易理解，會點英文的同志都能看懂...........................
3. 實例
實例1: dstat sda -D3 5 #在默認顯示內容的基礎上只顯示sda磁盤的信息
這里的 3 5 意思跟vmstat3 5 一樣，意思就是每隔3秒更新一次，總共更新5次，但是這里有個小區別就是初使時要顯示一次，不包括在內！
實例2：dstat-cdlmnpsy #統計顯示CPU,IO,load,memory,network,process,swap,system
實例3 ：date&& dstat -tclmdny 10 #10秒監視一次
實例4：dstat -cdlmnyp-N total -D total 3 5
相關各模塊顯示內容跟top、vmstat、iostat等這些工具的意思相同，如cpu相關的usr代表應用空間也就是應用程序所占用的百分比，注意這里也是百分比，sys表示系統內核空間占用的百分比，idl表示CPU空閑情況,wai表示IO等待數，hiq和sig則顯示服務中斷有關信息。
其它就不再一一說明，都相對簡單！
OK，只簡單介紹到這里，這工具應用起來還算比較簡單，顯示也很直觀。工具的使用還需靠平時多去練習、觀察才能熟能生巧！
參考站點：http://wiki.51osos.com/index.php?title=Dstat&printable=yes
http://dag.wieers.com/home-made/dstat
=====================================
http://10lover10.blog.51cto.com/6266102/1087731
很多服務端開發的同事和新手運維都來和我討論過如何診斷linux系統的性能瓶頸，今天統一說明。
查找瓶頸有一個基本的流程，不外乎借助系統工具來給系統做一個全面的檢查，最后根據結果來確定問題出在哪方面。
基本流程：
1、使用top查看系統的總體運行情況；
Top的輸出結果那些是很有用的信息呢？我已經全部用紅線框起來了，具體如下：
：load average 這行表示系統最近1分鍾，5分鍾，15分鍾的平均負載。那么怎樣的負載才是可以接受的呢？有個簡單的辦法，在top命令中，再按‘1’鍵，會列出系統使用的cpu的數量，以負載的值不要超過cpu數量最合適。
：Tasks 這行反應的是當前系統的任務狀態，主要看running和zombie進程的數量，一個健康的系統zombie（僵死進程）的數量一定是為0的，否則肯定系統已經出不小的問題了。
：Cpu（s）這行反應當前cpu的工作狀態，us表示用戶進程占整個cpu運行時間的百分比，sy表示系統進程的占用時間百分比；id表示cpu當前的空閑時間百分比，wa表示等待時間百分比，這幾個概念是最重要的。下面有個實際的列子會再詳細分析。
：Mem這行反應當前系統內存使用狀況
：Swap 這行就是系統交換分區使用狀態，一個性能優越的系統，交換分區使用量一定是為0的，交換分區只是一種應對在系統內存不足時的一種緊急機制，用到交換分區，說明可以考慮增加內存或者裁減現有內存數據大小了。畢竟交換分區就是硬盤，速度和內存差了太多。
2、看硬盤容量，硬盤容量如果爆滿的話，那么什么詭異的情況都可能出現，這個已經非常危急了，具體的命令：df；
3、看帶寬；這里如果細分的話就復雜了，比如是否有網絡攻擊，封包數量和特征是否異常等，zabbix是其中的佼佼者，這里我們只要看目前的帶寬有沒有接近網卡的上限，命令: dstat -n;
這台機器是千兆網卡，現在最大才跑到2.7mbyte/s *8 ～ 20mbit/s，遠遠沒到，帶寬這個很少有機會用到網卡峰值的80%左右，但是在業務繁忙的時候，這個也是非常重要的監控對象。
4、一個具體的實例。昨天一個新同學說應用很卡，延遲較大。內存還有很多不使用，就如上面top圖顯示那樣，還有接近3G可以使用的內存。我等錄上去看了看，使用vmstat：
可以看到過段時間就會發現有些進程處於阻塞狀態，原因內是因為cpu處於等待的時間變長了，cpu是空閑的很，等着進程進來運算，而進程遲遲沒有到達，這個肯定就是數據在交換分區了，存取太慢導致的卡和延遲，后來關閉了交換分區，並且整理內存之后，一切就正常了。
一個初步的系統性能診斷按照基本流程就幾步，只是開始接觸linux的同學不知道按照一個流程來操作。所以需要多看多動手。當然現在監控軟件很多，可以監控的性能指標也很多。
本文出自 “時乘六龍” 博客，請務必保留此出處http://10lover10.blog.51cto.com/6266102/1087731
===========================
http://www.ha97.com/4512.html
一、前言
很顯然從名字中我們就可以知道vmstat是一個查看虛擬內存（Virtual Memory）使用狀況的工具，但是怎樣通過vmstat來發現系統中的瓶頸呢？在回答這個問題前，還是讓我們回顧一下Linux中關於虛擬內存相關內容。
二、虛擬內存原理
在系統中運行的每個進程都需要使用到內存，但不是每個進程都需要每時每刻使用系統分配的內存空間。當系統運行所需內存超過實際的物理內存，內核會釋放某些進程所占用但未使用的部分或所有物理內存，將這部分資料存儲在磁盤上直到進程下一次調用，並將釋放出的內存提供給有需要的進程使用。
在Linux內存管理中，主要是通過“調頁Paging”和“交換Swapping”來完成上述的內存調度。調頁算法是將內存中最近不常使用的頁面換到磁盤上，把活動頁面保留在內存中供進程使用。交換技術是將整個進程，而不是部分頁面，全部交換到磁盤上。
分頁(Page)寫入磁盤的過程被稱作Page-Out，分頁(Page)從磁盤重新回到內存的過程被稱作Page-In。當內核需要一個分頁時，但發現此分頁不在物理內存中(因為已經被Page-Out了)，此時就發生了分頁錯誤（Page Fault）。
當系統內核發現可運行內存變少時，就會通過Page-Out來釋放一部分物理內存。經管Page-Out不是經常發生，但是如果Page-out頻繁不斷的發生，直到當內核管理分頁的時間超過運行程式的時間時，系統效能會急劇下降。這時的系統已經運行非常慢或進入暫停狀態，這種狀態亦被稱作thrashing(顛簸)。
三、vmstat詳解
1.用法
vmstat [-a] [-n] [-S unit] [delay [ count]]
vmstat [-s] [-n] [-S unit]
vmstat [-m] [-n] [delay [ count]]
vmstat [-d] [-n] [delay [ count]]
vmstat [-p disk partition] [-n] [delay [ count]]
vmstat [-f]
vmstat [-V]
-a：顯示活躍和非活躍內存
-f：顯示從系統啟動至今的fork數量 。
-m：顯示slabinfo
-n：只在開始時顯示一次各字段名稱。
-s：顯示內存相關統計信息及多種系統活動數量。
delay：刷新時間間隔。如果不指定，只顯示一條結果。
count：刷新次數。如果不指定刷新次數，但指定了刷新時間間隔，這時刷新次數為無窮。
-d：顯示磁盤相關統計信息。
-p：顯示指定磁盤分區統計信息
-S：使用指定單位顯示。參數有 k 、K 、m 、M ，分別代表1000、1024、1000000、1048576字節（byte）。默認單位為K（1024 bytes）
-V：顯示vmstat版本信息。
2.使用說明
例子1：每3秒輸出一條結果
字段說明：
Procs（進程）：
r: 運行隊列中進程數量，這個值也可以判斷是否需要增加CPU。（長期大於1）
b: 等待IO的進程數量
Memory（內存）：
swpd: 使用虛擬內存大小
注意：如果swpd的值不為0，但是SI，SO的值長期為0，這種情況不會影響系統性能。
free: 空閑物理內存大小
buff: 用作緩沖的內存大小
cache: 用作緩存的內存大小
注意：如果cache的值大的時候，說明cache處的文件數多，如果頻繁訪問到的文件都能被cache處，那么磁盤的讀IO bi會非常小。
Swap：
si: 每秒從交換區寫到內存的大小，由磁盤調入內存
so: 每秒寫入交換區的內存大小，由內存調入磁盤
注意：內存夠用的時候，這2個值都是0，如果這2個值長期大於0時，系統性能會受到影響，磁盤IO和CPU資源都會被消耗。有些朋友看到空閑內存（free）很少的或接近於0時，就認為內存不夠用了，不能光看這一點，還要結合si和so，如果free很少，但是si和so也很少（大多時候是0），那么不用擔心，系統性能這時不會受到影響的。
IO：（現在的Linux版本塊的大小為1kb）
bi: 每秒讀取的塊數
bo: 每秒寫入的塊數
注意：隨機磁盤讀寫的時候，這2個值越大（如超出1024k)，能看到CPU在IO等待的值也會越大。
系統：
in: 每秒中斷數，包括時鍾中斷。
cs: 每秒上下文切換數。
注意：上面2個值越大，會看到由內核消耗的CPU時間會越大。
CPU（以百分比表示）：
us: 用戶進程執行時間百分比(user time)
注意： us的值比較高時，說明用戶進程消耗的CPU時間多，但是如果長期超50%的使用，那么我們就該考慮優化程序算法或者進行加速。
sy: 內核系統進程執行時間百分比(system time)
注意：sy的值高時，說明系統內核消耗的CPU資源多，這並不是良性表現，我們應該檢查原因。
wa: IO等待時間百分比
注意：wa的值高時，說明IO等待比較嚴重，這可能由於磁盤大量作隨機訪問造成，也有可能磁盤出現瓶頸（塊操作）。
id: 空閑時間百分比
例子2：顯示活躍和非活躍內存
使用-a選項顯示活躍和非活躍內存時，所顯示的內容除增加inact和active外，其他顯示內容與例子1相同。
字段說明：
Memory（內存）：
inact: 非活躍內存大小（當使用-a選項時顯示）
active: 活躍的內存大小（當使用-a選項時顯示）
總結：
目前說來，對於服務器監控有用處的度量主要有：
r（運行隊列）
pi（頁導入）
us（用戶CPU）
sy（系統CPU）
id（空閑）
注意：如果r經常大於4 ，且id經常少於40，表示cpu的負荷很重。如果bi，bo 長期不等於0，表示內存不足。
通過VMSTAT識別CPU瓶頸：
r（運行隊列）展示了正在執行和等待CPU資源的任務個數。當這個值超過了CPU數目，就會出現CPU瓶頸了。
Linux下查看CPU核心數的命令：cat /proc/cpuinfo|grep processor|wc -l
當r值超過了CPU個數，就會出現CPU瓶頸，解決辦法大體幾種：
1. 最簡單的就是增加CPU個數和核數
2. 通過調整任務執行時間，如大任務放到系統不繁忙的情況下進行執行，進爾平衡系統任務
3. 調整已有任務的優先級
通過vmstat識別CPU滿負荷：
首先需要聲明一點的是，vmstat中CPU的度量是百分比的。當us＋sy的值接近100的時候，表示CPU正在接近滿負荷工作。但要注意的是，CPU 滿負荷工作並不能說明什么，Linux總是試圖要CPU盡可能的繁忙，使得任務的吞吐量最大化。唯一能夠確定CPU瓶頸的還是r（運行隊列）的值。
通過vmstat識別RAM瓶頸：
數據庫服務器都只有有限的RAM，出現內存爭用現象是Oracle的常見問題。
首先用free查看RAM的數量：
[oracle@oracle-db02 ~]$ free
total used free shared buffers cached
Mem: 2074924 2071112 3812 0 40616 1598656
-/+ buffers/cache: 431840 1643084
Swap: 3068404 195804 2872600
當內存的需求大於RAM的數量，服務器啟動了虛擬內存機制，通過虛擬內存，可以將RAM段移到SWAP DISK的特殊磁盤段上，這樣會 出現虛擬內存的頁導出和頁導入現象，頁導出並不能說明RAM瓶頸，虛擬內存系統經常會對內存段進行頁導出，但頁導入操作就表明了服務器需要更多的內存了， 頁導入需要從SWAP DISK上將內存段復制回RAM，導致服務器速度變慢。
解決的辦法有幾種：
1. 最簡單的，加大RAM；
2. 改小SGA，使得對RAM需求減少；
3. 減少RAM的需求。（如：減少PGA）
參考文檔，本人做了相關修改和說明：
http://hi.baidu.com/imlidapeng/blog/item/51872329329ab8335243c1c9.html
http://qa.taobao.com/?p=2269
==================================
http://www.ctohome.com/FuWuQi/cf/659.html
vmstat下表io下面的bi表示讀取和bo表示寫入，單位是block（硬盤讀寫的最小單位是扇區，一個扇區是512 bytes。一次硬盤讀寫的數據量不會超過512 bytes，這一次讀寫的數據量就稱為1個block。在大文件的讀寫操作中，基本可以按乘512來根據block計算出讀寫的實際數據量，誤差很小。）cpu下面的wa，這個wa就是wait的縮寫，代表的意思是CPU在等待硬盤讀寫操作的時間，用百分比表示。wait越大則機器io性能就越差。 -------------------------------------------------- 關於bo和bi，到底是讀還是寫，也許你會看到完全相反的2種解釋。這是某些理解錯誤導致的。正確做法，是你自己測試下。首先vmstat 1 1000運行起來，觀察下bo和bi， 然后再開一個ssh窗口，運行 du -sh / 這個命令來讀取輸出各個目錄的大小。這里幾乎沒有寫入操作，然后你看看你的bi或bo是否有變化，對CTOHOME的服務器測試結果，明顯，bi變大，說明bi是讀文件
首先可以通過看硬盤型號，大致判斷硬盤是什么級別的。比如你不能拿企業級的硬盤和 家用PC的普通硬盤比，這樣比是沒有價值的。VPS也是沒有測試的必要，因為VPS的性能取決於整個服務器性能，比如一個低配服務器開5個vps，和一個高配服務器開30個vps，這是沒有對比性的。 獨立服務器檢測硬盤性能如下，通過dd命令和vmstat命令，僅供技術員墨跡：
DD大致檢測： dd if=/dev/zero of=test bs=64k count=4k oflag=dsync
幾個獨立服務器的硬盤dd結果參考（注意，dd只有在服務器完全空閑的情況下對比才有意義。如果一個服務器跑了很多應用，一個服務器空閑，那么對比結果是沒有任何意義的）：
Vendor: ATA Model: WDC WD5000AAKX-0 Rev: 15.0
[root@host640.ctohome.com]# dd if=/dev/zero of=test bs=64k count=4k oflag=dsync
4096+0 records in
4096+0 records out
268435456 bytes (268 MB) copied, 7.05519 seconds, 38.0 MB/s
Vendor: ATA Model: WDC WD2002FYPS-0 Rev: 04.0
[root@host30.ctohome.com]# dd if=/dev/zero of=test bs=64k count=4k oflag=dsync
4096+0 records in
4096+0 records out
268435456 bytes (268 MB) copied, 4.96645 seconds, 54.0 MB/s
Vendor: WDC Model: WD1002FAEX-0 Rev: 05.0 RAID10
[root@host650.ctohome.com]# dd if=/dev/zero of=test bs=64k count=4k oflag=dsync
4096+0 records in
4096+0 records out
268435456 bytes (268 MB) copied, 2.05799 seconds, 130 MB/s
IO wait 參考：
vmstat下表io下面的bi表示讀取和bo表示寫入，單位是block（硬盤讀寫的最小單位是扇區，一個扇區是512 bytes。一次硬盤讀寫的數據量不會超過512 bytes，這一次讀寫的數據量就稱為1個block。在大文件的讀寫操作中，基本可以按乘512來根據block計算出讀寫的實際數據量，誤差很小。）cpu下面的wa，這個wa就是wait的縮寫，代表的意思是CPU在等待硬盤讀寫操作的時間，用百分比表示。wait越大則機器io性能就越差。
[root@host30.ctohome.com]# man vmstat | grep 'block device'
bi: Blocks received from a block device (blocks/s). 讀
bo: Blocks sent to a block device (blocks/s). 寫
CTOHOME提醒：關於bo和bi，到底是讀還是寫，也許你會看到完全相反的2種解釋。這是某些理解錯誤導致的。正確做法，是你自己測試下。首先vmstat 1 1000運行起來，觀察下bo和bi， 然后再開一個ssh窗口，運行 du -sh / 這個命令來讀取輸出各個目錄的大小。這里幾乎沒有寫入操作，然后你看看你的bi或bo是否有變化，對CTOHOME的服務器測試結果，明顯，bi變大，說明bi是讀文件。
vmstat 1 1000
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
5 1 9504 230360 593980 12154304 0 0 24 1316 3170 7063 15 2 83 1 0
3 2 9504 226840 594016 12156884 0 0 180 0 3403 5827 18 3 76 3 0
2 0 9504 238936 594076 12157364 0 0 108 16 3634 2834 17 3 76 4 0
2 0 9504 246568 594084 12157356 0 0 172 0 3315 7355 12 2 84 1 0
3 0 9504 246072 594092 12157400 0 0 12 0 3489 5299 18 2 80 1 0
5 1 9504 246128 594100 12157828 0 0 60 3800 3430 2577 18 3 78 1 0
3 0 9504 243936 594164 12158428 0 0 984 2220 3624 12936 23 3 71 3 0
1 0 9504 249004 594168 12158424 0 0 4 0 3222 2282 12 2 86 0 0
0 0 9504 249192 594208 12158468 0 0 76 2060 3762 5611 9 2 88 1 0
0 0 9504 248256 594216 12158460 0 0 92 0 3471 7062 7 1 90 1 0
3 1 9504 233860 594232 12158880 0 0 144 0 3371 8783 15 2 81 2 0
1 0 9504 232720 594236 12158876 0 0 180 24 3648 19296 33 4 61 3 0
5 0 9504 228440 594260 12159408 0 0 36 0 3589 5185 18 2 79 2 0
4 0 9504 245836 594280 12159824 0 0 264 2820 3743 17055 25 5 67 2 0
2 0 9504 232392 594292 12159816 0 0 92 0 3799 4387 17 3 79 1 0
0 0 9504 248092 594324 12159784 0 0 116 1448 3395 2450 4 2 92 2 0
0 3 9504 241272 594336 12159896 0 0 4 3364 3828 3339 6 1 68 26 0
1 5 9504 245452 594360 12159872 0 0 608 1804 3851 7458 5 2 59 34 0
1 2 9504 246452 594396 12159872 0 0 20 848 3176 3440 1 1 62 36 0
4 2 9504 245352 594488 12160652 0 0 992 1012 3725 9925 16 2 54 28 0
1 0 9504 239124 594504 12161668 0 0 96 4 3283 10042 19 2 77 2 0
0 0 9504 246200 594508 12161664 0 0 0 1716 3707 2144 1 1 98 0 0
1 0 9504 229088 594508 12161664 0 0 16 0 3438 2846 12 3 84 1 0
vmstat 1 1000
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 0 0 217284 116704 397428 0 0 1244 327 80 272 0 0 99 1 0
0 0 0 216424 116716 397416 0 0 8 272 366 1717 0 0 99 0 0
0 0 0 216424 116716 397436 0 0 0 0 310 1590 0 0 100 0 0
0 0 0 216424 116736 397416 0 0 12 420 340 1841 0 0 100 0 0
0 0 0 216424 116744 397436 0 0 4 120 318 1684 0 0 100 0 0
0 0 0 216424 116744 397436 0 0 0 0 302 1612 0 0 100 0 0
0 0 0 216424 116756 397424 0 0 8 96 315 1667 0 0 100 0 0
0 0 0 216424 116756 397424 0 0 0 0 305 1603 0 0 100 0 0
0 0 0 216424 116760 397432 0 0 4 184 323 1738 0 0 100 0 0
0 0 0 216424 116760 397432 0 0 0 168 314 1702 0 0 100 0 0
0 0 0 216432 116764 397432 0 0 4 0 306 1636 0 0 100 0 0
0 0 0 216432 116776 397420 0 0 8 96 314 1634 0 0 100 0 0
.....
http://lihuipeng.blog.51cto.com/3064864/1183732
vmstat參數：
-bo 磁盤寫的數據量大
-us 持續大於50，服務器高峰可以接受
-wa IO等待，持續大於30，說明IO等待嚴重
-id 持續小於50，服務器高峰可以接受
▶ CPU使用率【CPU Utilization】
這可能是最直接的指標了,它表示每個處理器的整體使用率。在IBM System x架構中,如果在持續一段時間里CPU使用率超過80%,就可能預示着CPU出現了瓶頸。
▶ 用戶時間【User Time】
表示用戶進程所花費的CPU百分比,包括Nice時間。在用戶時間值很高的情況下,表明系統正在執行實際的工作。
▶ 系統時間【System Time】
表示內核操作所花費的CPU百分比,包括硬中斷【IRQ】和軟中斷[SoftIRQ]。系統時間值持續很高表明網絡或驅動器堆棧可能存在瓶頸。通常系統只花費很少時間在內核時間上。
▶ 等待【Waiting】
花費在等待I/O操作所需的CPU時間總和,與阻塞【Blocked】值相似,系統不應該花費過多的時間等待I/O操作;否則你應該檢查一下I/O子系統各方面性能。
▶ 空閑時間【Idle time】
表示CPU空閑的百分比。
▶ Nice時間【Nice time】
表示花費在執行re-nicing(改變進程的執行順序和優先級)進程的CPU百分比。
▶ 平均負載【Load average】
平均負載不是百分比,它是下面數值之和的平均值:
– 隊列中等待執行的進程數
– 等待不可中斷任務執行完成的進程數。
也就是TASK_RUNNING和TASK_UNINTERRUPTIBLE之和的平均值。如果請求CPU時間的進程發生阻塞(),平均負載將會上升。相反如果每個進程都可以立即執行不會錯過CPU周期,平均負載就會降低。
▶ 可運行進程【Runable processes】
這個值表示准備執行的進程。這個值在持續一段時間按內應該不會超過物理處理器數量的10倍,否則CPU可能存在瓶頸。
▶ 堵塞【Blocked】
在等待I/O操作完成前,進程是不能繼續執行。進程堵塞可能意味着I/O存在瓶頸。
▶ 上下文交換【Context switch】
系統中進程之間進行交換的數量。上下文交換次數過多與大量的中斷有關,這可能暗示着驅動器或應用程序存在問題。通常是不需要上下文交換的,因為每次只需要刷新CPU緩存,但有些上下文交換是必要的。
▶ 中斷【Interrupts】
中斷數量中包括硬中斷和軟中斷。硬中斷會對系統性能產生非常不利的影響。高中斷值表明軟件存在瓶頸,可能是內核或者驅動。請記住中斷值中也包括CPU始終所導致的中斷。內存的性能指標。
▶ 空閑內存【Free memory】
與其它操作系統相比,不必過分在意空閑內存值。正如1.2.2“虛擬內存管理”所述,Linux內核將大量未使用的內存分配作為文件系統緩存使用,所以在已用內存扣除用於緩沖和緩存的數量得到實際空閑內存。
▶ 交換空間使用【Swap usage】
這個值表示已使用的交換空間數量。正如1.2.2“虛擬內存管理”所述,交換空間的使用只能告訴你Linux在管理內存上是多么有效。要想確定內存是否存在瓶頸,Swap In/Out的數量才以為着用來。如果Swap In/Out長時間保持在每秒鍾超過200到300頁以上可能表示內存存在瓶頸。
▶ 緩沖與緩存【Buffer and cache】
被用來作為文件系統和塊設備的緩存
▶ Slabs
表示內核所使用的內存。注意內核的頁是不能被交換到硬盤上的。
▶ 活動與非活動內存【Active versus inactive memory】
提供關於活動內存的相關信息。非活動內存會作為候選被kswapd交換到硬盤。參見“頁幀回收”網絡的性能指標。
▶ 已收到和已傳送的封包【Packets received and sent】
這個指標能告訴你特定網卡已收到和已發送的封包數量
▶ 已收到和已傳送的字節【Bytes received and sent】
這個值表示特定網卡已收到和已發送的字節數量。
▶ 每秒鍾沖突數【Collisions per second】
這個值提供發生在指定網卡的網絡沖突的數量。持續出現沖突值表示在網絡架構中存在瓶頸而不是服務器。在大多數正確配置網絡中,沖突時非常罕見的,除非網絡架構是由hub組成的。
▶ 丟棄的封包【Packets dropped】
被內核丟棄的封包數,原因可能是防火牆配置問題或缺乏網絡緩沖
▶ Overruns
Overruns表示超出網絡接口緩沖的次數。這個指標可以與丟棄的封包數量配合來確定瓶頸是出自網絡緩沖還是網絡隊列長度。
▶ 錯誤【Errors】
被標示為失敗的幀的數量。這經常是由於網絡不匹配或部分網線損壞引起的。對於銅纜千兆網部分網線損壞會產生嚴重的性能問題。塊設備的性能指標。
▶ IO等待【Iowait】
CPU在等待I/O操作發生所花費的時間。如果這個值持續很高,很可能表示I/O存在瓶頸。
▶ 隊列平均長度【Average queue length】
I/O請求的數量。通常硬盤隊列值在2到3為最佳;過高可能表示硬盤I/O存在瓶頸。
▶ 平均等待時間【Average wait】
I/O請求服務所花費的平均時間。等待時間包括實際I/O操作的時間和在I/O隊列中等待的時間。單位為毫秒ms。
▶ 每秒鍾傳輸的數量【Transfers per second】
表示每秒鍾執行了多少次I/O操作(包括讀取和寫入)。與每秒鍾傳輸字節數【kBytes per second】結合可以幫助確定系統平均傳輸大小。平均傳輸大小通常要與硬盤子系統的條帶大小一致。
▶ 每秒鍾讀寫塊的數量【Blocks read/write per second】
這個指標表示每秒鍾讀寫塊的數量,在2.6內核中塊的大小為1024字節,早期的內核可以有不同的塊大小,從512字節到4KB。
▶ 每秒鍾讀寫字節的數量【Kilobytes per second read/write】
表示塊設備讀寫的實際數據的數量,單位為KB。
=========================
http://blog.163.com/xychenbaihu@yeah/blog/static/13222965520123724410678
linux性能分析及調優__cpu 性能瓶頸調優可調性能參數 、內存性能瓶頸可調性能參數(操作系統設置swap的目的、在寫程序時、如何使自己的內存不被換出swap，常駐物理內存)、磁盤I/O可調性能參數(如何判斷磁盤IO瓶頸，使用iostat -x 1)、網絡可調性能參數
2012-04-07 02:44:10| 分類： Linux高性能開發|舉報|字號 訂閱
計算機中，cpu是最重要的一個子系統，負責所有計算任務；
基於摩爾定律的發展，cpu是發展最快的一個硬件，所以瓶頸很少出現在cpu上；
我們線上環境的cpu都是多核的，並且基於SMP(symmetric multiprocessing)結構的。
通過觀察線上機器cpu使用率會發現，使用率很低很低，不到5%； 說明我們的資源浪費情況多么嚴重啊；(但為什么不能一台機器多部署幾個應用呢，后邊我會解釋）; 我們線上的cpu一個核支持超級線程，也就是一個核上可以並行運行幾個線程）
機器CPU使用情況監控:
1、良好狀態指標
CPU利用率：User Time <= 70%，System Time <= 35%，User Time + System Time <= 70%。
上下文切換： 與CPU利用率相關聯，如果CPU利用率狀態良好，大量的上下文切換也是可以接受的。
可運行隊列： 每個處理器的可運行隊列<=3個線程。
2、監控工具 vmstat
$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
14 0 140 2904316 341912 3952308 0 0 0 460 1106 9593 36 64 1 0 0
17 0 140 2903492 341912 3951780 0 0 0 0 1037 9614 35 65 1 0 0
20 0 140 2902016 341912 3952000 0 0 0 0 1046 9739 35 64 1 0 0
17 0 140 2903904 341912 3951888 0 0 0 76 1044 9879 37 63 0 0 0
16 0 140 2904580 341912 3952108 0 0 0 0 1055 9808 34 65 1 0 0
重要參數：
r， run queue， 可運行隊列的線程數，這些線程都是可運行狀態，只不過CPU暫時不可用；
一般要求小於CPU*3的數量。
cat /proc/stat 可以看到有幾個CPU。
b，被blocked的進程數，正在等待IO請求；
in，interrupts，被處理過的中斷數
cs，context switch，系統上正在做上下文切換的數目
us，用戶占用CPU的百分比
sys，內核和中斷占用CPU的百分比
id，CPU完全空閑的百分比
上例可得：
sy高us低，以及高頻度的上下文切換（cs），說明應用程序進行了大量的系統調用；
這台4核機器的r應該在12個以內，現在r在14個線程以上，此時CPU負荷很重。
一般我們認為，如果是4核機器，r高於8是，應該就是負載很高了。
可調優性能參數:
1、 通過調整進程優先級調整： nice 命令來調整進程優先級別；可調范圍（-20到 19） 如： renice 5 pid
2、 通過調整cpu的親和度來集中處理某一個中斷類型:(比如網卡中斷)
將系統發出的中斷都綁定在一個cpu上，這樣其他cpu繼續執行自己正在執行的線程，不被中斷打擾，從而較少了線程上下文切換時間，增強性能；
注： cpu親和度的概念： 在多核cpu中，linux操作系統搶占式調度系統，按照cpu時間片/中斷/等不斷調度進程給cpu去執行的；
如果在一個時間片調度線程1在cpu1上運行，另外一個時間片調度線程1在cpu2上去運行，這樣會造成線程執行速度慢，性能降低。
為什么呢？
我們知道SMP上多核都是共享L1 ,L2 CPU Cache的。並且各個核的內存空間都是不可共享的，一個線程如果多次時間片上在不同的cpu上運行，會造成cache的不斷失效和寫入，性能會降低；
而linux的進程調度有個親和度算法可以將盡量將進程每次都調度到同一個cpu上處理；
linux調度時當然也有Loadbalance算法保證進程調度的均勻負載的；
例如： echo 03 > /proc/irq/19/smp-affinity (將中斷類型為19的中斷綁定到第三個cpu上處理）
第二節：內存性能瓶頸
首先，linux的內存管理是聰明和智能的；
linux通過（virtual memory manage)來管理內存的； 對於大多數應用，linux是不直接寫到硬盤上去的，而是先寫到 virtual memory manage 管理的文件系統緩存(也在內存中的)里 ,方便應用的后續的讀請求；因為和磁盤的I/O操作是昂貴的；linux會根據一些算法策略適當的時候同步到硬盤的；這就是為什么我們運行linux一段時間后，發現可用內存那么少的原因，多數被cache+buffer占用咧；
所以我們提高性能的辦法就是減少寫到磁盤的次數，提高每次寫磁盤時的效率質量；
機器內存使用情況監控:
1、良好狀態指標
swap in （si） == 0，swap out （so） == 0
應用程序可用內存/系統物理內存 <= 70%
2、監控工具 vmstat
$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 3 252696 2432 268 7148 3604 2368 3608 2372 288 288 0 0 21 78 1
0 2 253484 2216 228 7104 5368 2976 5372 3036 930 519 0 0 0 100 0
0 1 259252 2616 128 6148 19784 18712 19784 18712 3821 1853 0 1 3 95 1
1 2 260008 2188 144 6824 11824 2584 12664 2584 1347 1174 14 0 0 86 0
2 1 262140 2964 128 5852 24912 17304 24952 17304 4737 2341 86 10 0 0 4
重要參數：
swpd， 已使用的 SWAP 空間大小，KB 為單位；
free， 可用的物理內存大小，KB 為單位；
buff， 物理內存用來緩存讀寫操作的buffer大小，KB 為單位；
cache， 物理內存用來緩存進程地址空間的 cache 大小，KB 為單位；
si， 數據從 SWAP 讀取到 RAM（swap in）的大小，KB 為單位；
so， 數據從 RAM 寫到 SWAP（swap out）的大小，KB 為單位。
上例可得：
物理可用內存 free 基本沒什么顯著變化，swapd逐步增加，說明最小可用的內存始終保持在 256MB(物理內存大小) * 10％ = 2.56MB 左右，當臟頁達到10％的時候就開始大量使用swap。
這個10%來自" /proc/sys/vm/dirty_background_ratio "。
可調優性能參數:
1.、通過調節緩存的臟數據同步到硬盤的策略：（臟數據表示沒有被當前的線程使用的數據）
例如： echo 10 > /proc/sys/vm/dirty_background_ratio (當臟數據占據物理內存10%時，觸發pdflush同步到硬盤）：
小心調節，會大幅度的影響性能；
echo 2000 > /proc/sys/vm/dirty_expire_centisecs (當臟數據在物理內存的逗留時間超過2000ms時被同步到硬盤）；
2、通過調節swap參數，來優化linux虛擬內存管理：基於程序的局部性原理，linux通過虛擬內存機制來實現並發運行進程，linux發現物理內存不夠用時，會根據LRU算法將一部分內存swap out到硬盤；當運行被換出的那個線程時，在swap in 到內存里；
例如： echo 10 > /proc/sys/vm/swappiness (值為0表示盡量都用物理內存，值為100表示積極的使用swap分區；）這個參數很重要；小心調節； 一般為60; ##在緊急處理線上問題時，可以緊急使用一下。
更多的參數:
一、操作系統設置swap的目的
程序運行的一個必要條件就是足夠的內存，而內存往往是系統里面比較緊張的一種資源。為了滿足更多程序的要求，操作系統虛擬了一部分內存地址，並將之映射到swap上。對於程序來說，它只知道操作系統給自己分配了內存地址，但並不清楚這些內存地址到底映射到物理內存還是swap。物理內存和swap在功能上是一樣的，只是因為物理存儲元件的不同（內存和磁盤），性能上有很大的差別。操作系統會根據程序使用內存的特點進行換入和換出，盡可能地把物理內存留給最需要它的程序。但是這種調度是按照預先設定的某種規則的，並不能完全符合程序的需要。
一些特殊的程序（比如MySQL）希望自己的數據永遠寄存在物理內存里，以便提供更高的性能。於是操作系統就設置了幾個api，以便為調用者提供“特殊服務”。
二、Linux提供的幾個api
1、mlockall()和munlockall()
這一對函數，可以讓調用者的地址空間常駐物理內存，也可以在需要的時候將此特權取消。mlockall()的flag位可以是MCL_CURRENT和MCL_FUTURE的任意組合，分別代表了“保持已分配的地址空間常駐物理內存”和“保持未來分配的地址空間常駐物理內存”。對於Linux來說，這對函數是非常霸道的，只有root用戶才有權限調用。
2、shmget()和shmat()
這一對函數，可以向操作系統申請使用大頁內存（Large Page）。大頁內存的特點是預分配和永駐物理內存，因為使用了共享內存段的方式，page table有可能會比傳統的小頁分配方式更小。
對於多進程共享內存的程序（比如ORACLE），大頁內存能夠節省很多page table開銷；
而對於MySQL來說，性能和資源開銷都沒有顯著變化，好處就在於減少了內存地址被映射到swap上的可能。至於為什么是減少，而不是完全避免，之后再講解。
3、O_DIRECT和posix_memalign()
以上兩個方法都不會減少內存的使用量，調用者的本意是獲取更高的系統特權，而不是節約系統資源。
O_DIRECT是一種更加理想化的方式，通過避免double buffer，節省了文件系統cache的開銷，最終減少swap的使用率。O_DIRECT是Linux IO調度相關的標志，在open函數里面調用。通過O_DIRECT標志打開的文件，讀寫都不會用到文件系統的cache。
傳統的數據庫（ORACLE、MySQL）基本都有O_DIRECT相關的開關，在提高性能的同時，也減少了內存的使用。至於posix_memalign()，是用來申請對齊的內存地址的。只有用posix_memalign()申請的內存地址，才能用來讀寫O_DIRECT模式下的文件描述符。
4、madvise()和fadvise()
這對函數也是比較溫和的，可以將調用者對數據訪問模式的預期傳遞給Linux，以期得到更好的性能。
我們比較感興趣的是MADV_DONTNEED和FADV_NOREUSE這兩個flag。前者會建議Linux釋放指定的內存區域，而后者會建議文件系統釋放指定文件所占用的cache。
當mysql出現內存導致的性能瓶頸時，可以:
1、/proc/sys/vm/swappiness的內容改成0（臨時），/etc/sysctl.conf上添加vm.swappiness=0（永久）
這個參數決定了Linux是傾向於使用swap，還是傾向於釋放文件系統cache。在內存緊張的情況下，數值越低越傾向於釋放文件系統cache。當然，這個參數只能減少使用swap的概率，並不能避免Linux使用swap。
2、修改MySQL的配置參數innodb_flush_method，開啟O_DIRECT模式。
這種情況下，InnoDB的buffer pool會直接繞過文件系統cache來訪問磁盤，但是redo log依舊會使用文件系統cache。值得注意的是，Redo log是覆寫模式的，即使使用了文件系統的cache，也不會占用太多。
3、添加MySQL的配置參數memlock
這個參數會強迫mysqld進程的地址空間一直被鎖定在物理內存上，對於os來說是非常霸道的一個要求。必須要用root帳號來啟動MySQL才能生效。
4、還有一個比較復雜的方法，指定MySQL使用大頁內存（Large Page）。Linux上的大頁內存是不會被換出物理內存的，和memlock有異曲同工之妙。具體的配置方法可以參考：http://harrison-fisk.blogspot.com/2009/01/enabling-innodb-large-pages-on-linux.html
第三節： 磁盤I/O可調性能參數
linux的子系統VFS(virtural file system)虛擬文件系統；從高層將各種文件系統，以及底層磁盤特性隱藏，對程序員提供：read,write,delete等文件操作；這就是之所以我們可以在linux上mount多種不同格式的文件系統的，而window確不行；
當然基於：虛擬文件系統，文件系統，文件系統驅動程序，硬件特性方面，都能找到性能瓶頸；
1、選擇適合應用的文件系統;
2.、調整進程I/O請求的優先級，分三種級別：1代表 real time ; 2代表best-effort; 3代表idle ;
如：ionice -c1 -p 1113(給進程1113的I/O優先級設置為最高優先級）
3、根據應用類型，適當調整page size 和block size;
4、升級驅動程序；
第四節 ：網絡可調性能參數
對於我們web應用來說，網絡性能調整如此重要，linux的網絡支持是無與倫比的；是作為網絡服務器的首先；對於web服務來說：除了應用的響應速度外，linux網絡管理子系統，網卡，帶寬都可能成為性能瓶頸；
網絡參數可以在/proc/sys/net/ipv4/ 下面的文件中進行配置。
可以查看和設置的參數:
1、查看網卡設置是否全雙工傳輸的： echtool eth0
2.、設置MTU（最大傳輸單元），在帶寬G以上的時候，要考慮將MTU增大，提高傳輸性能；
如： ifconfig eth0 mtu 9000 up
如果數據包的長度大於mtu的長度時，很容易出現丟包情況。
3.、增加網絡數據緩存；傳輸數據時linux是將包先放入緩存，填滿緩存后即發送出去；讀操作類似；
sysctl -w net.ipv4.tcp_rmem="4096 87380 8388608" ：設置tcp讀緩存：最小緩存，初始化時，最大緩存
sysctl -w net.ipv4.tcp_wmem="4096 87380 8388608" ：設置tcp寫緩存：最小緩存，初始化時，最大緩存
由於是先將數據放入緩存再發送，或收取收據，那么當內存緊張或內存不夠用時，網絡丟包就可能出現。
4、禁用window_scaling,並且直接設置window_size;(就像我們經常設置jvm的參數：xms = xmx一樣
sysctl -w net.ipv4.tcp_window_scaling=0
5、設置TCP連接可重用性： 對於TIME_OUT狀態的TCP連接可用於下一個TCP重用，這樣減少了三次握手和創建時間，非常提高性能，尤其對於web server；
如： 開啟可重用tcp功能： sysctl -w net.ipv4.tcp_tw_reuse=1 sysctl -w net.ipv4.tcp_tw_recyle=1
6、禁用掉沒必要的tcp/ip協議功能：比如icmp;broadcast包的接收；
7、linux對於keeplive的tcp連接有一個默認的過期時間；可以減小這個時間，讓沒用的連接釋放掉，畢竟tcp連接數是有限的嘛；
如： sysctl -w net.ipv4.tcp_keepalive_time=1800 （設置過期時間，1800s)
8、設置最大tcp正在連接狀態（還沒ESTABLISHED)隊列長度；避免由於太多的tcp連接過來，導致服務器掛掉；比如DoS攻擊
如：sysctl -w net.ipv4.tcp_max_syn_backlog=4096
9、 綁定tcp類型的中斷到一個cpu上；（讓cpu去親和這個類型中斷，避免頻繁的中斷，影響線程調度性能）
總結： 我們在性能優化一個應用時，首要的是設定優化要達到的目標，然后尋找瓶頸，調整參數，達到優化目的；但是尋找瓶頸時可能是最累的，要從大范圍，通過很多用例，很多測試報告，不斷的縮小范圍，最終確定瓶頸點；以上這些參數只是個認識，系統性能優化中可能用到，但並不是放之四海而皆准的； 有的參數要邊測試，邊調整的；
................
http://4457553.blog.51cto.com/4447553/1297998
服務器宕機原因很多，資源不足、應用、硬件、系統內核bug等，以下一個小例子
服務器宕機了，首先得知道服務器宕機的時間點，然后分析日志查找原因
1.last reboot 此命令可以查看主機起來的時間，不是宕機的時間
reboot system boot 2.4.21-27.ELsmp Mon Sep 16 02:28 (07:02) //這個是主機起來的時間
2.sar -u -f /var/log/sa/sa16 |more 查看歷史cpu情況
01:10:00 AM all 12.18 0.00 3.90 36.97 46.95
01:20:00 AM all 25.21 0.00 2.39 24.43 47.96
01:30:00 AM all 3.72 0.00 4.03 44.92 47.32
01:40:00 AM all 1.65 0.00 2.45 47.59 48.31
01:50:00 AM all 31.85 0.00 2.86 18.03 47.26
02:00:00 AM all 48.40 0.00 2.01 2.46 47.13 //這里才是主機宕機的時間，要看宕機原因看着個時間點的日志
Average: all 10.77 0.00 2.00 14.76 72.47
02:28:07 AM LINUX RESTART
02:30:00 AM CPU %user %nice %system %iowait %idle
02:40:00 AM all 0.44 0.00 1.11 0.90 97.55
02:50:00 AM all 0.94 0.00 1.03 0.36 97.67
Sep 16 02:00:02 ilearndb snmpd[1138]: [smux_accept] accepted fd 11 from 10.0.1.145:46748
Sep 16 02:01:53 ilearndb modprobe: modprobe: Can't locate module eth2
Sep 16 02:01:53 ilearndb last message repeated 3 times
Sep 16 02:05:04 ilearndb snmpd[1138]: [smux_accept] accepted fd 11 from 10.0.1.145:46824 //系統里面看到2:05分還有日志，說明2:00的時候主機hang住了，sar已經取不了數據
在看sar的數據，發現（用到了swap，並且使用率在上升），是內存不足導致的主機hang住了。
# sar -r -f sa16|more
12:00:00 AM kbmemfree kbmemused %memused kbbuffers kbcached kbswpfree kbswpused %swpused kbswpcad
12:10:00 AM 27784 2027668 98.65 14012 1668488 7436568 411176 5.24 70372
12:20:00 AM 22880 2032572 98.89 15292 1673892 7436576 411168 5.24 70536
12:30:01 AM 22068 2033384 98.93 16280 1672976 7436576 411168 5.24 70536
12:40:00 AM 22848 2032604 98.89 17760 1671660 7436576 411168 5.24 70540
12:50:00 AM 23048 2032404 98.88 18744 1670228 7436576 411168 5.24 70580
01:00:00 AM 27328 2028124 98.67 19616 1664684 7436648 411096 5.24 70572
01:10:00 AM 18760 2036692 99.09 8424 1714120 7418172 429572 5.47 28584
01:20:00 AM 18584 2036868 99.10 14596 1731984 7413060 434684 5.54 17520
01:30:00 AM 22208 2033244 98.92 2436 1739972 7421352 426392 5.43 17520
01:40:00 AM 18448 2037004 99.10 3940 1742296 7421444 426300 5.43 17600
01:50:00 AM 17880 2037572 99.13 6480 1727696 7410060 437684 5.58 18028
02:00:00 AM 18124 2037328 99.12 10916 1718740 7408268 439476 5.60 17644
Average: 21663 2033789 98.95 12375 1699728 7425990 421754 5.37 45003
02:28:07 AM LINUX RESTART
02:30:00 AM kbmemfree kbmemused %memused kbbuffers kbcached kbswpfree kbswpused %swpused kbswpcad
02:40:00 AM 1517792 537660 26.16 27452 393360 7847744 0 0.00 0
02:50:00 AM 1337060 718392 34.95 29020 562108 7847744 0 0.00 0
03:00:00 AM 1330228 725224 35.28 30468 563964 7847744 0 0.00 0
03:10:00 AM 1218940 836512 40.70 31964 668272 7847744 0 0.00 0
03:20:00 AM 1218008 837444 40.74 33016 670572 7847744 0 0.00 0
03:30:00 AM 1208612 846840 41.20 34072 673436 7847744 0 0.00 0
03:40:00 AM 1200904 854548 41.57 34212 678896 7847744 0 0.00 0
03:50:00 AM 1201228 854224 41.56 35204 679216 7847744 0 0.00 0
可以考慮給主機增加1G內存。
附：性能瓶頸分析
CPU資源的過度使用，會造成系統中出現大量的等待進程，導致應用程序響應緩慢，而進程的大量增加又會導致系統內存資源的增加，當物理內存耗盡時，系統會使用虛擬內存，而虛擬內存的使用又會造成磁盤IO的增加並加大CPU的開銷。
1、查看cpu是否是瓶頸
可以使用很多工具：topas、vmstat、sar、top（命令的使用網上有很多資料介紹）
目前大部分CPU在同一時間只能運行一個線程，超線程的處理器可以在同一時間處理多個線程，因此可以利用超線程特性提高系統性能。
在linux系統下只有運行SMP內核才能支持超線程，但是安裝的CPu數量越多，從超線程獲得的性能提升越少。
另外linux內核會將多核的處理器當做多個單獨的CPU來識別，例如，兩個4核的CPU會被當成8個單個CPU，從性能角度講，兩個4核的CPU整體性能要比8個單核CPU低25%-30%。
可能出現CPU瓶頸的應用有郵件服務器、動態web服務器等。
CPU物理個數 》cat /proc/cpuinfo |grep "physicalid" |sort |uniq |wc -l
查看cpu幾核 》cat /proc/cpuinfo |grep"cores"|uniq
邏輯cpu個數 》cat /proc/cpuinfo|grep processor|wc –l
CPU型號查看 》dmidecode |grep -B5 -A5 -i cpu
vmstat 虛擬內存統計
例： vmstat 2 3
輸出項的解釋如下：
procs
memory
swap
io
system
CPU
好： user%+sys%<70%
壞： user%+sys%=85%
糟糕： user%+sys%>=90%
2、查看內存是否瓶頸
內存不足時，可以使用工具觀察到頻繁使用虛擬內存，虛擬內存可以緩解物理內存的不足，但是虛擬內存的過多占用會導致應用程序的性能明顯下降。
服務器內存查看 》dmidecode |grep -B5 -A5 -i memory |grep Size
free命令
free是監控linux內存使用的指令。-
free -m
-
total used free shared buffers cached
-
Mem: 48291 33630 14660 0 24 22437
-
-/+ buffers/cache: 11168 37122
-
Swap: 0 0 0
vmstat命令可以查看
好：SwapIn(si) = 0 SwapOut(so) = 0
壞：Per CPU with 10page/s
糟糕：more swap In & swap out
3. 磁盤IO性能
命令 iostat 可得到相應的數值
好：iowait%<20%
壞：iowait% = 35%
糟糕：iowait%>=50%
4.網絡帶寬
查詢QLogic HBA卡 》lspci | grep -i Fibre
user%表示CPU處在用戶模式下的時間百分比
sys%表示CPU處在系統模式下的時間百分比
iowait%表示CPU等待輸入輸出完成時間的百分比
swap in表示虛擬內存的頁導入，從SWAP DISK交換到RAM
swap out表示虛擬內存的頁導出，從RAM交換到SWAP DISK
個人總結：
| 總結論： |
|||||
| 序號 |
檢查點 |
檢查方法 |
判斷依據 |
結果判斷 |
|
| 1 |
系統的Uptime時間 |
uptime |
如果發現系統uptime時間很短，則需要檢查系統是否重啟過 |
||
| 2 |
檢查文件系統的使用率 |
df -h |
對於OS的文件系統，如果發現使用率高於90%就應該再進一步檢查是什么原因引起的文件系統使用率上漲。對於應用系統使用的文件系統，我們重點在於發現有沒有文件系統使用率到達95%以上，若有，把情況報告給相關的人員。 |
||
| 3 |
檢查網絡狀態 |
ping |
網絡連通性檢查 |
||
| ifconfig |
檢查當前處於up狀態的網卡 |
||||
| mii-tool |
link ok 顯示各個網卡所接鏈路的狀況 |
||||
| ethtool eth[n] |
查看指定網卡所接鏈路的狀況 |
||||
| ls -al /etc/resolv.conf |
確保以上文件的權限是other可讀 |
||||
| cat /etc/hosts |
主機名在hosts文件中只應該與機器的物理IP映射，如果出現有機器的浮動IP與主機映射就需要做進一步檢查 |
||||
| netstat –rn |
正常情況下應該只設置了網關，而沒有其它的靜態路由，如果在列表中發現有其它的路由，則需要確認是否正確 |
||||
| view /etc/sysconfig/network-scripts/ifcfg-eth* |
先檢查子網掩碼設置是否正確 |
||||
| 4 |
檢查ntp時間服務器設置 |
ntpq -p |
正常情況下應該有如下輸出信息： |
||
| 5 |
進程狀態 |
ps –ef | grep defunct；ps -ef | wc -l；ps -ef | grep -v root | wc -l |
如果系統中存在大量的僵屍進程則屬於異常的狀態需要檢查處理。如果只是個別進程就不需要處理。 |
||
| 6 |
內存狀態 |
free -m |
檢查內存使用情況 |
||
| 7 |
swap狀態 |
swapon -s |
查看swap使用百分比 |
||
| 8 |
檢查機器性能 |
vmstat |
CPU：如果cpu的id字段長時間<10，該機器的CPU負載比較高 |
||
| 9 |
檢查磁盤性能 |
iostat |
檢查iowait 時長是否過大？ |
||
| 10 |
檢查系統日志 |
view /var/log/messages |
可以通過檢索error,fail,warn等字眼加快檢查的速度 |
||
| 11 |
收集系統日志 |
sosreport -a --batch |
收集系統日志 |
||
| 12 |
收集硬件日志 |
DSET |
Dell PC Server ：用DSET 工具收集硬件日志 |
||
http://www.cnblogs.com/me115/p/3643778.html
尋找Linux單機負載瓶頸
服務器性能上不去，是哪里出了問題?IO還是CPU？只有找到瓶頸點，才能對症下葯；
如何尋找Linux單機負載瓶頸，遵循的原則是不要推測，我們要通過測量的數據說話；
負載分兩類：
1.CPU負載；
2.IO負載；
排查流程
1.查看平均負載（top/uptime命令）
2.確認CPU、IO有無瓶頸；（使用 sar vmstat）
3.CPU負載過高時尋找流程：
4.IO負載過高時尋找流程；
查看平均負載
先通過top命令查看服務器是否出現負載過重的狀況，之后，再具體使用工具來分析出是CPU負載過高還是IO負載過高；
比如，使用sar工具查看CPU使用率和IO等待率（sar的具體使用教程參考大CC的這篇文章：
http://blog.me115.com/2013/12/468
top的結果：
load average：0.7, 0.66,0.59
平均負載分別表明從左到右1分鍾、5分鍾、15分鍾內，單位時間內處於等待狀態的任務數；
（等待 的意思 表明在等待cpu、或者等待IO）
CPU負載過高時的尋找流程
使用top、sar確認目標程序；
再通過ps查看進程狀態和CPU使用時間等；
進一步尋找：通過strace 或 oprofile命令；
IO負載過高的尋找流程
IO負載過高，多半是程序發出的IO請求過多導致負載過高，或是發生頁面交互導致頻繁訪問磁盤；
應通過sar或vmstat確認交換區狀態，以找出原因；
如果是發生頁面交互的情況，通過以下步驟調查：
1.使用ps工具確認是否有進程消耗了大量內存；
2.如果由於程序故障造成內存消息過大，應改進程序；
3.內存不足則增加內存；
如果沒有交換發生，而且磁盤IO頻繁，可能是用於緩存的內存不足；
1.考慮擴大緩存，增加內存；
2.考慮分散存儲
Posted by: 大CC | 04APR,2014
博客：blog.me115.com
微博：新浪微博
作為一個 Linux 系統管理員，統計各類 IO 是一項必不可少的工作。其統計工具中 iostat 顯然又是最重要的一個統計手段。但是這里 iostat 不是本文的重點，因為這個工具的使用在網絡上已經有大量的教程，可以供大家參考。這里主要是想介紹一些其他統計工具以來滿足不同的需求。
iostat
iostat 的功能異常強大，輸出項也特別多，比如下面這個例子：
1
2 3 |
|
其各項的含義分別是：
- rrqm/s: 每秒進行 merge 的讀操作數目.即 delta(rmerge)/s
- wrqm/s: 每秒進行 merge 的寫操作數目.即 delta(wmerge)/s
- r/s: 每秒完成的讀 I/O 設備次數.即 delta(rio)/s
- w/s: 每秒完成的寫 I/O 設備次數.即 delta(wio)/s
- rsec/s: 每秒讀扇區數.即 delta(rsect)/s
- wsec/s: 每秒寫扇區數.即 delta(wsect)/s
- rkB/s: 每秒讀 K 字節數.是 rsect/s 的一半,因為每扇區大小為 512 字節.(需要計算)
- wkB/s: 每秒寫 K 字節數.是 wsect/s 的一半.(需要計算)
- avgrq-sz: 平均每次設備 I/O 操作的數據大小 (扇區).delta(rsect+wsect)/delta(rio+wio)
- avgqu-sz: 平均 I/O 隊列長度.即 delta(aveq)/s/1000 (因為 aveq 的單位為毫秒).
- await: 平均每次設備 I/O 操作的等待時間 (毫秒).即 delta(ruse+wuse)/delta(rio+wio)
- svctm: 平均每次設備 I/O 操作的服務時間 (毫秒).即 delta(use)/delta(rio+wio)
- %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 壓力高)
另外 await 的參數也要多和 svctm 來參考。差的過高就一定有 IO 的問題.
avgrq-sz 也是個做 IO 調優時需要注意的地方,這個就是直接每次操作的數據的大小,如果次數多,但數據拿的小的話,其實 IO 也會很小.如果數據拿的大,才 IO 的數據會高.也可以通過 avgqu-sz × ( r/s or w/s ) = rsec/s or wsec/s.也就是講,讀定速度是這個來決定的.
svctm 一般要小於 await (因為同時等待的請求的等待時間被重復計算了),svctm 的大小一般和磁盤性能有關,CPU/內存的負荷也會對其有影響,請求過多也會間接導致 svctm 的增加.await 的大小一般取決於服務時間(svctm) 以及 I/O 隊列的長度和 I/O 請求的發出模式.如果 svctm 比較接近 await,說明 I/O 幾乎沒有等待時間；如果 await 遠大於 svctm,說明 I/O 隊列太長,應用得到的響應時間變慢,如果響應時間超過了用戶可以容許的范圍,這時可以考慮更換更快的磁盤,調整內核 elevator 算法,優化應用,或者升級 CPU.
隊列長度(avgqu-sz)也可作為衡量系統 I/O 負荷的指標,但由於 avgqu-sz 是按照單位時間的平均值,所以不能反映瞬間的 I/O 洪水.
有時間的話，我會單獨寫幾個帖子來說說iostat。
iodump
iodump 是一個統計每一個進程(線程)所消耗的磁盤 I/O 工具。這個一個 perl 腳本，其原理時打開有關 I/O 的內核記錄消息開關，而后讀取消息然后分析輸出。簡單使用步驟如下：
首先下載這個工具
wget http://aspersa.googlecode.com/svn/trunk/iodump
然后打開有關 I/O 內核消息的開關
echo 1 >/proc/sys/vm/block_dump
上述開關打開后，內核會記錄下每一個 I/O 操作的消息。我們只需要定時獲取並分析就好了，比如下面這樣
while true; do sleep 1; dmesg -c ; done |perl iodump
等待一段時間，然后通過ctrl+c來結束上述腳本，你將獲得下面類似的信息:
1
2 3 4 5 6 7 |
|
上述輸出的單位為塊(block)，每塊的大小取決於創建文件系統時指定的塊大小。比如我這個里的 sda7 的 block 大小是 1KB。
iotop
iotop 是一個 Python 編寫的工具，有類似top工具的 UI，包括一些參數也和top類似。不過它對系統有一些要求，分別是：
- Python ≥ 2.5 or Python ≥ 2.4 with the ctypes module
- Kernel ≥ 2.6.20
- Kernel uses options:
- TASK_DELAY_ACCT
- CONFIG_TASKSTATS
- TASK_IO_ACCOUNTING
- CONFIG_VM_EVENT_COUNTERS
如果是基於 RPM 包的系統，可以直接下載編譯好的二進制包(here)或者二進制源代碼包(here)
如果是 Debian/Ubuntu 系統，直接使用
sudo apt-get install iotop
即可（不得不說，Debian 系統提供的軟件真的是相當豐富呀)，其他系統則可以通過下面的指令下載源代碼，然后編譯
git clone git://repo.or.cz/iotop.git
具體的使用方法可以參考 iotop(8)手冊，下面是在我機器上的一個顯示：
1
2 3 4 5 6 |
|
iopp
iopp 是另外一個統計每一個進程 I/O 的工具，使用 C 語言編寫，理論上應該比上述兩個重狙效率都要高。安裝方法很簡單，首先通過下面的指令下載源代碼:
git://github.com/markwkm/iopp.git
然后分別通過下面的指令編譯安裝
1
2 3 |
|
下面是一個使用例子
1
2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
上述輸出的各項含義是：
- pid 進程 ID
- rchar 將要從磁盤讀取的字節數
- wchar 已經寫入或應該要寫入磁盤的字節數
- syscr 讀 I/O 數
- syscw 寫 I/O 數
- rbytes 真正從磁盤讀取的字節數
- wbytes 真正寫入到磁盤的字節數
- cwbytes 因為清空頁面緩存而導致沒有發生操作的字節數
- command 執行的命令
其中rbytes,wbytes,cwbytes會因給出-k或者-m參數，而顯示為rkb,wkb,cwkb或rmb,wmb,cwmb。command一列如果給出-c的參數則顯示完整的命令名而不僅僅只是命令本身。這些參數的使用和top類似。
更具體的可以參考 iopp(8)手冊。
dstat
dstat 號稱各種資源統計工具，其目的是想替代vmstat,iostat,netstat,ifstat等各種單一統計工具，從而做到All in one。 dstat 用 Python 語言編寫。
dstat 能夠清晰顯示每列的信息，特別是單位及大小很明確，不會在單位換算上犯迷糊和失誤。最重要的是，因為它是基於模塊化設計，因此我們可以很容易的寫一個插件來收集我們需要的統計信息。
另外，dstat 的輸出還可以導出為CSV格式文件，從而可以在電子表格工具里分方便的生成統計圖形。
目前 dstat 的插件已經相當多了，這是我機器上目前的輸出:
1
2 3 4 5 6 7 8 9 10 11 12 |
|
下面給出幾個使用的列子（實際輸出是帶彩色的，很容易識別）
dstat 的缺省輸出
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
指定需要顯示的列
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
指定需要顯示的列，並同時將結果導出到文件
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
更詳細的用法，可以參考 dstat(1)手冊