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

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

我在 RAID 控制器后面设置了一台 Solaris Express 11 机器,该机器带有一些速度相当快的 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 内存,效果很好 —— 即使在 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

谢谢尤怀特

答案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).

相关内容