吞吐量和 IOPS 及測試工具 FIO 使用

本文轉載自查看原文 2020-04-24 17:03 3969 雲原生/ Ceph

學習資料來源於網絡。

磁盤I/O的概念

I/O 的概念，從字義來理解就是輸入輸出。操作系統從上層到底層，各個層次之間均存在 I/O。比如，CPU 有 I/O，內存有 I/O, VMM 有 I/O, 底層磁盤上也有 I/O，這是廣義上的 I/O。通常來講，一個上層的 I/O 可能會產生針對磁盤的多個 I/O，也就是說，上層的 I/O 是稀疏的，下層的 I/O 是密集的。

磁盤的 I/O，顧名思義就是磁盤的輸入輸出。輸入指的是對磁盤寫入數據，輸出指的是從磁盤讀出數據。我們常見的磁盤類型有 ATA、SATA、FC、SCSI、SAS，如圖1所示。這幾種磁盤中，服務器常用的是 SAS 和 FC 磁盤，一些高端存儲也使用 SSD 盤。每一種磁盤的性能是不一樣的。

性能評價指標

SAN（Storage Area Network, 存儲區域網絡）和NAS存儲（Network Attached Storage，網絡附加存儲)一般都具備2個評價指標：IOPS和帶寬（throughput），兩個指標互相獨立又相互關聯。體現存儲系統性能的最主要指標是IOPS。下面，將介紹一下這兩個參數的含義。

IOPS (Input/Output Per Second)即每秒的輸入輸出量(或讀寫次數)，是衡量磁盤性能的主要指標之一。IOPS是指單位時間內系統能處理的I/O請求數量，I/O請求通常為讀或寫數據操作請求。
隨機讀寫頻繁的應用，如OLTP(Online Transaction Processing)，IOPS是關鍵衡量指標。

什么是 OLTP ？

OLTP 也稱為面向交易的處理過程，其基本特征是前台接收的用戶數據可以立即傳送到計算中心進行處理，並在很短的時間內給出處理結果，是對用戶操作快速響應的方式之一。

特征：

支持大量並發，實時性要求很高，交易確定性，並發性要求高並且嚴格的要求事務的完整、安全性。

另一個重要指標是數據吞吐量(Throughput)，指單位時間內可以成功傳輸的數據數量。對於大量順序讀寫的應用，如VOD(Video On Demand)，則更關注吞吐量指標。

簡而言之：

磁盤的 IOPS，也就是在一秒內，磁盤進行多少次 I/O 讀寫。
磁盤的吞吐量，也就是每秒磁盤 I/O 的流量，即磁盤寫入加上讀出的數據的大小。

在知乎上看到對吞吐量的理解：

　所謂“吞”就是吃進去，“吐”就是吐出來，這一進一出就是吞吐量。比如，一秒吃進去1M bit位，同時又吐出1M bit 位，那么吞吐量 = 1M bit / 秒。不是很明白這里為什么要除以2 ？

IOPS 與吞吐量的關系

　　每秒 I/O 吞吐量＝ IOPS* 平均 I/O SIZE。

IOPS可細分為如下幾個指標：

Toatal IOPS，混合讀寫和順序隨機I/O負載情況下的磁盤IOPS，這個與實際I/O情況最為相符，大多數應用關注此指標。
Random Read IOPS，100%隨機讀負載情況下的IOPS。
Random Write IOPS，100%隨機寫負載情況下的IOPS。
Sequential Read IOPS，100%順序讀負載情況下的IOPS。
Sequential Write IOPS，100%順序寫負載情況下的IOPS。

IOPS 計算公式

對於磁盤來說一個完整的IO操作是這樣進行的：

當控制器對磁盤發出一個IO操作命令的時候，磁盤的驅動臂(Actuator Arm)帶讀寫磁頭(Head)離開着陸區(Landing Zone，位於內圈沒有數據的區域)，移動到要操作的初始數據塊所在的磁道(Track)的正上方，這個過程被稱為尋址(Seeking)，對應消耗的時間被稱為尋址時間(Seek Time);
但是找到對應磁道還不能馬上讀取數據，這時候磁頭要等到磁盤盤片(Platter)旋轉到初始數據塊所在的扇區(Sector)落在讀寫磁頭正上方的之后才能開始讀取數據，在這個等待盤片旋轉到可操作扇區的過程中消耗的時間稱為旋轉延時(Rotational Delay);
接下來就隨着盤片的旋轉，磁頭不斷的讀/寫相應的數據塊，直到完成這次IO所需要操作的全部數據，這個過程稱為數據傳送(Data Transfer)，對應的時間稱為傳送時間(Transfer Time)。完成這三個步驟之后一次IO操作也就完成了。

尋址時間：考慮到被讀寫的數據可能在磁盤的任意一個磁道，既有可能在磁盤的最內圈(尋址時間最短)，也可能在磁盤的最外圈(尋址時間最長)，所以在計算中我們只考慮平均尋址時間，也就是磁盤參數中標明的那個平均尋址時間，這里就采用當前最多的10k rpm 硬盤的5ms。

旋轉延時：和尋址一樣，當磁頭定位到磁道之后有可能正好在要讀寫扇區之上，這時候是不需要額外額延時就可以立刻讀寫到數據，但是最壞的情況確實要磁盤旋轉整整一圈之后磁頭才能讀取到數據，所以這里我們也考慮的是平均旋轉延時，對於10krpm的磁盤就是(60s/10k)*(1/2) = 2ms。

傳送時間：磁盤參數提供我們的最大的傳輸速度，當然要達到這種速度是很有難度的，但是這個速度卻是磁盤純讀寫磁盤的速度，因此只要給定了單次 IO的大小，我們就知道磁盤需要花費多少時間在數據傳送上，這個時間就是IO Chunk Size / Max Transfer Rate。

隨機讀寫頻繁的應用，如小文件存儲(圖片)、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 追求吞吐量。

個人理解：

如果要測試 IOPS 就需要定義小的 I/O size，如果要測試吞吐量則需要定義稍大的 I/O size，主要還是根據讀寫磁盤數據的大小而定。

常見磁盤平均物理尋道時間為：

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時，必須在同樣的測試基准下進行，即便如此也會產生一定的隨機不確定性。

大多數的軟件都是屬於同步I/O軟件，也就是說程序的一次I/O要等到上次I/O操作的完成后才進行，這樣在硬盤中同時可能僅只有一個命令，也是無法發揮這個技術的優勢，這時隊列深度為1。

隨着Intel的超線程技術的普及和應用環境的多任務化，以及異步I/O軟件的大量涌現。這項技術可以被應用到了，實際隊列深度的增加代表着性能的提高。

在測試時，隊列深度為1是主要指標，大多數時候都參考1就可以。實際運行時隊列深度也一般不會超過4.

IOPS可細分為如下幾個指標：

數據量為n字節，隊列深度為k時，隨機讀取的IOPS
數據量為n字節，隊列深度為k時，隨機寫入的IOPS

舉例測試

由於條件有限，我這里就只能找到兩個U 盤來進行測試，主要是演示測試方式。

測試前提：

我們在進行測試時，都會分清楚

測試對象：要區分硬盤、SSD、RAID、SAN、雲硬盤等，因為它們有不同的特點
測試指標：IOPS和MBPS(吞吐率)，下面會具體闡述
測試工具：Linux下常用Fio、dd工具, Windows下常用IOMeter,
測試參數: IO大小，尋址空間，隊列深度，讀寫模式，隨機/順序模式
測試方法：也就是測試步驟。

測試是為了對比，所以需要定性和定量。在宣布自己的測試結果時，需要說明這次測試的工具、參數、方法，以便於比較。

本次測試是采用vmware 虛擬磁盤和兩塊U 盤，測試工具為 dd 命令和 fio

vmware 虛擬機配合 u 盤進行測試：

第一塊 U盤 設備為 /dev/sdf

Apr 24 15:12:04 localhost kernel: usb 1-1: new high-speed USB device number 4 using ehci-pci
Apr 24 15:12:04 localhost kernel: usb 1-1: New USB device found, idVendor=058f, idProduct=6387, bcdDevice= 1.06
Apr 24 15:12:04 localhost kernel: usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Apr 24 15:12:04 localhost kernel: usb 1-1: Product: Mass Storage
Apr 24 15:12:04 localhost kernel: usb 1-1: Manufacturer: Generic
Apr 24 15:12:04 localhost kernel: usb 1-1: SerialNumber: BAAF2066
Apr 24 15:12:04 localhost kernel: usb-storage 1-1:1.0: USB Mass Storage device detected
Apr 24 15:12:04 localhost kernel: scsi host5: usb-storage 1-1:1.0
Apr 24 15:12:05 localhost kernel: scsi 5:0:0:0: Direct-Access     Generic  Flash Disk       8.07 PQ: 0 ANSI: 4
Apr 24 15:12:05 localhost kernel: sd 5:0:0:0: Attached scsi generic sg6 type 0
Apr 24 15:12:05 localhost kernel: sd 5:0:0:0: [sdf] 15728640 512-byte logical blocks: (8.05 GB/7.50 GiB)
Apr 24 15:12:05 localhost kernel: sd 5:0:0:0: [sdf] Write Protect is off
Apr 24 15:12:05 localhost kernel: sd 5:0:0:0: [sdf] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Apr 24 15:12:05 localhost kernel: sd 5:0:0:0: [sdf] Attached SCSI removable disk



第二塊 U盤 設備為 /dev/sdg

Apr 24 15:12:30 localhost kernel: usb 1-2: new high-speed USB device number 5 using ehci-pci
Apr 24 15:12:31 localhost kernel: usb 1-2: New USB device found, idVendor=0951, idProduct=1666, bcdDevice= 1.10
Apr 24 15:12:31 localhost kernel: usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Apr 24 15:12:31 localhost kernel: usb 1-2: Product: DataTraveler 3.0
Apr 24 15:12:31 localhost kernel: usb 1-2: Manufacturer: Kingston
Apr 24 15:12:31 localhost kernel: usb 1-2: SerialNumber: 0015F284C2ADB031E955D50B
Apr 24 15:12:31 localhost kernel: usb-storage 1-2:1.0: USB Mass Storage device detected
Apr 24 15:12:31 localhost kernel: scsi host6: usb-storage 1-2:1.0
Apr 24 15:12:32 localhost kernel: scsi 6:0:0:0: Direct-Access     Kingston DataTraveler 3.0 PMAP PQ: 0 ANSI: 6
Apr 24 15:12:32 localhost kernel: sd 6:0:0:0: Attached scsi generic sg7 type 0
Apr 24 15:12:32 localhost kernel: sd 6:0:0:0: [sdg] 30277632 512-byte logical blocks: (15.5 GB/14.4 GiB)
Apr 24 15:12:32 localhost kernel: sd 6:0:0:0: [sdg] Write Protect is off
Apr 24 15:12:32 localhost kernel: sd 6:0:0:0: [sdg] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Apr 24 15:12:32 localhost kernel: sd 6:0:0:0: [sdg] Attached SCSI removable disk


第三塊 虛擬磁盤設備為 /dev/sdb

sdb               8:16   0    2T  0 disk

順序讀

工具：fio

測試命令：fio -name iops -rw=read -bs=4k -runtime=10 -iodepth 1 -filename /dev/sdb -ioengine libaio -direct=1

【第一塊 U盤 /dev/sdf】read: IOPS=316, BW=1267KiB/s
【第二塊 U盤 /dev/sdg】read: IOPS=310, BW=1242KiB/s
【第三塊  盤 /dev/sdb】read: IOPS=8274, BW=32.3MiB/s

在對 4KB 數據包進行順序讀的情況下：

1 號U盤速度為 1.2MB/s，IOPS 為 316

2 號U盤速度為 1.2MB/S，IOPS 為 310

3 號虛擬磁盤為 32.3MB/S，IOPS 為 8274

結論：

在順序讀的測試下， U盤讀取4K 以內的小文件，簡直讓人心疼。

隨機讀

工具：fio

測試命令：fio -name iops -rw=randread -bs=4k -runtime=10 -iodepth 1 -filename /dev/sdf -ioengine libaio -direct=1

【第一塊 U盤 /dev/sdf】read: IOPS=195, BW=782KiB/s
【第二塊 U盤 /dev/sdg】read: IOPS=317, BW=1270KiB/s
【第三塊  盤 /dev/sdb】read: IOPS=6342, BW=24.8MiB/s

在對 4KB 數據包進行隨機讀的情況下：

1 號U盤速度為 782KB/s，IOPS 為 195

2 號U盤速度為 1.3MB/S，IOPS 為 317

3 號虛擬磁盤為 24.8MB/S，IOPS 為 6342

結論：

在隨機讀的測試下，2號U盤性能超越了1號U盤，虛擬磁盤依然碾壓。

順序寫

工具：fio

測試命令：fio -name iops -rw=write -bs=4k -runtime=10 -iodepth 1 -filename /dev/sdf -ioengine libaio -direct=1

【第一塊 U盤 /dev/sdf】write: IOPS=119, BW=476KiB/s
【第二塊 U盤 /dev/sdg】write: IOPS=284, BW=1138KiB/s
【第三塊  盤 /dev/sdb】write: IOPS=9065, BW=35.4MiB/s

在對 4KB 數據包進行順序寫的情況下：

1 號U盤速度為 476KB/s，IOPS 為 119

2 號U盤速度為 1.1MB/S，IOPS 為 284

3 號虛擬磁盤為 35.4MB/S，IOPS 為 9065

結論：

在順序寫的測試下，2號U盤脫穎而出,超越了第一塊U盤有3倍，虛擬磁盤依然遙遙領先。

隨機寫

工具：fio

測試命令：fio -name iops -rw=randwrite -bs=4k -runtime=10 -iodepth 1 -filename /dev/sdf -ioengine libaio -direct=1

【第一塊 U盤 /dev/sdf】write: IOPS=1, BW=7069B/s
【第二塊 U盤 /dev/sdg】write: IOPS=164, BW=657KiB/s
【第三塊  盤 /dev/sdb】write: IOPS=348, BW=1396KiB/s

在對 4KB 數據包進行隨機寫的情況下：

1 號U盤速度為 7KB/s，IOPS 為 1

2 號U盤速度為 657KB/S，IOPS 為 164

3 號虛擬磁盤為 1396MB/S，IOPS 為 348

結論：

在隨機寫的測試下， 1號 U盤是被玩壞了嗎？ 2號U盤性能也是差強人意，畢竟是U盤，而3號虛擬磁盤的性能還是能夠接受的。

順序混合讀寫

工具：fio

測試命令：fio -name iops -rw=rw -bs=4k -runtime=10 -iodepth 1 -filename /dev/sdf -ioengine libaio -direct=1

【第一塊 U盤 /dev/sdf】read: IOPS=55, BW=221KiB/s 		write: IOPS=59, BW=240KiB/s
【第二塊 U盤 /dev/sdg】read: IOPS=153, BW=612KiB/s 		write: IOPS=160, BW=644KiB/s
【第三塊  盤 /dev/sdb】read: IOPS=4426, BW=17.3MiB/s 	　　　　 write: IOPS=4397, BW=17.2MiB/s

在對 4KB 數據包進行順序混合讀寫的情況下：

1 號U盤順序讀：IOPS=55，吞吐量為：221KiB/s 　　　　順序寫 IOPS=59，吞吐量為：240KiB/s

2 號U盤順序讀：IOPS=153，吞吐量為：612KiB/s 　　　　順序寫 IOPS=160，吞吐量為：644KiB/s

3 號虛擬磁盤讀： IOPS=4426，吞吐量為：17.3MiB/s 　　順序寫 IOPS=4397，吞吐量為：17.2MiB/s

結論：

在順序混合讀寫的測試下，性能對比排名：虛擬磁盤 > 2號U盤 > 1號U盤

隨機混合讀寫

工具：fio

測試命令：fio -name iops -rw=randrw -bs=4k -runtime=10 -iodepth 1 -filename /dev/sdf -ioengine libaio -direct=1

【第一塊 U盤 /dev/sdf】read: IOPS=88, BW=352KiB/s 		write: IOPS=92, BW=369KiB/s
【第二塊 U盤 /dev/sdg】read: IOPS=151, BW=608KiB/s 		write: IOPS=159, BW=637KiB/s
【第三塊  盤 /dev/sdb】read: IOPS=4586, BW=17.9MiB/s 	write: IOPS=4558, BW=17.8MiB/s

在對 4KB 數據包進行隨機混合讀寫的情況下：

1 號U盤順序讀：IOPS=88，吞吐量為：352KiB/s 　　　　順序寫 IOPS=92，吞吐量為：369KiB/s

2 號U盤順序讀：IOPS=151，吞吐量為：608KiB/s 　　　　順序寫 IOPS=159，吞吐量為：637KiB/s

3 號虛擬磁盤讀： IOPS=4586，吞吐量為：17.9MiB/s 　　順序寫 IOPS=4558，吞吐量為：17.8MiB/s

結論：

在順序混合讀寫的測試下，性能對比排名：虛擬磁盤 > 2號U盤 > 1號U盤

總結：

以上測試，是根據 I/O SIZE = 4k 來進行測試的，對於小文件，應該重點關注的是磁盤的 IOPS 性能。拋開虛擬磁盤不說，兩塊U盤的IOPS 和吞吐量已經非常清晰了，孰強孰弱也很容易分辨出來。

存儲系統模型
為了更好的測試，我們需要先了解存儲系統，塊存儲系統本質是一個排隊模型，我們可以拿銀行作為比喻。還記得你去銀行辦事時的流程嗎？

去前台取單號
等待排在你之前的人辦完業務
輪到你去某個櫃台
櫃台職員幫你辦完手續1
櫃台職員幫你辦完手續2
櫃台職員幫你辦完手續3
辦完業務，從櫃台離開

如何評估銀行的效率呢：

增加櫃台數
降低服務時間

因此，排隊系統或存儲系統的優化方法是：

增加並行度
降低服務時間

在服務器中，這種模型是很常見的，比如web服務器。

硬盤測試

硬盤原理

我們應該如何測試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。

我們在列出IOPS時，需要說明IO大小，尋址空間，讀寫模式，順序/隨機，隊列深度。我們一般常用的IO大小是4KB，這是因為文件系統常用的塊大小是4KB。

使用 dd 測試硬盤

雖然硬盤的性能是可以估算出來的，但是怎么才能讓應用獲得這些性能呢？對於測試工具來說，就是如何得到IOPS和MBPS峰值。我們先用dd測試一下磁盤的MBPS(吞吐量)。

dd測試

# dd if=/dev/zero of=/dev/sdb bs=4k count=100000 oflag=direct 
100000+0 records in
100000+0 records out
409600000 bytes (410 MB) copied, 7.13428 s, 57.4 MB/s

iostat 查看磁盤性能

執行命令：iostat  -dxk /dev/sdb 1
Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdb               0.00     0.00    0.00 14264.00     0.00 57056.00     8.00     0.82    0.06    0.00    0.06   0.06  82.10

本次測試使用的是虛擬磁盤，使用 dd 測試這塊虛擬磁盤的 MBPS 只有 57.4MB/S，通過 iostat 查看磁盤狀態，發現磁盤利用率只有 82.10% 並沒有達到 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/sdb bs=2M count=1000 oflag=direct 
1000+0 records in
1000+0 records out
2097152000 bytes (2.1 GB) copied, 7.65746 s, 274 MB/s


iostat 查看
Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdb               0.00     0.00    0.00  339.00     0.00 173568.00  1024.00     1.62    5.13    0.00    5.13   2.90  98.40

可以看到2MB的IO到達底層之后，會變成多個512KB的IO，平均隊列長度為1.73，這個硬盤的利用率是99%，MBPS達到了207MB/s。(為什么會變成512KB的IO，你可以去使用Google去查一下內核參數 max_sectors_kb的意義和使用方法 )

也就是說增加隊列深度，是可以測試出硬盤的峰值的。

使用 fio 測試硬盤

測試下SATA硬盤的4KB隨機寫的IOPS。使用工具：fio

測試命令及說明：

#fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=randwrite -size=2000G -filename=/dev/sdb -name "vdisk 4k test" -iodepth=1 -runtime 10
簡單介紹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.920ms

橙色：硬盤利用率達到 98.58%

-iodepth=4

藍色：IOPS = 230

綠色：每個IO請求平均耗時：17.3ms

黃色：95%的IO請求響應時間小於 25.47ms

橙色：硬盤利用率達到 99.76%

對面兩次測試數據，發現這次測試的IOPS沒有提高，反而IO平均響應時間變大了，是17ms。

為什么這里提高隊列深度沒有作用呢，原因當隊列深度為1時，硬盤的利用率已經達到了98%，說明硬盤已經沒有多少空閑時間可以壓榨了。而且響應時間為 4ms。對於SATA硬盤，當增加隊列深度時，並不會增加IOPS，只會增加響應時間。這是因為硬盤只有一個磁頭，並行度是1，所以當IO請求隊列變長時，每個IO請求的等待時間都會變長，導致響應時間也變長。

最后，注意下

/sys/block/sdb/queue/max_sectors_kb

這個參數，通過 max_sectors_kb = 256 可以降低延遲，然后增加測試隊列深度可以測試出磁盤的極限吞吐量，手里沒有獨立的磁盤，因此無法得到驗證。

參考鏈接：

https://blog.51cto.com/wushank/1708168

https://blog.csdn.net/hanchengxi/article/details/19089589

免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。

猜您在找 吞吐量和Iops、測試工具FIO使用 IxChariot：網絡吞吐量及延遲)測試工具 IOPS 使用FIO工具測試 tcp/udp並發（大吞吐量）性能測試工具磁盤性能指標--IOPS、吞吐量及測試 tcp並發，吞吐量，socks5性能測試工具 sysbench測試阿里雲ECS雲磁盤的IOPS,吞吐量性能測試--吞吐量 Kafka吞吐量測試嵌入式Linux設備使用iperf工具進行WiFi吞吐量測試