主页 / server / 问题 / 895137
Accepted
Ajay
Asked: 2018-02-02 01:37:42 +0800 CST

ZFS：配置建议 1x NVMe 作为 ARC 和 ZIL，4x SSD 用于 zvols 用于虚拟化

  • 772

所以最近在测试一个 ZoL 系统时，我们发现我们的 SSD 上随机和顺序读取的性能很差，随机写入的性能很差。

我们的系统是 2 个三星 1TB 850Evo SSD 的条带，用于测试 ZFS 性能，与 LVM 相比，它非常糟糕：读取速度比 HDD 慢，写入速度也不及我们在 LVM 上获得的预期 1.7GB。这很奇怪，因为我们的 FreeBSD 备份服务器具有速度较慢的 HDD 和较旧类型的 SSD，并且在相同的测试中表现更好。

尽管系统在某种程度上被剥夺了 RAM（zfs 为 arc 获得 4gb，其他一切都由 VM 占用）但是没有缓存并且没有同步，性能仍然没有接近任何东西。

因此，我们正在考虑购买基于 AMD Epyc 的较新系统，并设置完整的 NVMe 或带有 SSD 的 NVMe，并禁用缓存以至少从 ZFS 中释放内存（我们希望它最多使用 10GB 的内存）。除了校验和之外，我们真的不需要 ZFS 的所有安全功能（但对于 SSD，它似乎是多余的，因为 SSD 运行内部校验和系统），因此 SSD 将是 vdev 的条带。

我们更喜欢 ZFS for zle on Thin-provisioned zvols 以及对远程系统（也运行 ZFS）的快照和增量备份的易用性。

然而，性能的斗争是艰难的......

非常感谢任何建议

virtualization

4 个回答

  1. 首先，ZFS 校验和不是多余的：它是端到端（RAM 到物理介质）校验和，而 HDD/SSD 校验和作为“内部介质”错误控制。要拥有与经典文件系统类似的东西，您必须使用 SATA 设备所缺乏的与 T10/DIF 兼容的磁盘和控制器（您被迫使用价格更高的 SAS SSD）。

    也就是说，ZVOL 的低写入性能通常是由于非常小的默认 8K 块大小，它小到足以大大增加元数据开销，但不足以阻止 4K 写入的读取-修改-写入周期。

    消费级 SATA SSD 磁盘（如三星 850 EVO）的另一个问题是它们没有任何断电保护缓存，因此 ZFS 不断刷新它们以进行元数据写入和同步数据写入。

    无论如何，您确实应该向我们提供有关您的基准测试方法最终实际预期工作量的更多详细信息，以获得准确的答案。

    • 4

  2. 性能很差，因为 ZFS 默认值不适合您正在做的事情。你有东西/etc/modprobe.d/zfs.conf吗？如果没有，则需要进行一些调整。

    • 虚拟机是否会与 ZFS 安装在同一台服务器上运行？
    • 如果是这样，则不需要 ZIL；它仅对同步写入活动有用，例如将 NFS 呈现给 VMware 和某些数据库。
    • 我将 128K 块大小用于本机磁盘上的 ZFS 存储。
    • 对于 Linux，zvols 需要volblocksize=128K
    • 我将 ashift=13 用于所有 SSD ZFS zpool，将 ashift=12 用于其他所有内容。
    • 不要禁用 ARC。如有必要，请限制它，但听起来您没有太多 RAM。
    • 不要禁用校验和。
    • 务必启用 LZ4 压缩！没有理由不这样做。
    • 你打算用 NVMe + 4xSSD 做什么？
    • 2
  3. Best Answer

    如果有人想知道。我们认为主要问题是 RAM（我们的 ARC 被限制在 4GB，所以其他所有东西都被系统吃掉了）。目前与 ZFS 的交易 - 它还没有为 SSD 和/或 NVMe 做好准备。它是为 HDD 设计的，它们笨重的头部、机械和可预测的问题缓慢而笨重。

    借助 SSD 和 NVMe，ZFS 执行他们不需要的愚蠢事情，并且不执行他们实际需要的事情。早在发明 ZFS 时，就没有更多的缓存被认为是非易失性 RAM。

    现在我们可以在一个拥有 4TB 空间的系统中放置 4 个 pcie SSD。

    在这种情况下，有两种方法可以处理这种情况。要么给它足够的内存，让它在你的 SSD 上正常运行，并提供它提供的开销。或者不使用 ZFS。

    很遗憾，因为它的结构性优势非常好。但是如果没有比 HDD 更高的 RAM 使用率，它就无法正确处理 SSD，因为所有设置和配置都告诉它“底层系统很慢，缓存是必要的，读小，写大和顺序”，当 SSD 快时，不需要缓存，可以读大写和正确随机。使用 Optane，这样的问题将是显而易见的。

    或多或少不需要的东西是广泛的缓存，在记录级别对每个文件进行校验和（这没有意义，因为如果你在 SSD 级别有 bitrot，你应该扔掉整个驱动器，因为没有用这样的系统，因为它可能有损坏的控制器破坏你的整个数据，它类似于坏的 RAM）。根本不需要SIL。ARC 也无用，尤其是使用 Optane 驱动器（它增加了 CPU 和 RAM 的开销）。记录大小应完全限制为写入交易驱动器理解。

    或者只是使用 LVM 在系统上进行 KVM 配置。精简配置在那里并不完美，但至少您不需要浪费极其宝贵的 RAM 来使 SSD 达到应有的水平。

    • 1

  4. 特别是如果有人使用 docker（就像我一样），如果您定期构建或拥有许多容器和卷（就像我一样 :)），UFS 就不是真正的生产解决方案。

    由于 docker 能够使用 ZFS 后端，仍然会有一些人希望在运行 ZFS 的系统上使用 SSD 和 Optane。

    @Andrew 我遇到了一些与您相同的问题，并且不得不解决我的大内存问题（ARC 为 32G）。整个服务器现在有 128GB 的​​ RAM，但可以提供很少有系统可以做到的惊人性能。

    另一组人将是在 AWS 上运行 ZFS 条带以解决 burstIO 问题的人 - 基本上，您的所有 EBS SSD 卷都在等待您的突发余额下降时开始显示类似 SATA 5.4K 的性能。在这种情况下，我看到 ZFS 突然切换到大型顺序 IO 来跟上。因此，只要我的应用程序监控 Burstbalance 并减少 IO，ZFS 就会尝试保持正常。

    我预计当他们的多层超虚拟化超越理智的存储阵列开始尝试在严重的 IO 和延迟上升的可怕时期动态管理性能时，VMWare 人员会经历非常相似的事情

    我知道存储系统设计，其中基本上大 RAM 缓存用作写入池 - 这基本上意味着存储报告所有写入都是缓存命中 & 暂存到磁盘稍后发生

    至少对于 ZFS，我知道真正的程序员做到了。

    因此，SSD 上的 ZFS 仍有一些价值 :) - 这取决于您遇到的问题类型。

    • 1

相关问题