問題背景:
在性能測試時，雖然測試出了結果，但是我們並不知道瓶頸是源端，還是目標端。例如我做上傳和下載性能驗證，從Linux服務器上向OSS集群上傳和下載文件，雖然測試出了速率，但是並不知道上傳是否存在瓶頸，瓶頸在Linux服務器上，還是在OSS集群端。所以在上傳時就需要觀察Linux服務器的CPU、內存、IO，同時監控OSS的bucket的帶寬、流量，從而判斷性能的瓶頸。
首先 、用top命令查看
top - 16:15:05 up 6 days, 6:25, 2 users, load average: 1.45, 1.77, 2.14 Tasks: 147 total, 1 running, 146 sleeping, 0 stopped, 0 zombie Cpu(s): 0.2% us, 0.2% sy, 0.0% ni, 86.9% id, 12.6% wa, 0.0% hi, 0.0% si Mem: 4037872k total, 4003648k used, 34224k free, 5512k buffers Swap: 7164948k total, 629192k used, 6535756k free, 3511184k cached
查看12.6% wa ，IO等待所占用的CPU時間的百分比,高過30%時IO壓力高
其次、 用iostat -x 1 10
如果 iostat 沒有，要 yum install sysstat
avg-cpu: %user %nice %sys %iowait %idle 0.00 0.00 0.25 33.46 66.29 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sdb 0.00 1122 17.00 9.00 192.00 9216.00 96.00 4608.00 123.79 137.23 1033.43 13.17 100.10 sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
iostat結果的相關字段說明如下： 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.10 %idle 66.29
如果 %util 接近 100%，說明產生的I/O請求太多，I/O系統已經滿負荷，該磁盤可能存在瓶頸。
idle小於70% IO壓力就較大了,一般讀取速度有較多的wait。