最近，在测试 ZoL 系统时，我们发现 SSD 的随机和顺序读取性能不佳，随机写入性能不佳。
我们的系统是 2 个三星 1TB 850Evo SSD 的条带，用于测试 ZFS 性能，与 LVM 相比，它的表现非常糟糕：读取速度比 HDD 慢，写入速度达不到 LVM 上预期的 1.7GB。这很奇怪，因为我们的 FreeBSD 备份服务器有较慢的 HDD 和较旧类型的 SSD，但在相同测试中表现更好。
虽然系统的 RAM 有些不足（zfs 为 arc 分配了 4gb，其他都被虚拟机占用了），但是在没有缓存和同步的情况下，性能仍然相差甚远。
因此，我们正在考虑购买基于 AMD Epyc 的新系统，并设置完整的 NVMe 或带有 SSD 的 NVMe，并禁用缓存，以至少从 ZFS 中释放一点内存（我们希望它最多使用 10GB 用于所有操作）。除了校验和之外，我们实际上并不需要 ZFS 的所有安全功能（但对于 SSD，这似乎是多余的，因为 SSD 运行内部校验和系统），因此 SSD 将成为 vdev 的条带。
我们更喜欢在精简配置的 zvols 上使用 ZFS 进行 zle，并且可以轻松地将快照和增量备份到远程系统（也运行 ZFS）。
然而，争取表现的努力是艰难的......
非常感谢任何建议
答案1
首先，ZFS 校验和是不是冗余：它是一个端到端（RAM 到物理媒体）校验和，而 HDD/SSD 校验和作为“媒体内部”错误控制。要获得与传统文件系统类似的功能，您需要有使用 T10/DIF 兼容磁盘和控制器，这是 SATA 设备所缺乏的（您被迫使用 SAS SSD，而它们要昂贵得多）。
也就是说，ZVOL 的写入性能低下通常是由于默认的 8K 块大小非常小造成的，这个大小足够小以至于大大增加元数据开销，但又不够小以至于无法阻止 4K 写入的读取-修改-写入循环。
消费级 SATA SSD 磁盘（如三星 850 EVO）的另一个问题是，它们没有任何断电保护缓存，因此 ZFS 会不断刷新它们以进行元数据写出和同步数据写入。
无论如何，您应该向我们提供有关基准测试方法和实际预期工作量的更多详细信息，以获得准确的答案。
答案2
性能不佳是因为 ZFS 默认设置不适合你正在做的事情。你有什么吗/etc/modprobe.d/zfs.conf？如果没有，它需要进行一些调整。
- 虚拟机是否会与 ZFS 安装在同一台服务器上运行？
- 如果是这样，ZIL 就没有必要了；它仅对同步写入活动有用，例如向 VMware 和某些数据库呈现 NFS。
- 我在本机磁盘上使用 128K 块大小作为 ZFS 存储。
- 对于 Linux，zvols 需要
volblocksize=128K - 我对所有 SSD ZFS zpools 使用 ashift=13，对其他所有 zpools 使用 ashift=12。
- 不要禁用 ARC。如果有必要，请限制它，但听起来你没有太多 RAM。
- 不要禁用校验和。
- 一定要启用 LZ4 压缩！没有理由不启用。
- 您打算用 NVMe + 4xSSD 做什么？
答案3
如果有人想知道。我们认为主要问题是 RAM（我们的 ARC 限制为 4GB，因此其他一切都被系统占用）。目前 ZFS 的问题在于 - 它还没有为 SSD 和/或 NVMe 做好准备。它是为 HDD 设计的，速度慢、体积大，磁头笨重，机械性能差，问题可预测。
对于 SSD 和 NVMe，ZFS 会执行一些它们不需要的愚蠢操作，而不会执行它们实际需要的操作。当 ZFS 被发明时，人们还没有想到非易失性 RAM 会充当缓存。
现在我们可以在具有 4TB 空间的系统中放置 4x pcie SSD。
在这种情况下，有两种方法可以处理这种情况。要么给它足够的内存，让它利用它提供的开销在您的 SSD 上正常运行。或者不使用 ZFS。
这很遗憾，因为它的结构优势相当不错。但是，如果没有比 HDD 更高的 RAM 使用率，它就无法正确处理 SSD，因为所有设置和配置都告诉它“底层系统很慢，需要缓存，读取小数据，写入大数据且顺序执行”，而 SSD 速度很快，不需要缓存，可以读取大数据和写入大数据并正确执行随机操作。使用 Optane 时，这些问题将显而易见。
或多或少不需要的东西是大量缓存、在记录级别对每个文件进行校验和（这没有意义，因为如果在 SSD 级别出现位腐烂，则应该丢弃整个驱动器，因为这样的系统没有用处，因为它可能会损坏控制器，从而毁掉整个数据，这类似于坏 RAM）。SIL 根本不需要。ARC 也是无用的，尤其是对于 Optane 驱动器（它会增加 CPU 和 RAM 的开销）。记录大小应该完全限制在驱动器理解的写入事务中。
或者在系统上使用 LVM 进行 KVM 配置。精简配置并不完美，但至少您不需要浪费极其宝贵的 RAM 来让您的 SSD 达到应有的性能水平。
答案4
具体来说，如果有人使用 docker（就像我一样），如果您定期构建或拥有许多容器和卷（就像我一样 :)），那么 UFS 并不是一个真正的生产解决方案。
由于 docker 能够使用 ZFS 后端，因此仍然会有一些人希望在运行 ZFS 的系统上使用 SSD 和 Optane。
@Andrew 我遇到了和你同样的一些问题，并且不得不用大量 RAM（ARC 为 32G）来解决我的问题。整个服务器现在有 128GB 的 RAM，但可以实现很少有系统能达到的惊人性能。
另一组人将在 AWS 上运行 ZFS 条带来解决突发 IO 问题 - 基本上，您的所有 EBS SSD 卷都在等待突发余额下降后开始显示类似 SATA 5.4K 的性能。在这种情况下，我看到 ZFS 突然切换到大型顺序 IO 以跟上。因此，只要我的应用程序监控突发余额并减少 IO，ZFS 就会尝试保持正常。
我预计，当 VMWare 用户使用多层超虚拟化存储阵列开始尝试在 IO 繁忙和延迟上升的危急时刻动态管理性能时，他们也会遇到非常类似的事情
我知道存储系统设计中，基本上使用大型 RAM 缓存作为写入池 - 这基本上意味着存储将所有写入报告为缓存命中，并且稍后暂存到磁盘
至少通过 ZFS 我知道真正的程序员做到了。
因此，SSD 上的 ZFS 仍然具有一定的价值 :) - 这取决于您遇到的问题类型。