一、概念介紹：
磁盤性能指標--IOPS
----------------------------------------------------------
IOPS (Input/Output Per Second)即每秒的輸入輸出量(或讀寫次數)，是衡量磁盤性能的主要指標之一。IOPS是指單位時間內系統能處理的I/O請求數量，一般以每秒處理的I/O請求數量爲單位，I/O請求通常爲讀或寫數據操作請求。
隨機讀寫頻繁的應用，如小文件存儲(圖片)、OLTP數據庫、郵件服務器，關注隨機讀寫性能，IOPS是關鍵衡量指標。
順序讀寫頻繁的應用，傳輸大量連續數據，如電視臺的視頻編輯，視頻點播VOD(Video On Demand)，關注連續讀寫性能。數據吞吐量是關鍵衡量指標。
IOPS和數據吞吐量適用於不同的場合：
讀取10000個1KB文件，用時10秒 Throught(吞吐量)=1MB/s ，IOPS=1000 追求IOPS
讀取1個10MB文件，用時0.2秒 Throught(吞吐量)=50MB/s, IOPS=5 追求吞吐量
磁盤服務時間
--------------------------------------
傳統磁盤本質上一種機械裝置，如FC, SAS, SATA磁盤，轉速通常爲5400/7200/10K/15K rpm不等。影響磁盤的關鍵因素是磁盤服務時間，即磁盤完成一個I/O請求所花費的時間，它由尋道時間、旋轉延遲和數據傳輸時間三部分構成。
尋道時間 Tseek是指將讀寫磁頭移動至正確的磁道上所需要的時間。尋道時間越短，I/O操作越快，目前磁盤的平均尋道時間一般在3－15ms。
旋轉延遲 Trotation是指盤片旋轉將請求數據所在扇區移至讀寫磁頭下方所需要的時間。旋轉延遲取決於磁盤轉速，通常使用磁盤旋轉一週所需時間的1/2表示。比如，7200 rpm的磁盤平均旋轉延遲大約爲60*1000/7200/2 = 4.17ms，而轉速爲15000 rpm的磁盤其平均旋轉延遲爲2ms。
數據傳輸時間 Ttransfer是指完成傳輸所請求的數據所需要的時間，它取決於數據傳輸率，其值等於數據大小除以數據傳輸率。目前IDE/ATA能達到133MB/s，SATA II可達到300MB/s的接口數據傳輸率，數據傳輸時間通常遠小於前兩部分消耗時間。簡單計算時可忽略。
常見磁盤平均物理尋道時間爲：
7200轉/分的STAT硬盤平均物理尋道時間是9ms
10000轉/分的STAT硬盤平均物理尋道時間是6ms
15000轉/分的SAS硬盤平均物理尋道時間是4ms
常見硬盤的旋轉延遲時間爲：
7200 rpm的磁盤平均旋轉延遲大約爲60*1000/7200/2 = 4.17ms
10000 rpm的磁盤平均旋轉延遲大約爲60*1000/10000/2 = 3ms，
15000 rpm的磁盤其平均旋轉延遲約爲60*1000/15000/2 = 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
影響測試的因素
-----------------------------------------
實際測量中，IOPS數值會受到很多因素的影響，包括I/O負載特徵(讀寫比例，順序和隨機，工作線程數，隊列深度，數據記錄大小)、系統配置、操作系統、磁盤驅動等等。因此對比測量磁盤IOPS時，必須在同樣的測試基準下進行，即便如此也會產生一定的隨機不確定性。
隊列深度說明
NCQ、SCSI TCQ、PATA TCQ和SATA TCQ技術解析
----------------------------------------
是一種命令排序技術，一把餵給設備更多的IO請求，讓電梯算法和設備有機會來安排合併以及內部並行處理，提高總體效率。
SCSI TCQ的隊列深度支持256級
ATA TCQ的隊列深度支持32級 （需要8M以上的緩存）
NCQ最高可以支持命令深度級數爲32級，NCQ可以最多對32個命令指令進行排序。
大多數的軟件都是屬於同步I/O軟件，也就是說程序的一次I/O要等到上次I/O操作的完成後才進行，這樣在硬盤中同時可能僅只有一個命令，也是無法發揮這個技術的優勢，這時隊列深度爲1。
隨着Intel的超線程技術的普及和應用環境的多任務化，以及異步I/O軟件的大量涌現。這項技術可以被應用到了，實際隊列深度的增加代表着性能的提高。
在測試時，隊列深度爲1是主要指標，大多數時候都參考1就可以。實際運行時隊列深度也一般不會超過4.
IOPS可細分爲如下幾個指標：
-----------------------------------------
數據量爲n字節，隊列深度爲k時，隨機讀取的IOPS
數據量爲n字節，隊列深度爲k時，隨機寫入的IOPS
二、舉例測試：
UOS公有云開放以來，一些用戶反應用dd命令測試出來的1TB雲硬盤的吞吐率(MBPS)只有128MB/s，而不是我們SLA保證的170MB /s ，這是爲什麼？下面我會簡單介紹如何測試硬盤，RAID，SAN，SSD，雲硬盤等，然後再來回答上面的問題。
測試前提
我們在進行測試時，都會分清楚:
測試對象：要區分硬盤、SSD、RAID、SAN、雲硬盤等，因爲它們有不同的特點
測試指標：IOPS和MBPS(吞吐率)，下面會具體闡述
測試工具：Linux下常用Fio、dd工具, Windows下常用IOMeter,
測試參數: IO大小，尋址空間，隊列深度，讀寫模式，隨機/順序模式
測試方法：也就是測試步驟。
測試是爲了對比，所以需要定性和定量。在宣佈自己的測試結果時，需要說明這次測試的工具、參數、方法，以便於比較。
測試工具 fio:
順序讀
測試命令:fio -name iops -rw=read -bs=4k -runtime=60 -iodepth 32 -filename /dev/sda6 -ioengine libaio -direct=1
SATA Jobs: 1 (f=1): [R] [16.4% done] [124.1M/0K /s] [31.3K/0 iops] [eta 00m:51s] SAS Jobs: 1 (f=1): [R] [16.4% done] [190M/0K /s] [41.3K/0 iops] [eta 00m:51s] SSD Jobs: 1 (f=1): [R] [100.0% done] [404M/0K /s] [103K /0 iops] [eta 00m:00s]
可以看到 在對4KB數據包進行連續讀的情況下:
SSD其速度可以達到404MB/S，IOPS達到103K/S
SAS其速度可以達到190MB/S，IOPS達到41K/S
SATA其速度可以達到124MB/S，IOPS達到31K/S
順序讀，SAS總體表現是SATA硬盤的1.3倍，SSD總體表現是sata硬盤的4倍。
隨機讀
測試命令 fio -name iops -rw=randread -bs=4k -runtime=60 -iodepth 32 -filename /dev/sda6 -ioengine libaio -direct=1
SATA Jobs: 1 (f=1): [r] [41.0% done] [466K/0K /s] [114 /0 iops] [eta 00m:36s] SAS Jobs: 1 (f=1): [r] [41.0% done] [1784K/0K /s] [456 /0 iops] [eta 00m:36s] SSD Jobs: 1 (f=1): [R] [100.0% done] [505M/0K /s] [129K /0 iops] [eta 00m:00s]
隨機讀，SAS總體表現是SATA硬盤的4倍，SSD總體表現是sata硬盤的一千多倍。
順序寫
測試命令:fio -name iops -rw=write -bs=4k -runtime=60 -iodepth 32 -filename /dev/sda6 -ioengine libaio -direct=1
SATA Jobs: 1 (f=1): [W] [21.3% done] [0K/124.9M /s] [0 /31.3K iops] [eta 00m:48s] SAS Jobs: 1 (f=1): [W] [21.3% done] [0K/190M /s] [0 /36.3K iops] [eta 00m:48s] SSD Jobs: 1 (f=1): [W] [100.0% done] [0K/592M /s] [0 /152K iops] [eta 00m:00s]
同樣的4KB數據包順序寫的情況下，SSD卡的成績爲592MB/S，IOPS爲152K。而本地硬盤僅爲118MB/S，IOPS僅爲30290。
隨機寫
測試命令: fio -name iops -rw=randwrite -bs=4k -runtime=60 -iodepth 32 -filename /dev/sda6 -ioengine libaio -direct=1
SATA Jobs: 1 (f=1): [w] [100.0% done] [0K/548K /s] [0 /134 iops] [eta 00m:00s] SAS Jobs: 1 (f=1): [w] [100.0% done] [0K/2000K /s] [0 /512 iops] [eta 00m:00s] SSD Jobs: 1 (f=1): [W] [100.0% done] [0K/549M /s] [0 /140K iops] [eta 00m:00s]
在接下來的4KB數據包隨機寫操作中，SSD卡再次展示了其高超的IO性能，高達549MB/S的隨機寫速率，IOPS高達140K。相比之下，本地硬盤的隨機讀寫僅爲548KB/S，IOPS爲134。
存儲系統模型
爲了更好的測試，我們需要先了解存儲系統，塊存儲系統本質是一個排隊模型，我們可以拿銀行作爲比喻。還記得你去銀行辦事時的流程嗎？
去前臺取單號
等待排在你之前的人辦完業務
輪到你去某個櫃檯
櫃檯職員幫你辦完手續1
櫃檯職員幫你辦完手續2
櫃檯職員幫你辦完手續3
辦完業務，從櫃檯離開
如何評估銀行的效率呢：
服務時間 = 手續1 + 手續2 + 手續3
響應時間 = 服務時間 + 等待時間
性能 = 單位時間內處理業務數量
那銀行如何提高效率呢:
增加櫃檯數
降低服務時間
因此，排隊系統或存儲系統的優化方法是
增加並行度
降低服務時間
硬盤測試
硬盤原理
我們應該如何測試SATA/SAS硬盤呢？
每個硬盤都有一個磁頭(相當於銀行的櫃檯)，硬盤的工作方式是：
收到IO請求，得到地址和數據大小
移動磁頭(尋址)
找到相應的磁道(尋址)
讀取數據
傳輸數據
則磁盤的隨機IO服務時間:
服務時間 = 尋道時間 + 旋轉時間 + 傳輸時間
對於10000轉速的SATA硬盤來說，一般尋道時間是7 ms，旋轉時間是3 ms, 64KB的傳輸時間是 0.8 ms， 則SATA硬盤每秒可以進行隨機IO操作是 1000/(7 + 3 + 0.8) = 93，所以我們估算SATA硬盤64KB隨機寫的IOPS是93。一般的硬盤廠商都會標明順序讀寫的MBPS。
我們在列出IOPS時，需要說明IO大小，尋址空間，讀寫模式，順序/隨機，隊列深度。我們一般常用的IO大小是4KB，這是因爲文件系統常用的塊大小是4KB。
使用dd測試硬盤
雖然硬盤的性能是可以估算出來的，但是怎麼才能讓應用獲得這些性能呢？對於測試工具來說，就是如何得到IOPS和MBPS峯值。我們先用dd測試一下SATA硬盤的MBPS(吞吐量)。
#dd if=/dev/zero of=/dev/sdd bs=4k count=300000 oflag=direct 記錄了300000+0 的讀入 記錄了300000+0 的寫出 1228800000字節(1.2 GB)已複製，17.958 秒，68.4 MB/秒
#iostat -x sdd 5 10 ... Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sdd 0.00 0.00 0.00 16794.80 0.00 134358.40 8.00 0.79 0.05 0.05 78.82...
爲什麼這塊硬盤的MBPS只有68MB/s? 這是因爲磁盤利用率是78%，沒有到達95%以上，還有部分時間是空閒的。當dd在前一個IO響應之後，在準備發起下一個IO時，SATA硬盤是空閒的。那麼如何才能提高利用率，讓磁盤不空閒呢？只有一個辦法，那就是增加硬盤的隊列深度。相對於CPU來說，硬盤屬於慢速設備，所有操作系統會有給每個硬盤分配一個專門的隊列用於緩衝IO請求。
隊列深度
什麼是磁盤的隊列深度？
在某個時刻,有N個inflight的IO請求,包括在隊列中的IO請求、磁盤正在處理的IO請求。N就是隊列深度。
加大硬盤隊列深度就是讓硬盤不斷工作，減少硬盤的空閒時間。
加大隊列深度 -> 提高利用率 -> 獲得IOPS和MBPS峯值 -> 注意響應時間在可接受的範圍內
增加隊列深度的辦法有很多
使用異步IO，同時發起多個IO請求，相當於隊列中有多個IO請求
多線程發起同步IO請求，相當於隊列中有多個IO請求
增大應用IO大小，到達底層之後，會變成多個IO請求，相當於隊列中有多個IO請求 隊列深度增加了。
隊列深度增加了，IO在隊列的等待時間也會增加，導致IO響應時間變大，這需要權衡。讓我們通過增加IO大小來增加dd的隊列深度，看有沒有效果：
dd if=/dev/zero of=/dev/sdd bs=2M count=1000 oflag=direct 記錄了1000+0 的讀入 記錄了1000+0 的寫出 2097152000字節(2.1 GB)已複製，10.6663 秒，197 MB/秒
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sdd 0.00 0.00 0.00 380.60 0.00 389734.40 1024.00 2.39 6.28 2.56 97.42
可以看到2MB的IO到達底層之後，會變成多個512KB的IO，平均隊列長度爲2.39，這個硬盤的利用率是97%，MBPS達到了197MB/s。(爲什麼會變成512KB的IO，你可以去使用Google去查一下內核參數 max_sectors_kb的意義和使用方法 )
也就是說增加隊列深度，是可以測試出硬盤的峯值的。
使用fio測試硬盤
現在，我們來測試下SATA硬盤的4KB隨機寫的IOPS。因爲我的環境是Linux，所以我使用FIO來測試。
$fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=randwrite -size=1000G -filename=/dev/vdb -name="EBS 4K randwrite test" -iodepth=64 -runtime=60
簡單介紹fio的參數
ioengine: 負載引擎，我們一般使用libaio，發起異步IO請求。
bs: IO大小
direct: 直寫，繞過操作系統Cache。因爲我們測試的是硬盤，而不是操作系統的Cache，所以設置爲1。
rw: 讀寫模式，有順序寫write、順序讀read、隨機寫randwrite、隨機讀randread等。
size: 尋址空間，IO會落在 [0, size)這個區間的硬盤空間上。這是一個可以影響IOPS的參數。一般設置爲硬盤的大小。
filename: 測試對象
iodepth: 隊列深度，只有使用libaio時纔有意義。這是一個可以影響IOPS的參數。
runtime: 測試時長
下面我們做兩次測試，分別 iodepth = 1和iodepth = 4的情況。下面是iodepth = 1的測試結果。
上圖中藍色方框裏面的是測出的IOPS 230, 綠色方框裏面是每個IO請求的平均響應時間，大約是4.3ms。***方框表示95%的IO請求的響應時間是小於等於 9.920 ms。橙色方框表示該硬盤的利用率已經達到了98.58%。
下面是 iodepth = 4 的測試:
我們發現這次測試的IOPS沒有提高，反而IO平均響應時間變大了，是17ms。
爲什麼這裏提高隊列深度沒有作用呢，原因當隊列深度爲1時，硬盤的利用率已經達到了98%，說明硬盤已經沒有多少空閒時間可以壓榨了。而且響應時間爲 4ms。 對於SATA硬盤，當增加隊列深度時，並不會增加IOPS，只會增加響應時間。這是因爲硬盤只有一個磁頭，並行度是1， 所以當IO請求隊列變長時，每個IO請求的等待時間都會變長，導致響應時間也變長。
這是以前用IOMeter測試一塊SATA硬盤的4K隨機寫性能，可以看到IOPS不會隨着隊列深度的增加而增加，反而是平均響應時間在倍增。
| 隊列深度 | IOPS | 平均響應時間 |
| 1 | 332.931525 | 3.002217 |
| 2 | 333.985074 | 5.986528 |
| 4 | 332.594653 | 12.025060 |
| 8 | 336.568012 | 23.766359 |
| 16 | 329.785606 | 48.513477 |
| 32 | 332.054590 | 96.353934 |
| 64 | 331.041063 | 193.200815 |
| 128 | 331.309109 | 385.163111 |
| 256 | 327.442963 | 774.401781 |
尋址空間對IOPS的影響
我們繼續測試SATA硬盤，前面我們提到尋址空間參數也會對IOPS產生影響，下面我們就測試當size=1GB時的情況。
我們發現，當設置size=1GB時，IOPS會顯著提高到568，IO平均響應時間會降到7ms(隊列深度爲4)。這是因爲當尋址空間爲1GB時，磁頭需要移動的距離變小了，每次IO請求的服務時間就降低了，這就是空間局部性原理。假如我們測試的RAID卡或者是磁盤陣列(SAN)，它們可能會用Cache把這1GB的數據全部緩存，極大降低了IO請求的服務時間(內存的寫操作比硬盤的寫操作快很1000倍)。所以設置尋址空間爲1GB的意義不大，因爲我們是要測試硬盤的全盤性能，而不是Cache的性能。
硬盤優化
硬盤廠商提高硬盤性能的方法主要是降低服務時間(延遲)：
提高轉速(降低旋轉時間和傳輸時間)
增加Cache(降低寫延遲，但不會提高IOPS)
提高單磁道密度(變相提高傳輸時間)
RAID測試
RAID0/RAID5/RAID6的多塊磁盤可以同時服務，其實就是提高並行度，這樣極大提高了性能(相當於銀行有多個櫃檯)。
以前測試過12塊RAID0，100GB的尋址空間，4KB隨機寫，逐步提高隊列深度，IOPS會提高，因爲它有12塊磁盤(12個磁頭同時工作)，並行度是12。
| 隊列深度 | IOPS | 平均響應時間 |
| 1 | 1215.995842 | 0.820917 |
| 2 | 4657.061317 | 0.428420 |
| 4 | 5369.326970 | 0.744060 |
| 8 | 5377.387303 | 1.486629 |
| 16 | 5487.911660 | 2.914048 |
| 32 | 5470.972663 | 5.846616 |
| 64 | 5520.234015 | 11.585251 |
| 128 | 5542.739816 | 23.085843 |
| 256 | 5513.994611 | 46.401606 |
RAID卡廠商優化的方法也是降低服務時間：
使用大內存Cache
使用IO處理器，降低XOR操作的延遲。
使用更大帶寬的硬盤接口
SAN測試
對於低端磁盤陣列，使用單機IOmeter就可以測試出它的IOPS和MBPS的峯值，但是對於高端磁盤陣列，就需要多機並行測試才能得到IOPS和MBPS的峯值(IOmeter支持多機並行測試)。
磁盤陣列廠商通過以下手段降低服務時間：
更快的存儲網絡，比如FC和IB，延時更低。
讀寫Cache。寫數據到Cache之後就馬上返回，不需要落盤。 而且磁盤陣列有更多的控制器和硬盤，大大提高了並行度。
現在的存儲廠商會找SPC幫忙測試自己的磁盤陣列產品(或全閃存陣列)， 並給SPC支付費用，這就是赤裸裸的標準壟斷。國內也有做存儲系統測試的，假如你要測試磁盤陣列，可以找NSTC (廣告時間)。
SSD測試
SSD的延時很低，並行度很高(多個nand塊同時工作)，缺點是壽命和GC造成的響應時間不穩定。
推薦用IOMeter進行測試，使用大隊列深度，並進行長時間測試，這樣可以測試出SSD的真實性能。
下圖是storagereview對一些SSD硬盤做的4KB隨機寫的長時間測試，可以看出有些SSD硬盤的最大響應時間很不穩定，會飆高到幾百ms，這是不可接受的。
雲硬盤測試
我們通過兩方面來提高雲硬盤的性能的：
降低延遲(使用SSD，使用萬兆網絡，優化代碼，減少瓶頸)
提高並行度(數據分片，同時使用整個集羣的所有SSD)
在Linux下測試雲硬盤
在Linux下，你可以使用FIO來測試
操作系統：Ubuntu 14.04
CPU： 2
Memory: 2GB
雲硬盤大小： 1TB(SLA: 6000 IOPS, 170MB/s吞吐率 )
安裝fio：
#sudo apt-get install fio
再次介紹一下FIO的測試參數：
ioengine: 負載引擎，我們一般使用libaio，發起異步IO請求。
bs: IO大小
direct: 直寫，繞過操作系統Cache。因爲我們測試的是硬盤，而不是操作系統的Cache，所以設置爲1。
rw: 讀寫模式，有順序寫write、順序讀read、隨機寫randwrite、隨機讀randread等。
size: 尋址空間，IO會落在 [0, size)這個區間的硬盤空間上。這是一個可以影響IOPS的參數。一般設置爲硬盤的大小。
filename: 測試對象
iodepth: 隊列深度，只有使用libaio時纔有意義。這是一個可以影響IOPS的參數。
runtime: 測試時長
4K隨機寫測試
我們首先進行4K隨機寫測試，測試參數和測試結果如下所示：
#fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=randwrite -size=100G -filename=/dev/vdb -name="EBS 4KB randwrite test" -iodepth=32 -runtime=60
藍色方框表示IOPS是5900，在正常的誤差範圍內。綠色方框表示IO請求的平均響應時間爲5.42ms， ***方框表示95%的IO請求的響應時間是小於等於 6.24 ms的。
4K隨機讀測試
我們再來進行4K隨機讀測試，測試參數和測試結果如下所示：
#fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=randread -size=100G -filename=/dev/vdb -name="EBS 4KB randread test" -iodepth=8 -runtime=60
512KB順序寫測試
最後我們來測試512KB順序寫，看看雲硬盤的最大MBPS(吞吐率)是多少，測試參數和測試結果如下所示：
#fio -ioengine=libaio -bs=512k -direct=1 -thread -rw=write -size=100G -filename=/dev/vdb -name="EBS 512KB seqwrite test" -iodepth=64 -runtime=60
藍色方框表示MBPS爲174226KB/s，約爲170MB/s。
使用dd測試吞吐率
其實使用dd命令也可以測試出170MB/s的吞吐率，不過需要設置一下內核參數，詳細介紹在 128MB/s VS 170MB/s 章節中。
在Windows下測試雲硬盤
在Windows下，我們一般使用IOMeter測試磁盤的性能，IOMeter不僅功能強大，而且很專業，是測試磁盤性能的首選工具。
IOMeter是圖形化界面(濃濃的MFC框架的味道)，非常方便操作，下面我將使用IOMeter測試我們UOS上1TB的雲硬盤。
操作系統：Window Server 2012 R2 64
CPU： 4
Memory: 8GB
雲硬盤大小： 1TB
當你把雲硬盤掛載到Windows主機之後，你還需要在windows操作系統裏面設置硬盤爲聯機狀態。
4K隨機寫測試
打開IOMeter(你需要先下載)，你會看到IOMeter的主界面。在右邊，你回發現4個worker(數量和CPU個數相同)，因爲我們現在只需要1個worker，所以你需要把其他3個worker移除掉。
現在讓我們來測試硬盤的4K隨機寫，我們選擇好硬盤(Red Hat VirtIO 0001)，設置尋址空間(Maximum Disk Size)爲50GB(每個硬盤扇區大小是512B，所以一共是 50*1024*1024*1024/512 = 104857600)，設置隊列深度(Outstanding I/Os)爲64。
然後在測試集中選擇”4KiB ALIGNED; 0% Read; 100% random(4KB對齊，100%隨機寫操作)” 測試
然後設置測試時間，我們設置測試時長爲60秒，測試之前的預熱時間爲10秒(IOMeter會發起負載，但是不統計這段時間的結果)。
在最後測試之前，你可以設置查看實時結果，設置實時結果的更新頻率是5秒鐘。最後點擊綠色旗子開始測試。
在測試過程中，我們可以看到實時的測試結果，當前的IOPS是6042，平均IO請求響應時間是10.56ms，這個測試還需要跑38秒，這個測試輪迴只有這個測試。
我們可以看到IOMeter自動化程度很高，極大解放測試人員的勞動力，而且可以導出CSV格式的測試結果。
順序讀寫測試
我們再按照上面的步驟，進行了順序讀/寫測試。下面是測試結果：
| IO大小 | 讀寫模式 | 隊列深度 | MBPS | |
| 順序寫吞吐測試 | 512KB | 順序寫 | 64 | 164.07 MB/s |
| 順序讀吞吐測試 | 256KB | 順序讀 | 64 | 179.32 MB/s |
雲硬盤的響應時間
當前雲硬盤寫操作的主要延遲是
網絡傳輸
多副本，寫三份(數據強一致性)
三份數據都落盤(數據持久化)之後，才返回
IO處理邏輯
我們當前主要是優化IO處理邏輯，並沒有去優化2和3，這是因爲我們是把用戶數據的安全性放在第一位。
128MB/s VS 170MB/s
回到最開始的問題 “爲什麼使用dd命令測試雲硬盤只有128MB/s”， 這是因爲目前雲硬盤在處理超大IO請求時的延遲比SSD高(我們會不斷進行優化)，現在我們有兩種方法來獲得更高的MBPS：
設置max_sectors_kb爲256 (系統默認爲512)，降低延遲
使用fio來測試，加大隊列深度
通過設置max_sectors_kb這個參數，使用dd也可以測出170MB/s的吞吐量
root@ustack:~# cat /sys/block/vdb/queue/max_sectors_kb 512 root@ustack:~# echo "256" > /sys/block/vdb/queue/max_sectors_kb root@ustack:~# root@ustack:~# dd if=/dev/zero of=/dev/vdb bs=32M count=40 oflag=direct 40+0 records in 40+0 records out 1342177280 bytes (1.3 GB) copied, 7.51685 s, 179 MB/s root@ustack:~#
同時查看IO請求的延遲：
root@ustack:~# iostat -x vdb 5 100 ... Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util vdb 0.00 0.00 0.00 688.00 0.00 176128.00 512.00 54.59 93.47 0.00 93.47 1.40 96.56
下面是使用fio工具的測試結果，也可以得到170MB/s的吞吐率。
不可測試的指標
IOPS和MBPS是用戶可以使用工具測試的指標，雲硬盤還有一些用戶不可測量的指標
數據一致性
數據持久性
數據可用性
這些指標我們只能通過根據系統架構和約束條件計算得到，然後轉告給用戶。這些指標衡量着公有云廠商的良心，有機會會專門進行介紹。
總結
上面介紹了一下測試工具和一些觀點，希望對你有所幫助。
測試需要定性和定量
瞭解存儲模型可以幫助你更好的進行測試
增加隊列深度可以有效測試出IOPS和MBPS的峯值