kafka集群搭建完成后肿轨，對(duì)集群進(jìn)行壓測(cè)寿冕。這樣的話(huà)，就需要實(shí)時(shí)查看kafka集群機(jī)器的IO情況椒袍。那怎么辦呢驼唱？其實(shí)linux是有一個(gè)命令來(lái)做這個(gè)事兒的。這個(gè)命令就是iostat驹暑。下面將詳細(xì)介紹一下這個(gè)命令玫恳。
- 用途
iostat用于輸出CPU和磁盤(pán)I/O相關(guān)的統(tǒng)計(jì)信息。
如果%iowait的值過(guò)高岗钩，表示硬盤(pán)存在I/O瓶頸
如果%idle值高纽窟，表示CPU較空閑
如果%idle值高但系統(tǒng)響應(yīng)慢時(shí)肖油，可能是CPU等待分配內(nèi)存兼吓，應(yīng)加大內(nèi)存容量。
如果%idle值持續(xù)低于10森枪，表明CPU處理能力相對(duì)較低视搏，系統(tǒng)中最需要解決的資源是CPU。
2县袱、深層理解
iostat數(shù)據(jù)來(lái)自哪里呢浑娜？？式散？其實(shí)這些數(shù)據(jù)來(lái)自/proc/diskstats
指標(biāo)講解可以參照這個(gè)：https://www.kernel.org/doc/Documentation/iostats.txt
我們以紅色方框的這條數(shù)據(jù)為例來(lái)講解：
8：主設(shè)備號(hào)筋遭；
16：從設(shè)備號(hào)
sdb：設(shè)備名
從第4個(gè)數(shù)據(jù)開(kāi)始，是一系列指標(biāo)信息：
974：(rd_ios) 讀操作的次數(shù)
0：(rd_merges)合并讀操作的次數(shù)。如果兩個(gè)讀操作讀取相鄰的數(shù)據(jù)塊漓滔，那么可以被合并成1個(gè)编饺。
686058：(rd_sectors)讀取的扇區(qū)數(shù)量
36129：(rd_ticks)讀操作消耗的時(shí)間（以毫秒為單位）。每個(gè)讀操作從__make_request()開(kāi)始計(jì)時(shí)响驴，到end_that_request_last()為止透且，包括了在隊(duì)列中等待的時(shí)間。
1231707：(wr_ios)寫(xiě)操作的次數(shù)
41463：(wr_merges)合并寫(xiě)操作的次數(shù)
996643025：(wr_sectors)寫(xiě)入的扇區(qū)數(shù)量
3166420811：(wr_ticks)寫(xiě)操作消耗的時(shí)間（以毫秒為單位）
0：(in_flight): 當(dāng)前未完成的I/O數(shù)量豁鲤。在I/O請(qǐng)求進(jìn)入隊(duì)列時(shí)該值加1秽誊，在I/O結(jié)束時(shí)該值減1。 注意：是I/O請(qǐng)求進(jìn)入隊(duì)列時(shí)琳骡，而不是提交給硬盤(pán)設(shè)備時(shí)锅论。
27884188：(io_ticks)該設(shè)備用于處理I/O的自然時(shí)間(wall-clock time)
3166454597：(time_in_queue)對(duì)字段#10(io_ticks)的加權(quán)值
- 參數(shù)講解
1）常用參數(shù)講解
-x：輸出擴(kuò)展信息。
在sdb這塊磁盤(pán)上：
?每秒向磁盤(pán)上寫(xiě)3M【3164.76kb】左右數(shù)據(jù)(wkB/s值)
?每秒有8次IO操作(r/s+w/s)楣号，其中以寫(xiě)操作為主體
?平均每次IO請(qǐng)求等待時(shí)間(await)為2516.95毫秒棍厌，處理時(shí)間為19.14毫秒
?等待處理的IO請(qǐng)求隊(duì)列(avgqu-sz)中，平均有20.51個(gè)請(qǐng)求駐留
-d：僅顯示磁盤(pán)統(tǒng)計(jì)信息竖席，與-c選項(xiàng)互斥
-k：以K為單位顯示每秒的磁盤(pán)請(qǐng)求數(shù),默認(rèn)單位塊
-c：僅顯示CPU統(tǒng)計(jì)信息耘纱，與-d選項(xiàng)互斥
2）其他參數(shù)講解
-m：用“mbytes/秒”代替“塊/秒”顯示統(tǒng)計(jì)信息
-t：顯示終端和CPU的信息
-N：顯示磁盤(pán)陣列(LVM) 信息
-h：可讀性更好的NFS目錄信息統(tǒng)計(jì)
- 實(shí)踐
（1）iostat -d -k 1 10
查看TPS和吞吐量信息(磁盤(pán)讀寫(xiě)速度單位為KB)，每1s刷新 毕荐，刷新10次結(jié)束
指標(biāo)解釋?zhuān)?br>
kB_read/s：每秒從驅(qū)動(dòng)器讀入的數(shù)據(jù)量,單位為K.
kB_wrtn/s：每秒向驅(qū)動(dòng)器寫(xiě)入的數(shù)據(jù)量,單位為K
kB_read：讀入的數(shù)據(jù)總量,單位為K.
kB_wrtn：寫(xiě)入的數(shù)據(jù)總量,單位為K.
rrqm/s：將讀入請(qǐng)求合并后,每秒發(fā)送到設(shè)備的讀入請(qǐng)求數(shù).
wrqm/s：將寫(xiě)入請(qǐng)求合并后,每秒發(fā)送到設(shè)備的寫(xiě)入請(qǐng)求數(shù).
（2）iostat -x -d -k 1 10
查看磁盤(pán)統(tǒng)計(jì)信息及擴(kuò)展信息(磁盤(pán)讀寫(xiě)速度單位為KB)束析，每1s刷新 ，刷新10次結(jié)束
在sdb這塊磁盤(pán)上憎亚，第2s時(shí)：
?每秒向磁盤(pán)上寫(xiě)24M【24064.00kb】左右數(shù)據(jù)(wkB/s值)
?每秒有47次IO操作(r/s+w/s)员寇，全部是寫(xiě)入操作
?平均每次IO請(qǐng)求等待時(shí)間(await)為4100.83ms，處理時(shí)間為21.30ms
?等待處理的IO請(qǐng)求隊(duì)列(avgqu-sz)中第美，平均有90.33個(gè)請(qǐng)求駐留
來(lái)一個(gè)簡(jiǎn)單的計(jì)算：%util = (r/s+w/s) * (svctm/1000)
上圖中：%util =(0+47) * (21.30/1000) = 1.0011
與圖中顯示的結(jié)果是一致的蝶锋。
指標(biāo)解釋?zhuān)?br>
rrqm/s：每秒對(duì)該設(shè)備的讀請(qǐng)求被合并次數(shù)，文件系統(tǒng)會(huì)對(duì)讀取同塊(block)的請(qǐng)求進(jìn)行合并什往；
wrqm/s：每秒對(duì)該設(shè)備的寫(xiě)請(qǐng)求被合并次數(shù)扳缕。
rsec/s：每秒完成的讀次數(shù)；
wsec/：每秒完成的寫(xiě)次數(shù)别威。
rKB/s：每秒讀數(shù)據(jù)量(kB為單位)躯舔；
wKB/s：每秒寫(xiě)數(shù)據(jù)量(kB為單位)；
avgrq-sz：平均每次IO操作的數(shù)據(jù)量(扇區(qū)數(shù)為單位)
avgqu-sz：平均等待處理的IO請(qǐng)求隊(duì)列長(zhǎng)度省古，隊(duì)列長(zhǎng)度越短越好粥庄。
await：每一個(gè)IO請(qǐng)求的處理的平均時(shí)間（單位是微秒毫秒）。這里可以理解為IO的
響應(yīng)時(shí)間豺妓，一般 地系統(tǒng)IO響應(yīng)時(shí)間應(yīng)該低于5ms惜互，如果大于10ms就比較大 了布讹。這個(gè)時(shí)間包括了隊(duì)列時(shí)間和服務(wù)時(shí)間，也就是說(shuō)训堆，一般情況下炒事，await大于svctm，它們的差值越小蔫慧，則說(shuō)明隊(duì)列時(shí)間越短挠乳， 反之差值越大，隊(duì)列時(shí)間越長(zhǎng)姑躲，說(shuō)明系統(tǒng)出了問(wèn)題睡扬。
svctm：表示平均每次設(shè)備I/O操作的服務(wù)時(shí)間（以毫秒為單位）。如果svctm的值與await很接近黍析，表 示幾乎沒(méi)有I/O等待卖怜，磁盤(pán)性能很好，如果await的值遠(yuǎn)高于svctm的值阐枣，則表示I/O隊(duì)列等待太 長(zhǎng)马靠，系統(tǒng)上運(yùn)行的應(yīng)用程序?qū)⒆兟?br>
%util： 在統(tǒng)計(jì)時(shí)間內(nèi)所有處理IO時(shí)間，除以總共統(tǒng)計(jì)時(shí)間蔼两。例如甩鳄，如果統(tǒng)計(jì)間隔1秒，該設(shè)備有0.8 秒在處理IO额划，而0.2秒閑置妙啃，那么該設(shè)備的%util = 0.8/1 = 80%，所以該參數(shù)暗示了設(shè)備的繁 忙程度俊戳。一般地揖赴，如果該參數(shù)是100%表示設(shè)備已經(jīng)接近滿(mǎn)負(fù)荷運(yùn)行了（當(dāng)然如果是多磁盤(pán)，即使%util是100%抑胎，因?yàn)榇疟P(pán)的并發(fā)能力燥滑，所以磁盤(pán)使用未必就到了瓶頸）。
參考博客：
https://www.cnblogs.com/gaoyuechen/p/8075421.html
https://blog.csdn.net/bingtang5/article/details/84611839
https://www.cnblogs.com/ggjucheng/archive/2013/01/13/2858810.html
