amazon-ec2 - ZFS 慢得离谱

Question

我误解iostat了结果还是真的每分钟只写 3.06 MB？

# zpool iostat -v 60

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zfs-backup   356G   588G    465     72  1.00M  3.11M
  xvdf       356G   588G    465     72  1.00M  3.11M
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zfs-backup   356G   588G    568     58  1.26M  3.06M
  xvdf       356G   588G    568     58  1.26M  3.06M
----------  -----  -----  -----  -----  -----  -----

当前rsync正在从其他 HDD ( ext4) 写入文件。根据我们的文件特征（约 50 KB 文件），数学似乎是正确的3.06 * 1024 / 58 = 54 KB。

作为记录：

• primarycache=metadata
• compression=lz4
• dedup=off
• checksum=on
• relatime=on
• atime=off

服务器在EC2，目前 1 核，2GB RAM ( t2.small)，硬盘 - 亚马逊上最便宜的。OS - Debian Jessie，zfs-dkms从debian testing存储库安装。

如果真的那么慢，那为什么呢？有没有办法在不将所有内容转移到 SSD 并添加 8 GB RAM 的情况下提高性能？它可以VPS在所有方面表现良好，还是在ZFS设计时考虑到裸机？

编辑

ZIL正如答案中所建议的那样，我添加了一个 5 GB 通用 SSD 用作。这并没有太大帮助，因为ZIL似乎根本没有使用。在我的用例中，5 GB 应该绰绰有余，根据以下 Oracle文章，我应该拥有1/2RAM 的大小。

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zfs-backup   504G   440G     47     36   272K  2.74M
  xvdf       504G   440G     47     36   272K  2.74M
logs            -      -      -      -      -      -
  xvdg          0  4.97G      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zfs-backup   504G   440G     44     37   236K  2.50M
  xvdf       504G   440G     44     37   236K  2.50M
logs            -      -      -      -      -      -
  xvdg          0  4.97G      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

编辑

dd测试显示速度相当不错。

# dd if=/dev/zero of=/mnt/zfs/docstore/10GB_test bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 29.3561 s, 366 MB/s

然而iostat，输出在带宽方面并没有太大变化。注意更多的写操作。

# zpool iostat -v 10
               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zfs-backup   529G   415G      0     40  1.05K  2.36M
  xvdf       529G   415G      0     40  1.05K  2.36M
logs            -      -      -      -      -      -
  xvdg          0  4.97G      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zfs-backup   529G   415G      2    364  3.70K  3.96M
  xvdf       529G   415G      2    364  3.70K  3.96M
logs            -      -      -      -      -      -
  xvdg          0  4.97G      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zfs-backup   529G   415G      0    613      0  4.48M
  xvdf       529G   415G      0    613      0  4.48M
logs            -      -      -      -      -      -
  xvdg          0  4.97G      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zfs-backup   529G   415G      0    490      0  3.67M
  xvdf       529G   415G      0    490      0  3.67M
logs            -      -      -      -      -      -
  xvdg          0  4.97G      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zfs-backup   529G   415G      0    126      0  2.77M
  xvdf       529G   415G      0    126      0  2.77M
logs            -      -      -      -      -      -
  xvdg          0  4.97G      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zfs-backup   529G   415G      0     29    460  1.84M
  xvdf       529G   415G      0     29    460  1.84M
logs            -      -      -      -      -      -
  xvdg          0  4.97G      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

Answer 1

它能否在 VPS 上表现良好，或者 ZFS 在设计时考虑了裸机？

两者都是。

最初它是为裸机设计的，那就是您自然会获得最佳性能和完整的功能集（否则您必须信任底层存储，例如，如果在请求同步写入时写入确实提交到磁盘）。尽管它非常灵活，因为您的 vdev 可以包含您可用的任何文件或设备 - 当然，性能只能与底层存储一样好。

需要考虑的几点：

• 在不同 ZFS 文件系统之间移动文件始终是完整的复制/删除，而不仅仅是重新排列链接（不适用于您的情况，但将来可能）
• 同步写入比异步慢得多（ZFS 必须等待每个请求提交，并且不能以通常的方式将写入排队*），并且只能通过将 ZFS 意图日志移动到适合的专用 vdev 来加速高写入 IOPS、低延迟和高耐用性（在大多数情况下，这将是 SLC SSD 或类似的，但它可以是与池中已有设备不同的任何设备）。具有可以轻松饱和 110 MB/s 异步的普通磁盘的系统可能具有大约 0.5 到 10 MB/s 的同步性能（取决于 vdev），而无需将 ZIL 分离到专用的 SLOG 设备上。因此，我不会认为您的价值观与众不同。
• 即使有良好的硬件，ZFS 也永远不会像更简单的文件系统那样快，因为灵活性和安全性的开销。Sun 从一开始就说明了这一点，您应该不会感到惊讶。如果你看重性能胜过任何东西，那就选择其他东西。
• 有问题的文件系统的块大小会影响性能，但我手头没有可靠的测试数字。
• 更多的 RAM 对您没有多大帮助（超过系统本身约 1 GB 的低阈值），因为它仅用作读取缓存（除非您启用了重复数据删除）

建议：

• 为您的池使用更快的（虚拟）磁盘
• 通过使用不同的（虚拟）设备将 ZIL 与您的普通池分开，最好比池更快，但即使是速度相同但未链接到其他设备的设备也可以改善您的情况
• 使用异步而不是同步并在您的事务（或相当大的块）之后自己验证它

---

*) 更准确地说：通常所有小于一定大小的小同步写入都会在 ZIL 中额外收集，然后再从 RAM 写入磁盘，这会每 5 秒或大约 4 GB 发生一次，以先到者为准（所有这些参数都可以进行修改）。这样做是因为：

• 每 5 秒从 RAM 写入旋转磁盘可以是连续的，因此比小写入快
• 在突然断电的情况下，中止的进行中的事务会保存在 ZIL 中，并且可以在重新启动时重新应用。这就像在具有事务日志的数据库中一样工作，并保证文件系统的一致状态（对于旧数据），并且没有要写入的数据是 los（对于新数据）。

通常 ZIL 驻留在池本身上，应使用冗余 vdev 对其进行保护，从而使整个操作对断电、磁盘崩溃、位错误等具有很强的弹性。缺点是池磁盘需要先执行随机小写操作他们可以以更有效的连续传输将相同的数据刷新到磁盘 - 因此建议将 ZIL 移动到另一个设备上 - 通常称为 SLOG 设备（单独的LOG设备）。这可以是另一个磁盘，但 SSD 在这种工作负载下的性能要好得多（并且会很快磨损，因为大多数事务都在通过它）。如果您从未遇到过崩溃，您的 SSD 将永远不会被读取，只会被写入。

Answer 2

这个特殊问题可能是由于邻居嘈杂造成的。由于它是一个 t2 实例，因此您最终将获得最低优先级。在这种情况下，您可以停止/启动您的实例以获取新主机。

除非您使用实例存储（无论如何，这并不是 t2 实例的真正选项），否则所有磁盘写入都将在本质上是 SAN 卷上完成。EBS 系统的网络接口由同一主机上的所有实例共享。实例的大小将决定实例的优先级。

如果您正在从一个卷写入另一个卷，您将通过同一接口传递所有读取和写入流量。

可能还有其他因素在起作用，具体取决于您拥有的卷类型以及您的 t2 实例上是否还有任何 CPU 积分