ZFS 池缓慢顺序读取

Question 1

我设法使速度非常接近我预期的数字。

我在寻找400MB/秒并管理392MB/秒。所以我说问题解决了。后来我又加了一个缓存设备，我成功了458MB/秒读取（我相信是缓存的）。

1.最初，只需将 ZFS 数据集recordsize值增加到1M

zfs set recordsize=1M pool2/test

我相信这种改变只会减少磁盘活动，从而提高大型同步读写的效率。这正是我想要的。

变更后的结果

bonnie++ = 写入 226MB，读取 392MB
dd = 写入 260MB，读取 392MB
2 个进程并行 = 227MB 写入，396MB 读取

2.当我添加缓存设备（120GB SSD）时，情况变得更好了。写入速度稍慢，我不知道为什么。

Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
igor            63G           208325  48 129343  28           458513  35 326.8  16

缓存设备的诀窍是l2arc_noprefetch=0设置/etc/modprobe.d/zfs.conf。它允许 ZFS 缓存流式/顺序数据。仅当您的缓存设备比您的阵列更快时才这样做，就像我的一样。

在受益于我的数据集上的记录大小变化后，我认为这可能是处理不佳的 zvol 性能的类似方法。

我听到一些人说他们使用获得了良好的性能volblocksize=64k，所以我尝试了一下。没有运气。

zfs create -b 64k -V 120G pool/volume

但后来我读到 ext4（我测试的文件系统）支持 RAID 选项，如stride和stripe-width，这是我以前从未使用过的。所以我使用这个网站来计算所需的设置：https://busybox.net/~aldot/mkfs_stride.html并再次格式化 zvol。

mkfs.ext3 -b 4096 -E stride=16,stripe-width=32 /dev/zvol/pool/volume

我做bonnie++了一个简单的基准测试，结果非常好。遗憾的是，我没有拿到结果，但我记得写入速度至少快了 5-6 倍。如果我再次进行基准测试，我会再次更新此答案。

Answer

我设法使速度非常接近我预期的数字。

我在寻找400MB/秒并管理392MB/秒。所以我说问题解决了。后来我又加了一个缓存设备，我成功了458MB/秒读取（我相信是缓存的）。

1.最初，只需将 ZFS 数据集recordsize值增加到1M

zfs set recordsize=1M pool2/test

我相信这种改变只会减少磁盘活动，从而提高大型同步读写的效率。这正是我想要的。

变更后的结果

bonnie++ = 写入 226MB，读取 392MB
dd = 写入 260MB，读取 392MB
2 个进程并行 = 227MB 写入，396MB 读取

2.当我添加缓存设备（120GB SSD）时，情况变得更好了。写入速度稍慢，我不知道为什么。

Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
igor            63G           208325  48 129343  28           458513  35 326.8  16

缓存设备的诀窍是l2arc_noprefetch=0设置/etc/modprobe.d/zfs.conf。它允许 ZFS 缓存流式/顺序数据。仅当您的缓存设备比您的阵列更快时才这样做，就像我的一样。

在受益于我的数据集上的记录大小变化后，我认为这可能是处理不佳的 zvol 性能的类似方法。

我听到一些人说他们使用获得了良好的性能volblocksize=64k，所以我尝试了一下。没有运气。

zfs create -b 64k -V 120G pool/volume

但后来我读到 ext4（我测试的文件系统）支持 RAID 选项，如stride和stripe-width，这是我以前从未使用过的。所以我使用这个网站来计算所需的设置：https://busybox.net/~aldot/mkfs_stride.html并再次格式化 zvol。

mkfs.ext3 -b 4096 -E stride=16,stripe-width=32 /dev/zvol/pool/volume

我做bonnie++了一个简单的基准测试，结果非常好。遗憾的是，我没有拿到结果，但我记得写入速度至少快了 5-6 倍。如果我再次进行基准测试，我会再次更新此答案。

Question 2

您的结果完全合理，但您的期望却不合理：您夸大了 RAID1（以及 RAID10）带来的读取性能改进。关键在于双向镜像最多单个磁盘的读取速度/IOP 是 2 倍，但实际性能可能在 1 倍到 2 倍之间。

让我们通过一个例子来说明。假设有一个具有双向镜像的系统，每个磁盘能够达到 100 MB/s（顺序）和 200 IOPS。队列深度为 1（最多一个未完成的请求），该阵列将具有不优于单个磁盘：RAID1 将 IO 请求拆分到两个磁盘的队列中，但它不是将单个请求拆分到两个磁盘上（至少，我见过的任何实现都是以这种方式运行的）。另一方面，如果您的 IO 队列更大（例如：您有 4/8 个未完成的请求），则总磁盘吞吐量将明显高于单个磁盘。

对于 RAID0 也可以做类似的事情，但在这种情况下，决定平均改进的不仅是队列大小，而且IO 请求大小也：如果你的平均 IO 大小小于块大小，那么它将不是可以在两个（或更多）磁盘上进行条带化，但将由单个磁盘提供服务。使用增加的 Bonnie++ 记录大小的结果显示了这种确切的行为：条带化极大地受益于更大的 IO 大小。

现在应该清楚的是，将两个 RAID 级别组合成 RAID10 阵列将不是导致线性性能扩展，但它设置了一个上限对此。我很确定，如果您运行多个 dd/bonnie++ 实例（或用于fio直接操作 IO 队列），您将获得更符合您最初预期的结果，这仅仅是因为您将以更完整的方式（多个未完成的顺序/随机 IO 请求）对您的 IO 阵列进行征税，而不是单独加载单个顺序 IO 请求。

Answer

您的结果完全合理，但您的期望却不合理：您夸大了 RAID1（以及 RAID10）带来的读取性能改进。关键在于双向镜像最多单个磁盘的读取速度/IOP 是 2 倍，但实际性能可能在 1 倍到 2 倍之间。

让我们通过一个例子来说明。假设有一个具有双向镜像的系统，每个磁盘能够达到 100 MB/s（顺序）和 200 IOPS。队列深度为 1（最多一个未完成的请求），该阵列将具有不优于单个磁盘：RAID1 将 IO 请求拆分到两个磁盘的队列中，但它不是将单个请求拆分到两个磁盘上（至少，我见过的任何实现都是以这种方式运行的）。另一方面，如果您的 IO 队列更大（例如：您有 4/8 个未完成的请求），则总磁盘吞吐量将明显高于单个磁盘。

对于 RAID0 也可以做类似的事情，但在这种情况下，决定平均改进的不仅是队列大小，而且IO 请求大小也：如果你的平均 IO 大小小于块大小，那么它将不是可以在两个（或更多）磁盘上进行条带化，但将由单个磁盘提供服务。使用增加的 Bonnie++ 记录大小的结果显示了这种确切的行为：条带化极大地受益于更大的 IO 大小。

现在应该清楚的是，将两个 RAID 级别组合成 RAID10 阵列将不是导致线性性能扩展，但它设置了一个上限对此。我很确定，如果您运行多个 dd/bonnie++ 实例（或用于fio直接操作 IO 队列），您将获得更符合您最初预期的结果，这仅仅是因为您将以更完整的方式（多个未完成的顺序/随机 IO 请求）对您的 IO 阵列进行征税，而不是单独加载单个顺序 IO 请求。

Question 3

zfs 写入并不是很快，但也不差。zfs 读取非常慢，请自己看一下：1）#准备：cd /mytestpool/mytestzfs;for f in urf{0..9};do dd if=/dev/urandom of=$f bs=1M count=102400;done;#获取包含大量子目录和文件（~50GB）的目录路径并检查大小，例如：du -sh /mytestpool/mytestzfs/appsdir2）重启3）时间 cat /mytestpool/mytestzfs/urf0 >/dev/null;date;for f in /mytestpool/mytestzfs/urf{1..9};do cat $f >/dev/null & wait;done;date; time tar cf - /mytestpool/mytestzfs/appsdir|cat - >/dev/null 4) #查看 iostat、iotop 或 zpool iostat：您会看到太多内容！ 5) 读取完成后，使用计算器除以 singlefilesize/sec，除以 9x singlefilessize/sec，再除以 directorysize/sec。这就是当磁盘上的数据越来越多，内存也越来越多时，您从 zfs 中得到的结果。

Answer

zfs 写入并不是很快，但也不差。zfs 读取非常慢，请自己看一下：1）#准备：cd /mytestpool/mytestzfs;for f in urf{0..9};do dd if=/dev/urandom of=$f bs=1M count=102400;done;#获取包含大量子目录和文件（~50GB）的目录路径并检查大小，例如：du -sh /mytestpool/mytestzfs/appsdir2）重启3）时间 cat /mytestpool/mytestzfs/urf0 >/dev/null;date;for f in /mytestpool/mytestzfs/urf{1..9};do cat $f >/dev/null & wait;done;date; time tar cf - /mytestpool/mytestzfs/appsdir|cat - >/dev/null 4) #查看 iostat、iotop 或 zpool iostat：您会看到太多内容！ 5) 读取完成后，使用计算器除以 singlefilesize/sec，除以 9x singlefilessize/sec，再除以 directorysize/sec。这就是当磁盘上的数据越来越多，内存也越来越多时，您从 zfs 中得到的结果。

ZFS 池缓慢顺序读取

答案1

答案2

答案3

相关内容