作者：維子 https://segmentfault.com/a/1190000021388785?utm_source=tag_newest
IO 性能對於一個系統的影響是至關重要的。一個系統經過多項優化以后，瓶頸往往落在數據庫；而數據庫經過多種優化以后，瓶頸最終會落到 IO 。而 IO 性能的發展，明顯落后於 CPU 的發展。 Memchached 也好， NoSql 也好，這些流行技術的背后都在直接或者間接地回避 IO 瓶頸，從而提高系統性能。
一、IO 系統的分層
上圖層次比較多，但總的就是三部分。磁盤 （存儲）、 VM （卷管理）和文件系統 。專有名詞不好理解，打個比方說：磁盤就相當於一塊待用的空地； LVM 相當於空地上的圍牆（把空地划分成多個部分）；文件系統則相當於每塊空地上建的樓房（決定了有多少房間、房屋編號如何，能容納多少人住）；而房子里面住的人，則相當於系統里面存的數據。
1.1 文件系統 — 數據如何存放？
對應了上圖的 File System 和 Buffer Cache 。
File System （文件系統）：解決了空間管理的問題 ，即：數據如何存放、讀取。
Buffer Cache ：解決數據緩沖的問題。對讀，進行 cache ，即：緩存經常要用到的數據；對寫，進行buffer ，緩沖一定數據以后，一次性進行寫入。
1.2 VM 磁盤空間不足了怎么辦？
對應上圖的 Vol Mgmt 。
VM 其實跟 IO 沒有必然聯系。他是處於文件系統和磁盤（存儲）中間的一層。 VM 屏蔽了底層磁盤對上層文件系統的影響 。當沒有 VM 的時候，文件系統直接使用存儲上的地址空間，因此文件系統直接受限於物理硬盤，這時如果發生磁盤空間不足的情況，對應用而言將是一場噩夢，不得不新增硬盤，然后重新進行數據復制。而 VM 則可以實現動態擴展，而對文件系統沒有影響。另外， VM 也可以把多個磁盤合並成一個磁盤，對文件系統呈現統一的地址空間，這個特性的殺傷力不言而喻。
1.3 存儲 — 數據放在哪兒？如何訪問？如何提高IO 速度？
對應上圖的 Device Driver 、 IO Channel 和 Disk Device
數據最終會放在這里，因此，效率、數據安全、容災是這里需要考慮的問題。而提高存儲的性能，則可以直接提高物理 IO 的性能
1.4 Logical IO vs Physical IO
邏輯 IO 是操作系統發起的 IO ，這個數據可能會放在磁盤上，也可能會放在內存（文件系統的 Cache ）里。
物理 IO 是設備驅動發起的 IO ，這個數據最終會落在磁盤上。
邏輯 IO 和物理 IO 不是一一對應的。
二、IO 模型
這部分的東西在網絡編程經常能看到，不過在所有IO處理中都是類似的。
2.1 IO 請求的兩個階段：
等待資源階段：IO請求一般需要請求特殊的資源（如磁盤、RAM、文件），當資源被上一個使用者使用沒有被釋放時，IO請求就會被阻塞，直到能夠使用這個資源。
使用資源階段：真正進行數據接收和發生。
舉例說就是排隊和服務。
2.2 在等待數據階段，IO分為阻塞IO和非阻塞IO。
阻塞IO：資源不可用時，IO請求一直阻塞，直到反饋結果（有數據或超時）。
非阻塞IO：資源不可用時，IO請求離開返回，返回數據標識資源不可用
2.3 在使用資源階段，IO分為同步IO和異步IO。
同步IO：應用阻塞在發送或接收數據的狀態，直到數據成功傳輸或返回失敗。
異步IO：應用發送或接收數據后立刻返回，數據寫入OS緩存，由OS完成數據發送或接收，並返回成功或失敗的信息給應用。
2.4 Unix的5個IO模型划分
- 阻塞IO
- 非阻塞IO
- IO復用
- 信號驅動的IO
- 異步IO
從性能上看，異步IO的性能無疑是最好的。
2.5 各種IO的特點
阻塞IO：使用簡單，但隨之而來的問題就是會形成阻塞，需要獨立線程配合，而這些線程在大多數時候都是沒有進行運算的。Java的BIO使用這種方式，問題帶來的問題很明顯，一個Socket需要一個獨立的線程，因此，會造成線程膨脹。
非阻塞IO：采用輪詢方式，不會形成線程的阻塞。Java的NIO使用這種方式，對比BIO的優勢很明顯，可以使用一個線程進行所有Socket的監聽（select）。大大減少了線程數。
同步IO：同步IO保證一個IO操作結束之后才會返回，因此同步IO效率會低一些，但是對應用來說，編程方式會簡單。Java的BIO和NIO都是使用這種方式進行數據處理。
異步IO：由於異步IO請求只是寫入了緩存，從緩存到硬盤是否成功不可知，因此異步IO相當於把一個IO拆成了兩部分，一是發起請求，二是獲取處理結果。因此，對應用來說增加了復雜性。但是異步IO的性能是所有很好的，而且異步的思想貫穿了IT系統放放面面。
三、IO 性能的重要指標
最重要的三個指標
3.1 IOPS
IOPS，Input/Output Per Second，即每秒鍾處理的I/O請求數量。IOPS是隨機訪問類型業務（OLTP類）很重要的一個參考指標。
3.1.2 一塊物理硬盤能提供多少IOPS？
從磁盤上進行數據讀取時，比較重要的幾個時間是：尋址時間（找到數據塊的起始位置），旋轉時間（等待磁盤旋轉到數據塊的起始位置），傳輸時間（讀取數據的時間和返回的時間）。其中尋址時間是固定的（磁頭定位到數據的存儲的扇區即可），旋轉時間受磁盤轉速的影響，傳輸時間受數據量大小的影響和接口類型的影響（不用硬盤接口速度不同），但是在隨機訪問類業務中，他的時間也很少。因此，在硬盤接口相同的情況下，IOPS主要受限於尋址時間和傳輸時間。以一個15K的硬盤為例，尋址時間固定為4ms，傳輸時間為60s/15000 * 1/2=2ms，忽略傳輸時間。1000ms/6ms=167個IOPS。
常見磁盤平均物理尋道時間為：
7200RPM（轉）/分的STAT硬盤平均物理尋道時間是9ms，平均旋轉延遲大約 4.17ms
10000RPM（轉）/分的SAS硬盤平均物理尋道時間是6ms ，平均旋轉延遲大約 3ms
15000RPM（轉）/分的SAS硬盤平均物理尋道時間是4ms，平均旋轉延遲大約 2ms
最大IOPS的理論計算方法：IOPS = 1000 ms/ (尋道時間 + 旋轉延遲)。忽略數據傳輸時間。
7200 rpm的磁盤IOPS = 1000 / (9 + 4.17) = 76 IOPS
10000 rpm的磁盤IOPS = 1000 / (6+ 3) = 111 IOPS
15000 rpm的磁盤IOPS = 1000 / (4 + 2) = 166 IOPS
RAID0/RAID5/RAID6的多塊磁盤可以並行工作，所以，在這樣的硬件條件下， IOPS 相應倍增。假如， 兩塊15000 rpm 磁盤的話，166 * 2 = 332 IOPS。
維基上列出了常見硬盤的IOPS
SSD 達到了驚人的100,000。 見下圖
固態硬盤沒有尋道時間和旋轉時間。IO耗時是通過地址查找數據耗時，根據芯片顆粒SLC、MLC，中控芯片、隊列深度32~64、接口Sata、PCIE的不同，一般負載非太高時是相對固定值（控制在60%利用率）。
IOPS = 1000/IO耗時。因為SSD比較固定，比如Intel 320 SSD對8K avgrq-sz耗時0.1ms，1000/0.1ms=10000 IOPS。
3.1.3 OS的一次IO請求對應物理硬盤一個IO嗎？
在沒有文件系統、沒有VM（卷管理）、沒有RAID、沒有存儲設備的情況下，這個答案還是成立的。但是當這么多中間層加進去以后，這個答案就不是這樣了。物理硬盤提供的IO是有限的，也是整個IO系統存在瓶頸的最大根源。所以，如果一塊硬盤不能提供，那么多塊在一起並行處理，這不就行了嗎？確實是這樣的。可以看到，越是高端的存儲設備的cache越大，硬盤越多，一方面通過cache異步處理IO，另一方面通過盤數增加，盡可能把一個OS的IO分布到不同硬盤上，從而提高性能。文件系統則是在cache上會影響，而VM則可能是一個IO分布到多個不同設備上（Striping）。
所以，一個OS的IO在經過多個中間層以后，發生在物理磁盤上的IO是不確定的。可能是一對一個，也可能一個對應多個。
3.1.4 IOPS 能算出來嗎？
對單塊磁盤的IOPS的計算沒有沒問題，但是當系統后面接的是一個存儲系統時、考慮不同讀寫比例，IOPS則很難計算，而需要根據實際情況進行測試。主要的因素有：
存儲系統本身有自己的緩存。緩存大小直接影響IOPS，理論上說，緩存越大能cache的東西越多，在cache命中率保持的情況下，IOPS會越高。
RAID級別。不同的RAID級別影響了物理IO的效率。
讀寫混合比例。對讀操作，一般只要cache能足夠大，可以大大減少物理IO，而都在cache中進行；對寫操作，不論cache有多大，最終的寫還是會落到磁盤上。因此，100%寫的IOPS要越獄小於100%的讀的IOPS。同時，100%寫的IOPS大致等同於存儲設備能提供的物理的IOPS。
一次IO請求數據量的多少。一次讀寫1KB和一次讀寫1MB，顯而易見，結果是完全不同的。
當時上面N多因素混合在一起以后，IOPS的值就變得撲朔迷離了。所以，一般需要通過實際應用的測試才能獲得。
3.2 IO Response Time
即IO的響應時間。IO響應時間是從操作系統內核發出一個IO請求到接收到IO響應的時間。因此，IO Response time除了包括磁盤獲取數據的時間，還包括了操作系統以及在存儲系統內部IO等待的時間。一般看，隨IOPS增加，因為IO出現等待，IO響應時間也會隨之增加。對一個OLTP系統，10ms以內的響應時間，是比較合理的。下面是一些IO性能示例：
- 一個8K的IO會比一個64K的IO速度快，因為數據讀取的少些。
- 一個64K的IO會比8個8K的IO速度快，因為前者只請求了一個IO而后者是8個IO。
- 串行IO會比隨機IO快，因為串行IO相對隨機IO說，即便沒有Cache，串行IO在磁盤處理上也會少些操作。
需要注意，IOPS與IO Response Time有着密切的聯系。一般情況下，IOPS增加，說明IO請求多了，IO Response Time會相應增加。但是會出現IOPS一直增加，但是IO Response Time變得非常慢，超過20ms甚至幾十ms，這時候的IOPS雖然還在提高，但是意義已經不大，因為整個IO系統的服務時間已經不可取。
3.3 Throughput
為吞吐量。這個指標衡量標識了最大的數據傳輸量。如上說明，這個值在順序訪問或者大數據量訪問的情況下會比較重要。尤其在大數據量寫的時候。
吞吐量不像IOPS影響因素很多，吞吐量一般受限於一些比較固定的因素，如：網絡帶寬、IO傳輸接口的帶寬、硬盤接口帶寬等。一般他的值就等於上面幾個地方中某一個的瓶頸。
3.4 一些概念
3.4.1 IO Chunk Size
即單個IO操作請求數據的大小。一次IO操作是指從發出IO請求到返回數據的過程。IO Chunk Size與應用或業務邏輯有着很密切的關系。比如像Oracle一類數據庫，由於其block size一般為8K，讀取、寫入時都此為單位，因此，8K為這個系統主要的IO Chunk Size。IO Chunk Size 小，考驗的是IO系統的IOPS能力；IO Chunk Size 大，考驗的時候IO系統的IO吞吐量。
3.4.2 Queue Deep
熟悉數據庫的人都知道，SQL是可以批量提交的，這樣可以大大提高操作效率。IO請求也是一樣，IO請求可以積累一定數據，然后一次提交到存儲系統，這樣一些相鄰的數據塊操作可以進行合並，減少物理IO數。而且Queue Deep如其名，就是設置一起提交的IO請求數量的。一般Queue Deep在IO驅動層面上進行配置。
Queue Deep與IOPS有着密切關系。Queue Deep主要考慮批量提交IO請求，自然只有IOPS是瓶頸的時候才會有意義，如果IO都是大IO，磁盤已經成瓶頸，Queue Deep意義也就不大了。一般來說，IOPS的峰值會隨着Queue Deep的增加而增加(不會非常顯著)，Queue Deep一般小於256。
3.4.3 隨機訪問（隨機IO）、順序訪問（順序IO）
隨機訪問的特點是每次IO請求的數據在磁盤上的位置跨度很大（如：分布在不同的扇區），因此N個非常小的IO請求（如：1K），必須以N次IO請求才能獲取到相應的數據。
順序訪問的特點跟隨機訪問相反，它請求的數據在磁盤的位置是連續的。當系統發起N個非常小的IO請求（如：1K）時，因為一次IO是有代價的，系統會取完整的一塊數據（如4K、8K），所以當第一次IO完成時，后續IO請求的數據可能已經有了。這樣可以減少IO請求的次數。這也就是所謂的預取。
隨機訪問和順序訪問同樣是有應用決定的。如數據庫、小文件的存儲的業務，大多是隨機IO。而視頻類業務、大文件存取，則大多為順序IO。
3.4.4 選取合理的觀察指標：
以上各指標中，不用的應用場景需要觀察不同的指標，因為應用場景不同，有些指標甚至是沒有意義的。
隨機訪問和IOPS: 在隨機訪問場景下，IOPS往往會到達瓶頸，而這個時候去觀察Throughput，則往往遠低於理論值。
順序訪問和Throughput：在順序訪問的場景下，Throughput往往會達到瓶頸（磁盤限制或者帶寬），而這時候去觀察IOPS，往往很小。
3.5 標定
與 CPU 不同，不同環境下，磁盤的性能指標與廠家標稱會不一致。因此，在性能分析前，對所在的計算環境進行標定是很有必要的。
目前主流的第三方IO測試工具有fio、iometer 和 Orion，這三種工具各有千秋。
fio 在 Linux 系統下使用比較方便，iometer 在 window 系統下使用比較方便，Orion 是 oracle 的IO測試軟件，可在沒有安裝 oracle 數據庫的情況下模擬 oracle 數據庫場景的讀寫。
3.5.1 FIO
FIO是測試IOPS的非常好的工具，用來對硬件進行壓力測試和驗證，支持13種不同的I/O引擎，包括：sync,mmap,libaio,posixaio,SGv3,splice,null,network,syslet,guasi,solarisaio等等。
3.5.1.1 安裝FIO
在FIO官網地址下載最新文件，解壓后./configure、make、make install 就可以使用fio了。
3.5.1.2 fio參數解釋
可以使用fio -help查看每個參數，具體的參數左右可以在官網查看how to文檔，如下為幾個常見的參數描述
filename=/dev/emcpowerb 支持文件系統或者裸設備，-filename=/dev/sda2或-filename=/dev/sdb
direct=1 測試過程繞過機器自帶的buffer，使測試結果更真實
rw=randwread 測試隨機讀的I/O
rw=randwrite 測試隨機寫的I/O
rw=randrw 測試隨機混合寫和讀的I/O
rw=read 測試順序讀的I/O
rw=write 測試順序寫的I/O
rw=rw 測試順序混合寫和讀的I/O
bs=4k 單次io的塊文件大小為4k
bsrange=512-2048 同上，提定數據塊的大小范圍
size=5g 本次的測試文件大小為5g，以每次4k的io進行測試
numjobs=30 本次的測試線程為30
runtime=1000 測試時間為1000秒，如果不寫則一直將5g文件分4k每次寫完為止
ioengine=psync io引擎使用pync方式，如果要使用libaio引擎，需要yum install libaio-devel包
rwmixwrite=30 在混合讀寫的模式下，寫占30%
group_reporting 關於顯示結果的，匯總每個進程的信息
此外
lockmem=1g 只使用1g內存進行測試
zero_buffers 用0初始化系統buffer
nrfiles=8 每個進程生成文件的數量3.5.1.3 fio測試
測試場景
100%隨機，100%讀， 4K
fio -filename=/dev/emcpowerb -direct=1 -iodepth 1 -thread -rw=randread -ioengine=psync -bs=4k -size=1000G -numjobs=50 -runtime=180 -group_reporting -name=rand_100read_4k
100%隨機，100%寫， 4K
fio -filename=/dev/emcpowerb -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=psync -bs=4k -size=1000G -numjobs=50 -runtime=180 -group_reporting -name=rand_100write_4k
100%順序，100%讀 ，4K
fio -filename=/dev/emcpowerb -direct=1 -iodepth 1 -thread -rw=read -ioengine=psync -bs=4k -size=1000G -numjobs=50 -runtime=180 -group_reporting -name=sqe_100read_4k
100%順序，100%寫 ，4K
fio -filename=/dev/emcpowerb -direct=1 -iodepth 1 -thread -rw=write -ioengine=psync -bs=4k -size=1000G -numjobs=50 -runtime=180 -group_reporting -name=sqe_100write_4k
100%隨機，70%讀，30%寫 4K
fio -filename=/dev/emcpowerb -direct=1 -iodepth 1 -thread -rw=randrw -rwmixread=70 -ioengine=psync -bs=4k -size=1000G -numjobs=50 -runtime=180 -group_reporting -name=randrw_70read_4k
實際測試
fio -filename=/dev/sda -direct=1 -iodepth 1 -thread -rw=randrw -rwmixread=70 -ioengine=psync -bs=16k -size=200G -numjobs=30 -runtime=100 -group_reporting -name=mytest -ioscheduler=noop上述命令，進行隨機讀寫測試。隊列深度為1。
VM (long time running) 是 測試用的虛擬機。這台 VM的磁盤性能極低。只有兩位數。同一台 ESXi 上的另一台 VM（new build )，磁盤性能很正常。兩者的區別在於，前者不是新裝，而是一直跑
volume test 。后者是新安裝的。
3.6 分析工具
3.6.1 iostat
用途：主要用於監控系統設備的IO負載情況，iostat首次運行時顯示自系統啟動開始的各項統計信息，之后運行iostat將顯示自上次運行該命令以后的統計信息。用戶可以通過指定統計的次數和時間來獲得所需的統計信息。
缺點：iostat有一個弱點，就是它不能對某個進程進行深入分析，僅對系統的整體情況進行分析。iostat屬於sysstat軟件包。可以用yum
install sysstat 直接安裝。
命令格式：
iostat[參數][時間][次數]
命令參數：
• -C 顯示CPU使用情況
• -d 顯示磁盤使用情況
• -k 以 KB 為單位顯示
• -m 以 M 為單位顯示
• -N 顯示磁盤陣列(LVM) 信息
• -n 顯示NFS 使用情況
• -p[磁盤] 顯示磁盤和分區的情況
• -t 顯示終端和CPU的信息
• -x 顯示詳細信息
• -V 顯示版本信息
如上圖，每1秒鍾顯示一次報告
iostat -x 2 6 /dev/sda1每兩秒鍾顯示一次sda1的統計報告，共顯示6次。
CPU 屬性值
• %user：CPU處在用戶模式下的時間百分比。
• %nice：CPU處在帶NICE值的用戶模式下的時間百分比。
• %system：CPU處在系統模式下的時間百分比。
• %iowait：CPU等待輸入輸出完成時間的百分比。
• %steal：管理程序維護另一個虛擬處理器時，虛擬CPU的無意識等待時間百分比。
• %idle：CPU空閑時間百分比。設備屬性值
備注：
• 如果%iowait的值過高，表示硬盤存在I/O瓶頸，
• %idle值高，表示CPU較空閑，
• 如果%idle值高但系統響應慢時，有可能是CPU等待分配內存，此時應加大內存容量。
• %idle值如果持續低於10，那么系統的CPU處理能力相對較低，表明系統中最需要解決的資源是CPU。
磁盤每一列的含義如下:
• rrqm/s: 每秒進行 merge 的讀操作數目。 即 rmerge/s
• wrqm/s: 每秒進行 merge 的寫操作數目。即 wmerge/s
• r/s: 每秒完成的讀 I/O 設備次數。 即 rio/s
• w/s: 每秒完成的寫 I/O 設備次數。即 wio/s
• rsec/s: 每秒讀扇區數。即 rsect/s
• wsec/s: 每秒寫扇區數。即 wsect/s
• rkB/s: 每秒讀 K 字節數。是 rsect/s 的一半,因為扇區大小為 512 字節
• wkB/s: 每秒寫 K 字節數。是 wsect/s 的一半
• avgrq-sz: 平均每次設備 I/O 操作的數據大小(扇區)
• avgqu-sz: 平均 I/O 隊列長度。
• await: 平均每次設備 I/O 操作的等待時間(毫秒)
• r_await：每個讀操作平均所需的時間=[Δrd_ticks/Δrd_ios]
不僅包括硬盤設備讀操作的時間，還包括了在kernel隊列中等待的時間。
• w_await：每個寫操作平均所需的時間=[Δwr_ticks/Δwr_ios]
不僅包括硬盤設備寫操作的時間，還包括了在kernel隊列中等待的時間。
• svctm: 平均每次設備 I/O 操作的服務時間(毫秒)
• %util: 一秒中有百分之多少的時間用於 I/O 操作,或者說一秒中有多少時間 I/O 隊列是非空的。
備注：
• 如果 %util 接近 100%，說明產生的I/O請求太多，I/O系統已經滿負荷，該磁盤可能存在瓶頸。
• 如果 svctm 比較接近 await，說明 I/O 幾乎沒有等待時間；
• 如果 await 遠大於 svctm，說明I/O 隊列太長，io響應太慢，則需要進行必要優化。
• 如果avgqu-sz比較大，也表示有當量io在等待。
3.6.2 iotop
在某些場景下，我們需要找到占用IO特別大的進程，然后關閉它，需要知道PID或者進程名稱，這就需要用到iotop。iotop是一個檢測Linux系統進程IO的工具，界面類似top，如下圖。
iotop和top一樣，也可以通過鍵入相應鍵，觸發排序選項，例如按o可以在IO活動進程和所有進程之間切換。可以通過左右箭頭，選擇響應的列進行數據排序。
iotop的常用參數如下：
-h, --help 查看幫助信息
-o, --only 只查看有IO操作的進程
-b, --batch 非交互模式
-n, --iter= 設置迭代次數
-d, --delay 刷新頻率，默認是1秒
-p, --pid 查看指定的進程號的IO，默認是所有進程
-u, --user 查看指定用戶進程的IO，默認是所有用戶
-P, --processes 只看進程，不看線程
-a, --accumulated 看累計IO，而不是實時IO
-k, --kilobytes 以KB為單位查看IO，而不是以最友好的單位顯示
-t, --time 每行添加一個時間戳，默認便開啟--batch
-q, --quit 不顯示頭部信息3.6.3 blktrace
blktrace是一柄神器，很多工具都是基於該神器的：ioprof，seekwatcher，iowatcher，這個工具基本可以滿足我們的對塊設備請求的所有了解。
blktrace的原理
一個I/O請求，從應用層到底層塊設備，路徑如下圖所示：
從上圖可以看出IO路徑是很復雜的。這么復雜的IO路徑我們是無法用短短一篇小博文介紹清楚的。我們將IO路徑簡化一下：
一個I/O請求進入block layer之后，可能會經歷下面的過程：
- Remap: 可能被DM(Device Mapper)或MD(Multiple Device, Software RAID) remap到其它設備
- Split: 可能會因為I/O請求與扇區邊界未對齊、或者size太大而被分拆(split)成多個物理I/O
- Merge: 可能會因為與其它I/O請求的物理位置相鄰而合並(merge)成一個I/O
- 被IO Scheduler依照調度策略發送給driver
- 被driver提交給硬件，經過HBA、電纜（光纖、網線等）、交換機（SAN或網絡）、最后到達存儲設備，設備完成IO請求之后再把結果發回。
blktrace 能夠記錄下IO所經歷的各個步驟:
我們一起看下blktrace的輸出長什么樣子：
第一個字段：8,0 這個字段是設備號 major device ID和minor device ID。
第二個字段：3 表示CPU
第三個字段：11 序列號
第四個字段：0.009507758 Time
Stamp是時間偏移
第五個字段：PID 本次IO對應的進程ID
第六個字段：Event，這個字段非常重要，反映了IO進行到了那一步
第七個字段：R表示 Read，
W是Write，D表示block，B表示Barrier Operation
第八個字段：223490+56，表示的是起始block number 和 number of blocks，即我們常說的Offset 和 Size
第九個字段：
進程名
其中第六個字段非常有用：每一個字母都代表了IO請求所經歷的某個階段。
Q – 即將生成IO請求
|
G – IO請求生成
|
I – IO請求進入IO Scheduler隊列
|
D – IO請求進入driver
|
C – IO請求執行完畢注意，整個IO路徑，分成很多段，每一段開始的時候，都會有一個時間戳，根據上一段開始的時間和下一段開始的時間，就可以得到IO 路徑各段花費的時間。
注意，我們心心念念的service time，也就是反應塊設備處理能力的指標，就是從D到C所花費的時間，簡稱D2C。
而iostat輸出中的await，即整個IO從生成請求到IO請求執行完畢，即從Q到C所花費的時間，我們簡稱Q2C。
3.6.4 iowatcher
僅僅查看數據進行分析，非常的不直觀。工具 iowatcher 可以把 blktrace 采集的信息，轉化為圖像和動畫，方便分析。
iowatcher -t sda.blktrace.bin -o disk.svg
iowatcher -t sda.blktrace.bin --movie -o disk.mp4首先，我們看 VM volume test 的圖像：
參考
說說IO（一）- IO的分層
說說IO（二）- IO模型
說說IO（三）- IO性能的重要指標
說說IO（四）- 文件系統
說說IO（五）- 邏輯卷管理
說說IO（六）- Driver &
IO Channel
說說IO（七）-
RAID
說說IO（八）-
三分天下
磁盤性能分析
IO測試工具之fio詳解
blktrace分析IO