帶有 L2ARC (SSD) 的 ZFS 隨機尋軌比不帶 L2ARC 的要慢
我目前正在舊文件伺服器中測試 ZFS (Opensolaris 2009.06)，以評估它對我們需求的使用。我們目前的設置如下：
- 雙核 (2,4 GHz) 與 4 GB RAM
- 3 個 SATA 控制器，帶 11 個 HDD (250 GB) 和一個 SSD (OCZ Vertex 2 100 GB)
我們要評估 L2ARC 的使用，所以目前的 ZPOOL 是：
$ zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM afstank ONLINE 0 0 0 raidz1 ONLINE 0 0 0 c11t0d0 ONLINE 0 0 0 c11t1d0 ONLINE 0 0 0 c11t2d0 ONLINE 0 0 0 c11t3d0 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 c13t0d0 ONLINE 0 0 0 c13t1d0 ONLINE 0 0 0 c13t2d0 ONLINE 0 0 0 c13t3d0 ONLINE 0 0 0 cache c14t3d0 ONLINE 0 0 0其中 c14t3d0 是 SSD（當然）。我們使用 bonnie++ 1.03d 執行 IO 測試，大小設置為 200 GB (-s 200g)，因此測試樣本永遠不會完全在 ARC/L2ARC 中。沒有 SSD 的結果是（幾次執行的平均值，沒有差異）
write_chr write_blk rewrite read_chr read_blk random seeks 101.998 kB/s 214.258 kB/s 96.673 kB/s 77.702 kB/s 254.695 kB/s 900 /s有了 SSD，它就變得有趣了。我的假設是，在最壞的情況下，結果應該至少是相同的。雖然寫入/讀取/重寫速率沒有差異，但各個 bonnie++ 執行之間的隨機尋軌速率差異很大（目前介於 188 /s 和 1333 /s 之間），平均值為 548 +- 200 /s，因此低於 w/o 的值固態硬碟。
所以，我的問題主要是：
- 為什麼隨機搜尋率差異如此之大？如果搜尋真的是隨機的，它們應該差別不大（我的假設）。因此，即使 SSD 會損害性能，它在每次 bonnie++ 執行中都應該是相同的。
- 為什麼在大多數 bonnie++ 執行中隨機搜尋性能更差？我會假設 bonnie++ 數據的一部分在 L2ARC 中，並且對這些數據的隨機搜尋性能更好，而對其他數據的隨機搜尋性能與以前類似。
不知道為什麼你會看到你所看到的行為，但我可以告訴你為什麼它們不一定表明現實世界的 ZFS 性能很糟糕。Bonnie 旨在測量實際磁碟的性能，並有意嘗試不利用磁碟/記憶體記憶體。您正在嘗試使用它來測量磁碟記憶體。
L2ARC 設備可能需要數小時才能變熱。根據 ARC 的主記憶體數量和工作負載的磁碟性能，用於 L2ARC 的 100GB SSD 需要 1-2 小時才能變熱，甚至可能更長（來源）。其次，L2Arc 旨在記憶體隨機讀取，而不是流式讀取工作負載。“如果您將 L2ARC 用於流式或順序工作負載，那麼 L2ARC 將主要忽略它而不記憶體它”（來源）。如果您的大部分工作量都進入 L2ARC，我會感到*非常驚訝。*嘗試生成類似於您對系統的實際使用的負載，而不是使用 bonnie++。
儘管不太可能，但執行Bonnie++ 的最新開發版本（1.96 與 1.03d）可能會產生更接近您預期的結果。您可能還想查看這篇關於Sun 7000 系列的 bonnie++ 的sun 部落格文章，儘管它們通過 NFS 而不是本地執行。