fio 測試中的 iodepth 到底是什麼意思？是隊列深度嗎？

我了解隊列深度，即儲存控制器可以處理的未完成 I/O 請求的數量（https://www.tomshardware.com/reviews/ssd-gaming-performance,2991-3.html），即這是對處理 I/O 請求並將命令發送到磁碟 (r/w) 的儲存控制器的限制，如果有超過它可以處理的請求（將由客戶端重新送出），它（不嚴格？）會丟棄請求想必）。

並且具有高超出 I/O 請求的原因可能是多個客戶端連接請求 I/O 或多個程序，即使來自單個主機請求 I/O（我認為，但似乎作業系統使用 I/O 調度程序合併 I/ O 請求 - 在進行定期或按需同步時源自緩衝區，並且僅發送固定數量的 outstading 請求，這樣就不會使儲存設備過載？）

現在，來到 fio 手冊頁中 iodepth 的定義：

要針對文件保持執行的 I/O 單元數。請注意，將 iodepth 增加到 1 以上不會影響同步 ioengine（使用 verify_async 時的小度數除外）。

這符合我對隊列深度的理解。如果 IO 是同步的（阻塞 IO），我們可以只有一個隊列。

甚至非同步引擎也可能會施加作業系統限制，導致無法達到所需的深度。這可能在 Linux 上使用 libaio 而未設置 `direct=1’ 時發生，因為緩衝 I/O 在該作業系統上不是非同步的。

對整個聲明感到困惑。

密切關注 fio 輸出中的 I/O 深度分佈，以驗證達到的深度是否符合預期。預設值：1。

我為每種 iodepth 和設備類型執行了多個測試，有 22 個並行作業，因為 CPU 計數為 24，並且 rwtype：順序讀取和順序寫入。Iodepths 是 1,16,256,1024,32768（我知道 32 或 64 應該是最大限制，我只是想嘗試一下）。

對於所有深度和所有磁碟（RAID 6 SSD、NVME 和 NFS），結果幾乎相同：除了在 32768 深度的 NVME 磁碟上順序讀取。

IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=99.9%
submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%

對於 32768 深度的 NVME，

complete  : 0=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=100.0%

我在 fio 中使用了 libaio 引擎（因為我不確定我需要為非同步 I/O 測試提供什麼 IO 引擎，而 libaio 似乎是正確的。這完全是一個不同的問題）

發生什麼了？為什麼送出並完成顯示 1-4 （除了一次執行的 NVME >64）

[global]
lockfile=none
kb_base=1024
fallocate=posix
blocksize=64k
openfiles=100
ioengine=libaio
buffered=1
invalidate=1
loops=5
randrepeat=1
size=512M
numjobs=22

[sr-iodepth-1]
description="Sequential Write,Parallel jobs-22,IO depth-1,libaio"
readwrite=write
size=5G
iodepth=1

[sr-iodepth-16]
description="Sequential Write,Parallel jobs-22,IO depth-16,libaio"
readwrite=write
size=5G
iodepth=16

[sr-iodepth-256]
description="Sequential Write,Parallel jobs-22,IO depth-256,libaio"
readwrite=write
size=5G
iodepth=256

[sr-iodepth-1024]
description="Sequential Write,Parallel jobs-22,IO depth-1024,libaio"
readwrite=write
size=5G
iodepth=1024

[sr-iodepth-32768]
description="Sequential Write,Parallel jobs-22,IO depth-32768,libaio"
readwrite=write
size=5G
iodepth=32768


[sw-iodepth-1]
description="Sequential Read,Parallel jobs-22,IO depth-1,libaio"
readwrite=read
size=512M
iodepth=1

[sw-iodepth-16]
description="Sequential Read,Parallel jobs-22,IO depth-16,libaio"
readwrite=read
size=512M
iodepth=16

[sw-iodepth-256]
description="Sequential Read,Parallel jobs-22,IO depth-256,libaio"
readwrite=read
size=512M
iodepth=256

[sw-iodepth-1024]
description="Sequential Read,Parallel jobs-22,IO depth-1024,libaio"
readwrite=read
size=512M
iodepth=1024

[sw-iodepth-32768]
description="Sequential Read,Parallel jobs-22,IO depth-32768,libaio"
readwrite=read
size=512M
iodepth=32768

（請不要在一篇文章中提出多個問題——這會讓回答變得非常困難……）

隊列深度，即未完成的 I/O 請求數

$$ … $$它處理 I/O 請求並將命令發送到磁碟（r/w）並且它（不嚴格？）丟棄請求

過多的請求通常不會被丟棄——設備中沒有地方將它們排隊，所以其他東西（例如作業系統）必須保留它們並在空間可用時送出它們。他們沒有迷失，只是不被接受。

以及高出眾的原因

$$ sic $$I/O 請求

有許多不同的原因 - 您列出了其中之一。例如，設備可能很慢（想想老式的 SD 卡），即使有一個“客戶端”也無法跟上。

只有固定數量的outstading

$$ sic $$請求，以免儲存設備過載？）

這是目標，但沒有什麼可以說設備將能夠跟上（有時有一些原因/配置不會發生合併）。

> > 甚至非同步引擎也可能會施加作業系統限制，導致無法達到所需的深度。這可能在 Linux 上使用 libaio 而未設置 `direct=1’ 時發生，因為緩衝 I/O 在該作業系統上不是非同步的。 > > >

對整個聲明感到困惑。

Linux 的一個怪癖是非O_DIRECTI/O（預設）通過緩衝區高速記憶體（這就是所謂的緩衝 I/O）。正因為如此，即使您認為您已經非同步送出（通過使用 Linux AIO），您實際上最終只是以同步行為結束。有關不同措辭的解釋，請參閱https://github.com/axboe/fio/issues/512#issuecomment-356604533。

為什麼送出並完成顯示 1-4

你的配置有這個：

buffered=1

你沒有註意到你之前想知道的警告！buffered=1是一樣的說法direct=0。即使您確實有direct=1，預設情況下fio一次送出一個 I/O，因此如果您的設備速度如此之快以至於它在​​下一個排隊之前完成了 I/O，您可能不會看到高於 1 的深度。如果您希望強制/保證批量送出，請參閱HOWTO/manualiodepth_batch_*中提到的選項fio。

好的，回到標題中的問題：

fio 測試中的 iodepth 到底是什麼意思？

這是fio將嘗試在內部排隊的未完成 I/O 的最大數量（但請注意，fio由於上面和下面給出的原因，可能永遠無法達到它）。

是嗎

$$ iodepth $$隊列深度？

也許更進一步，它還取決於您所說的“隊列深度”是什麼意思。如果您的意思是avgqu-sz由諸如 Linux 之類的工具報告的，iostat那麼根據所使用的 ioengine、與該 I/O 引擎一起使用的選項、I/O 的類型和样式等因素，它們iodepth 可能相似或大不相同送出，它必須經過的層，直到它達到被報告的級別等。

我想你已經在很多不同的地方問過這些問題的變化——例如，fio 郵件列表對上述一些問題有答案——而且郵件提到你也在 https://unix.stackexchange.com/questions /459045/what-exactly-is-iodepth-in-fio。您可能需要小心，因為您可能會讓人們回答實際上已經在其他地方回答過的問題，並且您沒有將它們聯繫在一起，這使得發現重複的答案變得困難……

引用自：https://serverfault.com/questions/923487