Solaris ZFS 卷：工作負載未達到 L2ARC
我在 RAID 控制器後面設置了一個帶有一些相當快的 HDD 的 Solaris Express 11 機器，將設備設置為啟用壓縮的 zpool，並向其添加了一個鏡像日誌和 2 個記憶體設備。這些數據集公開為與 ESX 一起使用的 FC 目標，並且我在其中填充了一些數據以供使用。L2ARC 部分填滿（由於某種原因不再填滿），但我幾乎看不到它有任何用途。
zpool iostat -v表明過去從記憶體中讀取的內容不多：tank 222G 1.96T 189 84 994K 1.95M c7t0d0s0 222G 1.96T 189 82 994K 1.91M mirror 49.5M 5.51G 0 2 0 33.2K c8t2d0p1 - - 0 2 0 33.3K c8t3d0p1 - - 0 2 0 33.3K cache - - - - - - c11d0p2 23.5G 60.4G 2 1 33.7K 113K c10d0p2 23.4G 60.4G 2 1 34.2K 113K啟用 L2ARC的arcstat.pl腳本顯示目前工作負載的 L2ARC 100% 未命中：
./arcstat.pl -f read,hits,miss,hit%,l2read,l2hits,l2miss,l2hit%,arcsz,l2size 5 read hits miss hit% l2read l2hits l2miss l2hit% arcsz l2size [...] 243 107 136 44 136 0 136 0 886M 39G 282 144 137 51 137 0 137 0 886M 39G 454 239 214 52 214 0 214 0 889M 39G [...]我首先懷疑這可能是記錄大小太大的影響，因此 L2ARC 將所有內容都辨識為流式負載，但 zpool 只包含 zfs 卷（我已將它們創建為“稀疏”使用
zfs create -V 500G -s <datasetname>），甚至沒有要更改的記錄集參數。我還發現了許多關於 L2ARC 的元數據每條記錄需要 200 字節 RAM 的概念，但到目前為止，我還無法找出 L2ARC 將什麼視為具有捲數據集的“記錄”——一個 512 字節的單個扇區？可能是因為元數據的 RAM 短缺而被填滿了再也不會被讀取的垃圾嗎？
**編輯：**在已經安裝的 2 GB 的基礎上添加 8 GB 的 RAM 效果很好 - 即使在 32 位安裝中也可以愉快地使用額外的 RAM，並且 L2ARC 現在已經增長並受到打擊：
time read hit% l2hit% arcsz l2size 21:43:38 340 97 13 6.4G 95G 21:43:48 185 97 18 6.4G 95G 21:43:58 655 91 2 6.4G 95G 21:44:08 432 98 16 6.4G 95G 21:44:18 778 92 9 6.4G 95G 21:44:28 910 99 19 6.4G 95G 21:44:38 4.6K 99 18 6.4G 95G感謝ewwhite。
您應該在系統中有更多的 RAM。指向 L2ARC 的指針需要保存在 RAM (ARC) 中，因此我認為您需要大約 4GB 或 6GB 的 RAM 才能更好地利用可用的 ~60GB L2ARC。
這是來自 ZFS 列表上的一個最新執行緒：
http://opensolaris.org/jive/thread.jspa?threadID=131296
L2ARC is "secondary" ARC. ZFS attempts to cache all reads in the ARC (Adaptive Read Cache) - should it find that it doesn't have enough space in the ARC (which is RAM-resident), it will evict some data over to the L2ARC (which in turn will simply dump the least-recently-used data when it runs out of space). Remember, however, every time something gets written to the L2ARC, a little bit of space is taken up in the ARC itself (a pointer to the L2ARC entry needs to be kept in ARC). So, it's not possible to have a giant L2ARC and tiny ARC. As a rule of thumb, I try not to have my L2ARC exceed my main RAM by more than 10-15x (with really bigMem machines, I'm a bit looser and allow 20-25x or so, but still...). So, if you are thinking of getting a 160GB SSD, it would be wise to go for at minimum 8GB of RAM. Once again, the amount of ARC space reserved for a L2ARC entry is fixed, and independent of the actual block size stored in L2ARC. The jist of this is that tiny files eat up a disproportionate amount of systems resources for their size (smaller size = larger % overhead vis-a-vis large files).