在發布了關於微軟在 Windows Server 2025 中可選原生 NVMe 功能的文章後，我們收到了許多請求，希望我們直接比較 Windows Server 2025（支援原生 NVMe）和基於 Linux 的伺服器作業系統之間的儲存效能。一位特別熱情的 Reddit 用戶甚至提出請我們喝啤酒！由於顯然沒有其他合理的選擇，我們決定在 Linux 上執行相同的測試。
很久很久以前，在一個遙遠的作業系統版本中
Linux 核心自 2012 年 3 月發布的3.3 版本起就支援 NVMe。同樣，Windows Server 自 2012 R2 版本（大約在 2013 年 10 月）起也開始支持該協定（非原生支持，透過 SCSI 轉換）。十多年過去了，用戶仍在爭論 Windows 和 Linux 哪個更適合存儲，因此我們決定透過對比兩者的基準測試結果，為這場爭論火上澆油。
由於我們已取得在 Windows Server 2025 上使用非原生和原生儲存堆疊的測試結果，因此我們認為有必要在 Linux 上評估兩種儲存堆疊。在 FIO 基準測試中，我們使用了 libaio 和 io_uring，這兩種 API 是目前最受歡迎的儲存事務 API。雖然 io_uring 更新，並且在非同步 I/O 方面進行了許多改進，但 libaio 因其靈活性和易用性仍然被廣泛使用（Didona、Pfefferle、Ioannou、Metzler 和 Trivedi，2022）。本文篇幅有限，無法對兩種儲存棧進行完整的架構概述，但我們仍將提供測試結果以便進行直接比較。
在 Ubuntu Server 24.04.4 LTS 上測試 NVMe
本次比較測試所使用的硬體平台與我們先前發佈的Windows Server 2025 原生 NVMe 文章中所使用的伺服器相同。為了確保最大吞吐量和一致的測試結果，該伺服器配備了兩顆 128 核 AMD EPYC 9754 CPU、768GB 4800 MT/s DDR5 內存，以及十五塊30.72 TB Solidigm P5316 NVMe SSD（採用 PCIe 4.0），並以 JBOD 配置進行連接。
正如我們在先前的文章中提到的，Solidigm P5316 的間接單元大小為 64 KB，這意味著對於較小區塊大小（例如 4K 測試）的寫入效能通常比預期要差。我們再次運行了不同區塊大小（4K、64K 和 128K）的測試模式，以提供更廣泛的讀寫操作結果。
我們選擇 Ubuntu Server 24.04.4 LTS 作為 Linux 範例，是因為它廣受歡迎且擁有長期支援。它預設運行在 Linux 核心 6.8 上，雖然這並非最新或最先進的版本，但很可能代表了全球大部分 Linux 安裝量。
- Windows Server 2025 原生 NVMe 在四項讀取效能基準測試中的三項中勝出。
- 在大多數測試中，Windows Server 的 CPU 使用率較低。
- Ubuntu Server 24.04.4 LTS 在四項寫入效能基準測試中的三項中勝出。
| 公制 | 隨機 4K | 隨機 64K | ||||||
|---|---|---|---|---|---|---|---|---|
| Windows 非原生 | Windows 原生 | Linux libaio | Linux io_uring | Windows 非原生 | Windows 原生 | Linux libaio | Linux io_uring | |
| 隨機閱讀 | ||||||||
| 頻寬（GiB/s） | 6.1 | 10.058 | 9.198 | 9.504 | 74.291 | 91.165 | 77.517 | 77.7 |
| IOPS | 1,598,959 | 2,636,516 | 2,411,000 | 2,491,000 | 1,217,176 | 1,493,637 | 1,270,000 | 1,273,000 |
| 平均延遲（毫秒） | 0.169 | 0.104 | 0.198 | 0.192 | 0.239 | 0.207 | 0.377 | 0.376 |
| CPU 總使用率 (%) | 72.67 | 74.22 | 99.77 | 99.76 | 68.44 | 65.11 | 83.16 | 84.72 |
| 公制 | 順序 64K | 順序 128K | ||||||
|---|---|---|---|---|---|---|---|---|
| Windows 非原生 | Windows 原生 | Linux libaio | Linux io_uring | Windows 非原生 | Windows 原生 | Linux libaio | Linux io_uring | |
| 順序閱讀 | ||||||||
| 頻寬（GiB/s） | 35.596 | 35.623 | 31.867 | 31.433 | 86.791 | 92.562 | 97.05 | 97 |
| IOPS | 583,192 | 583,638 | 522,000 | 515,000 | 710,978 | 758,252 | 795,000 | 795,000 |
| 平均延遲（毫秒） | 0.809 | 0.812 | 0.919 | 0.932 | 0.613 | 0.608 | 0.603 | 0.604 |
| CPU 總使用率 (%) | 44.89 | 37.11 | 53.94 | 41.74 | 61.56 | 49.56 | 75.14 | 76.90 |
| 公制 | 隨機 4K | 隨機 64K | ||||||
|---|---|---|---|---|---|---|---|---|
| Windows 非原生 | Windows 原生 | Linux libaio | Linux io_uring | Windows 非原生 | Windows 原生 | Linux libaio | Linux io_uring | |
| 隨機寫入 | ||||||||
| 頻寬（GiB/s） | 1.803 | 1.756 | 1.876 | 1.815 | 7.654 | 7.655 | 7.652 | 7.651 |
| IOPS | 472,725 | 460,383 | 492,000 | 476,000 | 125,391 | 125,406 | 125,000 | 125,000 |
| 平均延遲（毫秒） | 0.992 | 1.028 | 0.974 | 1.007 | 3.814 | 3.816 | 3.827 | 3.828 |
| CPU 總使用率 (%) | 26.00 | 20.67 | 45.76 | 22.80 | 12.22 | 9.33 | 20.07 | 10.90 |
| 公制 | 順序 64K | 順序 128K | ||||||
|---|---|---|---|---|---|---|---|---|
| Windows 非原生 | Windows 原生 | Linux libaio | Linux io_uring | Windows 非原生 | Windows 原生 | Linux libaio | Linux io_uring | |
| 順序寫入 | ||||||||
| 頻寬（GiB/s） | 44.67 | 50.087 | 52.283 | 52.25 | 50.477 | 50.079 | 52 | 52.083 |
| IOPS | 731,859 | 820,603 | 856,000 | 856,000 | 413,495 | 410,232 | 426,000 | 427,000 |
| 平均延遲（毫秒） | 0.399 | 0.558 | 0.560 | 0.560 | 1.022 | 1.149 | 1.126 | 1.125 |
| CPU 總使用率 (%) | 70.44 | 57.78 | 61.88 | 62.75 | 58.44 | 47.33 | 61.49 | 44.27 |
請注意： 由於 Windows Server 2025 和 Ubuntu Server 24.04.4 LTS 的 FIO 報告方式不同，我們的 Linux IOPS 結果會四捨五入到千位。頻寬、延遲和 CPU 使用率結果在兩個平台上均採用一致的四捨五入方式。
數字不會說謊
我們立即發現，Ubuntu 並非在所有方面都優於 Windows。雖然 libaio 和 io_uring 在我們的隨機讀取頻寬測試中表現出色，但它們的效能仍不如微軟原生 NVMe 協定堆疊。在我們的 64K 隨機讀取測試中，Windows NT 核心的效能比 Linux 核心高出約 17%，原生 NVMe 的讀取速度達到了 91.165 GiB/s，而 io_uring 的最佳成績為 77.7 GiB/s。
然而，托瓦茲的技術恐怖並非完全沒有希望。在我們的一項讀取效能基準測試－順序 128K 測試中，Ubuntu Server 險勝 Windows Server。在此測試中，Linux 的 libaio 效能最佳，達到 97.05 GiB/s，而 Windows 的原生 NVMe 為 92.562 GiB/s，兩者相差約 5%。這表明，在管理大於磁碟機間接單元大小的區塊時，Linux 可能略佔優勢。
在Linux和Windows系統下，隨機寫入頻寬表現一致，尤其是在64K基準測試中。這些測試的最佳和最差結果僅相差0.05%，顯示所有儲存堆疊都充滿了硬碟的全部效能。
有趣的是，Linux 6.8 核心在 64K 和 128K 區塊大小的順序寫入頻寬測試中取得了勝利。雖然差距並不大，但開源軟體堆疊在這兩種情況下都比 Windows Server 的原生 NVMe 高出約 2 GiB/s。
延遲測試結果總體上與吞吐量測試結果一致，隨機讀取平均值的差異最能反映這一點。遺憾的是，對於 Tux 而言，libaio 和 io_uring 的延遲較高，其中 Windows Server 原生 NVMe（0.207 毫秒）和 libaio（0.377 毫秒）在 64K 次隨機讀取測試中的最大延遲差異為 0.17 毫秒。
基準測試中最令人震驚的發現或許是 Windows Server 2025 和 Ubuntu Server 24.04.4 LTS 之間 CPU 使用率的巨大差異。在四項隨機和順序讀取基準測試中，有三項測試顯示 Windows Server 原生 NVMe 的 CPU 使用率最低。最顯著的結果出現在 128K 順序讀取基準測試中，Windows 的 CPU 使用率比 Linux 低 27.34%。
在隨機寫入和順序寫入測試中，使用 libaio 和 io_uring 的 CPU 使用率略有提升，但仍不足以阻止 Windows Server 上的原生 NVMe 在三項基準測試中勝出。值得注意的是，libaio 在 4K 隨機寫入測試中的 CPU 使用率達到了系統 CPU 的 45.76%，而其他儲存方案的 CPU 使用率則徘徊在 20% 左右。
CPU晚宴，優勝者！
我們的測試結果顯示，在不同區塊大小的隨機和順序效能測試中，Windows Server 和 Ubuntu Server 的效能非常接近。在頻寬方面，採用原生 NVMe 的 Windows Server 2025 在大多數讀取測試中通常優於 Linux，而 Linux 在寫入測試中的表現略勝一籌。延遲測試結果也印證了這一點，但真正的亮點在於 Windows Server 2025 在使用原生 NVMe 時的 CPU 效率。
微軟顯然投入了大量精力，力求打造其最新的儲存堆棧，雖然它並非總能勝過 libaio 和 io_uring，但表現可圈可點。儘管這些結果並非適用於所有用例和伺服器配置，但當儲存效能比作業系統相容性更為重要時，它們或許能夠幫助伺服器管理員決定部署 Windows 伺服器還是 Linux 伺服器。
歡迎在我們的社群平台或SR Discord伺服器上留言，告訴我們您對這些測試結果的看法！您是否預料到Windows Server會在我們的測試中表現如此出色？還是您更看好Linux？您是否希望看到更多Linux伺服器發行版或核心的測試？我們始終期待您的回饋，而像這樣應讀者要求進行的測試往往會成為我們最受歡迎的文章。
參考
Didona, D., Pfefferle, J., Ioannou, N., Metzler, B., & Trivedi, A. (2022年6月13日). 理解現代儲存API：libaio、SPDK和io_uring的系統研究。 SYSTOR '22, 120-121。2026年4月3日檢索自https://atlarge-research.com/pdfs/2022-systor-apis.pdf
Amazon