我目前正在较旧的文件服务器中测试 ZFS (Opensolaris 2009.06),以评估其是否符合我们的需求。我们当前的设置如下:
- 双核 (2.4 GHz),4 GB RAM
- 3x 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,因此低于不使用 SSD 的值。
所以,我的问题主要是:
- 为什么随机寻道率相差这么大?如果寻道真的是随机的,它们应该不会相差太大(我的假设)。因此,即使 SSD 损害了性能,每次运行 bonnie++ 时也应该相同。
- 为什么在大多数 bonnie++ 运行中随机寻道性能较差?我认为部分 bonnie++ 数据位于 L2ARC 中,并且对该数据的随机寻道性能更好,而对其他数据的随机寻道性能与以前类似。
答案1
不确定您为什么会看到这种行为,但我可以告诉您为什么它们并不一定表示现实世界中 ZFS 性能糟糕。Bonnie 旨在测量实际磁盘的性能,并有意尝试不利用磁盘/内存缓存。您正尝试使用它来测量磁盘缓存。
L2ARC 设备可能需要几个小时才会变热。根据您为 ARC 准备的主内存大小以及工作负载下的磁盘性能,用于 L2ARC 的 100GB SSD 需要 1-2 小时才会变热,甚至可能需要更长时间(来源)。其次,L2Arc 旨在缓存随机读取,而不是流式读取工作负载。“如果您将 L2ARC 用于流式或顺序工作负载,则 L2ARC 将主要忽略它而不是缓存它”(来源)。 我会真的如果您的大部分 bonnie 工作负载进入了 L2ARC,您会感到惊讶。不要使用 bonnie++,而是尝试生成类似于您实际使用系统的负载。
虽然不太可能,但运行Bonnie++ 的最新开发版本(1.96 vs 1.03d)可能会产生更接近您预期的结果。您可能还想查看这篇关于Sun 7000 系列的 bonnie++,尽管它们是通过 NFS 运行而不是在本地运行。
答案2
您还可以在 SSD 中的 L2ARC 中启用流数据缓存。
l2arc_noprefetch 参数对此很有用。
此可调参数决定是否缓存流数据。默认不缓存流数据(默认值为 true)。如果将其设置为 false,您可能会看到 L2ARC 缓存命中率显著增加。