从理论上讲

Question

从理论上讲

在一个非常理论化的世界，从您的池配置（四个 vdev，每个都是双磁盘镜像）来看，您可以预期读取带宽相当于一个磁盘速度的八倍。这是因为：

在镜像 vdev 中，虚拟文件系统能够同时从两个磁盘读取不同的数据块
在多 vdev 池中，ZFS 会自动对数据进行条带化，这样它就可以同时从多个 vdev 读取数据

西部数据声称 3 TB Red 硬盘的读取速度可以超过 140 MB/s。这不会发生，至少不会一直发生。因此，我们假设您可以从其中一个硬盘获得 100 MB/s。当它们在您的池配置中组合时，您可以理论上获得高达 800 MB/s 的读取带宽。

欢迎来到真实的世界

现在让我明确一点：800 MB/s，这可能不会发生！这并不是因为 ZFS 欺骗了你，而是因为带宽计算是基于硬件不会妨碍你的假设。但事实确实如此，所以在实际工作负载下你无法获得理论速度。

当然，我知道您仍然希望通过将多个磁盘组合成一个更大的池来实现一些合理的性能改进。

然后发生了什么？

让我们看看你的测试：第一次复制大文件时，速度为 80 MB/s同步，那么第二次执行相同操作时，速度为 400 MB/s。差异的解释是自适应替换缓存（ARC）我相信你已经知道了。为了完整起见，我只会说这些。

ZFS ARC 提供了一种将经常访问的数据存储在 RAM 中的机制。

第一次从 ZFS 数据集读取文件时，ZFS 必须实际从磁盘读取数据；与此同时，它会填充其读取缓存。第二次读取同一个文件时，您会直接从 RAM 获取数据 - 并且您说您的系统上有足够的空间来容纳整个 1.08 GB 的文件。这意味着您再次使用 rsync (400 MB/s) 复制文件时看到的速度与 ZFS 池中的物理磁盘无关。我们可以将其视为您的固态硬盘 sda驱动。准确地说，不是生的SSD 的写入速度：这是使用 rsync 从延迟极低、带宽极高的介质（RAM 内存）读取数据并写入 SSD 驱动器（延迟也极低）时获得的速度。另外，我认为我们应该考虑到 Linux 可能正在使用所有可用的 RAM 内存来缓存异步写入（此处做出假设！）到 SSD 驱动器分区。

因此，在这一点上，出现一个问题：如果您的 RAM 到 SSD 的写入速度似乎为 400 MB/s，那么当 ZFS 实际从磁盘读取时，为什么只有 80 MB/s？这比单个磁盘的速度还慢！显然，不能怪罪 SSD 本身，我们对 ZFS 池中所有这些驱动器的期望要高得多！

所以，说实话，我没有完整的答案。在考虑了我到目前为止所说的一切之后，我的部分回答你的问题是：

在我看来，带宽低是因为 I/O 活动较多，这意味着 rsync 实际上并不允许直接顺序读取大文件，而是生成大量 I/O，如果驱动器在大量 I/O 中存在延迟，这可能会严重影响流式传输性能。让我们记住，Western Digital Red 磁盘用于网络存储应用程序，这意味着它们旨在实现不错的带宽和良好的每 GB 价格比，而不是高 IOPS。当您从 RAM（低延迟媒体）执行完全相同的操作时，整体流媒体性能还不错。
rsync 不是一个好方法基准测试您的 ZFS 池 - 或其他任何东西。如果您在 Google 中搜索rsync 性能你会看到它比普通文件复制慢的证据——我认为有充分的理由：速度不是你使用 rsync 的目的。我会寻找其他基准测试方法。即使只是dd或者cp可能是顺序读/写测试的更好选择。你可以看看本文寻找一些灵感。
此外，我会尝试找出真实的单磁盘读取性能，在磁盘添加到 ZFS 池之前运行测试。销毁池（您将丢失数据：如有必要，请先备份！），在每个磁盘上运行测试，然后再次定义池并进行更多测试。然后，您可以根据观察到的实际速度应用数学，并再次对理论读取带宽，根据您的 ZFS 池配置（4 vdevs * 2 个磁盘镜像 = 单磁盘带宽 * 8）。
如果您在池中使用每个磁盘之前对其进行测试，您可能会发现一个或多个磁盘状况不佳。如果您刚刚购买了磁盘，请退回有问题的磁盘并要求更换。
如果您对每个磁盘运行测试并发现它们的性能一直很慢，那么您可能遇到了硬件相关的问题 - 配置、驱动程序支持或其他类似问题。
我会尝试不同的硬件配置（如果可能）并针对每个配置运行测试。使用单个镜像 vdev 池运行测试，然后尝试将更多 vdev 组合在一起。看看这是否能给你带来预期的结果。

总结：您需要有条不紊地找出瓶颈所在。不要假设它是 ZFS 本身；它可能不是。尝试不同的配置，并使用适合该工作的工具运行测试。

我不是基准测试或测试专家，所以我不会在这方面给你建议。互联网上有很多关于这个主题的精彩资料。我只是想谈谈 ZFS 特有的一些方面，希望能给你一个方向。

Answer 1

从理论上讲

在一个非常理论化的世界，从您的池配置（四个 vdev，每个都是双磁盘镜像）来看，您可以预期读取带宽相当于一个磁盘速度的八倍。这是因为：

在镜像 vdev 中，虚拟文件系统能够同时从两个磁盘读取不同的数据块
在多 vdev 池中，ZFS 会自动对数据进行条带化，这样它就可以同时从多个 vdev 读取数据

西部数据声称 3 TB Red 硬盘的读取速度可以超过 140 MB/s。这不会发生，至少不会一直发生。因此，我们假设您可以从其中一个硬盘获得 100 MB/s。当它们在您的池配置中组合时，您可以理论上获得高达 800 MB/s 的读取带宽。

欢迎来到真实的世界

现在让我明确一点：800 MB/s，这可能不会发生！这并不是因为 ZFS 欺骗了你，而是因为带宽计算是基于硬件不会妨碍你的假设。但事实确实如此，所以在实际工作负载下你无法获得理论速度。

当然，我知道您仍然希望通过将多个磁盘组合成一个更大的池来实现一些合理的性能改进。

然后发生了什么？

让我们看看你的测试：第一次复制大文件时，速度为 80 MB/s同步，那么第二次执行相同操作时，速度为 400 MB/s。差异的解释是自适应替换缓存（ARC）我相信你已经知道了。为了完整起见，我只会说这些。

ZFS ARC 提供了一种将经常访问的数据存储在 RAM 中的机制。

第一次从 ZFS 数据集读取文件时，ZFS 必须实际从磁盘读取数据；与此同时，它会填充其读取缓存。第二次读取同一个文件时，您会直接从 RAM 获取数据 - 并且您说您的系统上有足够的空间来容纳整个 1.08 GB 的文件。这意味着您再次使用 rsync (400 MB/s) 复制文件时看到的速度与 ZFS 池中的物理磁盘无关。我们可以将其视为您的固态硬盘 sda驱动。准确地说，不是生的SSD 的写入速度：这是使用 rsync 从延迟极低、带宽极高的介质（RAM 内存）读取数据并写入 SSD 驱动器（延迟也极低）时获得的速度。另外，我认为我们应该考虑到 Linux 可能正在使用所有可用的 RAM 内存来缓存异步写入（此处做出假设！）到 SSD 驱动器分区。

因此，在这一点上，出现一个问题：如果您的 RAM 到 SSD 的写入速度似乎为 400 MB/s，那么当 ZFS 实际从磁盘读取时，为什么只有 80 MB/s？这比单个磁盘的速度还慢！显然，不能怪罪 SSD 本身，我们对 ZFS 池中所有这些驱动器的期望要高得多！

所以，说实话，我没有完整的答案。在考虑了我到目前为止所说的一切之后，我的部分回答你的问题是：

在我看来，带宽低是因为 I/O 活动较多，这意味着 rsync 实际上并不允许直接顺序读取大文件，而是生成大量 I/O，如果驱动器在大量 I/O 中存在延迟，这可能会严重影响流式传输性能。让我们记住，Western Digital Red 磁盘用于网络存储应用程序，这意味着它们旨在实现不错的带宽和良好的每 GB 价格比，而不是高 IOPS。当您从 RAM（低延迟媒体）执行完全相同的操作时，整体流媒体性能还不错。
rsync 不是一个好方法基准测试您的 ZFS 池 - 或其他任何东西。如果您在 Google 中搜索rsync 性能你会看到它比普通文件复制慢的证据——我认为有充分的理由：速度不是你使用 rsync 的目的。我会寻找其他基准测试方法。即使只是dd或者cp可能是顺序读/写测试的更好选择。你可以看看本文寻找一些灵感。
此外，我会尝试找出真实的单磁盘读取性能，在磁盘添加到 ZFS 池之前运行测试。销毁池（您将丢失数据：如有必要，请先备份！），在每个磁盘上运行测试，然后再次定义池并进行更多测试。然后，您可以根据观察到的实际速度应用数学，并再次对理论读取带宽，根据您的 ZFS 池配置（4 vdevs * 2 个磁盘镜像 = 单磁盘带宽 * 8）。
如果您在池中使用每个磁盘之前对其进行测试，您可能会发现一个或多个磁盘状况不佳。如果您刚刚购买了磁盘，请退回有问题的磁盘并要求更换。
如果您对每个磁盘运行测试并发现它们的性能一直很慢，那么您可能遇到了硬件相关的问题 - 配置、驱动程序支持或其他类似问题。
我会尝试不同的硬件配置（如果可能）并针对每个配置运行测试。使用单个镜像 vdev 池运行测试，然后尝试将更多 vdev 组合在一起。看看这是否能给你带来预期的结果。

总结：您需要有条不紊地找出瓶颈所在。不要假设它是 ZFS 本身；它可能不是。尝试不同的配置，并使用适合该工作的工具运行测试。

我不是基准测试或测试专家，所以我不会在这方面给你建议。互联网上有很多关于这个主题的精彩资料。我只是想谈谈 ZFS 特有的一些方面，希望能给你一个方向。

从理论上讲

答案1

从理论上讲

欢迎来到真实的世界

然后发生了什么？

相关内容