带有L2ARC（SSD）的ZFS对于随机search比没有L2ARC要慢

我目前正在testingZFS（Opensolaris 2009.06）在一个较旧的文件服务器，以评估其使用我们的需要。我们目前的设置如下：

双核（2,4 GHz），带有4 GB RAM
带有11个HDD（250 GB）的3个SATA控制器和一个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运行IOtesting，大小设置为200 GB（-s 200g），这样testing样本将永远不会完全在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变得有趣。我的假设是，结果应该是在最坏的情况下，至less是一样的。虽然写入/读取/重写率没有区别，但随机查找率在各个bonnie ++运行（到目前为止在188 / s和1333 / s之间）之间显着不同，平均值为548±200 / s，因此低于w / o SSD。

所以，我的问题主要是：

为什么随机查找率差异如此之大？如果这些追求真的是随机的，那么它们应该没什么太大的区别（我的假设）。所以，即使SSD损害性能，它应该在每个bonnie ++运行中都是一样的。
为什么在大多数bonnie ++运行中，随机查找性能会变差？我假设Bonnie ++数据的某些部分在L2ARC和随机寻找的这个数据上执行的更好，而随机寻找其他数据就像以前一样执行。

不知道为什么你看到了你所看到的行为，但我可以告诉你为什么他们不一定意味着可怕的真实世界的ZFSperformance。 Bonnie旨在衡量实际磁盘的性能，并故意尝试不利用磁盘/内存caching。您正试图使用它来衡量磁盘caching。

L2ARC设备可能需要几个小时才能变热。取决于您拥有多less主内存以及工作负载的磁盘性能，一个用于L2ARC的100GB固态硬盘将需要1-2小时才能变热，甚至更长（来源）。其次L2Arc被devise为caching随机读取，而不是stream式读取工作负载。 “如果您使用L2ARC进行stream式或顺序工作负载，那么L2ARC将主要忽略它，而不是将其caching”（来源）。如果你的bonnie工作负荷大部分都进入了L2ARC，我会非常惊讶。尝试生成类似于系统实际使用的负载，而不是使用bonnie ++。

虽然不太可能，但运行Bonnie ++的最新开发版本（1.96 vs 1.03d）可能会产生更接近您的预期结果的东西。你可能也想看看这个Sun的博客文章，关于使用Sun 7000系列的bonnie ++ ，尽pipe它们是通过NFS而不是本地运行的。

您也可以在SSD中的L2ARC中启用stream式数据caching。

l2arc_noprefetch参数对此非常有用。

此可调参数决定stream数据是否被caching。默认不cachingstream式数据（默认值为true）。如果将其设置为false，则可能会看到L2ARCcaching命中率显着增加。