Solaris ZFS 卷：工作负载未达到 L2ARC

Question

我设置了一台 Solaris Express 11 机器，在 RAID 控制器后面有一些相当快的 HDD，将设备设置为启用压缩的 zpool，并向其中添加了一个镜像日志和 2 个缓存设备。数据集作为 FC 目标公开以与 ESX 一起使用，我已经用一些数据填充了它以进行处理。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。

Answer 1

您应该在系统中有更多的 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).