linux – ZFS池缓慢顺序读取

发布时间：2020-12-13 17:20:38 所属栏目：Linux 来源：网络整理

导读：我有一个关于这个问题的相关问题,但它太复杂太大了,所以我决定将问题分解为NFS和本地问题.我也试过在zfs-discuss邮件列表上询问这个问题但没有取得多大成功. Slow copying between NFS/CIFS directories on same server 大纲：我是如何设置和我期待的我有一

我有一个关于这个问题的相关问题,但它太复杂太大了,所以我决定将问题分解为NFS和本地问题.我也试过在zfs-discuss邮件列表上询问这个问题但没有取得多大成功.

Slow copying between NFS/CIFS directories on same server

大纲：我是如何设置和我期待的

>我有一个带有4个磁盘的ZFS池. 2TB RED配置为2个条带镜像(RAID 10).在Linux上,zfsonlinux.没有缓存或日志设备.
>数据在镜像间平衡(对ZFS很重要)
>每个磁盘可以并行读取(原始w?? / dd)147MB /秒,总吞吐量为588MB /秒.
>根据类似的4TB RED磁盘的基准测试,我希望每个磁盘的写入速度为115MB /秒,读取速度为138MB /秒,顺序数据重写速度为50MB /秒.我希望读或写不低于100MB /秒,因为这些天任何磁盘都能做到这一点.
>我认为在负载读取或写入顺序数据时,我会在所有4个磁盘上看到100％的IO利用率.并且在100％利用率的情况下磁盘将超过100MB /秒.
>我认为这个池可以让我在一个磁盘上大约2倍写入,2倍重写和4倍读取性能 – 我错了吗？
> NEW我认为同一个池上的ext4 zvol与ZFS的速度大致相同

我真正得到的

我发现池的读取性能并不像我预期的那么高

从几天前的bonnie基准测试池

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    99  99 232132  47 118787  27   336  97 257072  22  92.7   6

bonnie在一个单独的4TB RED驱动器上,它自己在一个zpool中

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   101  99 115288  30 49781  14   326  97 138250  13 111.6   8

根据这一点,读取和重写速度基于单个4TB RED驱动器的结果是合适的(它们是双倍的).但是,我预期的读取速度大约是550MB /秒(4TB驱动器速度的4倍),我至少希望大约400MB /秒.相反,我看到大约260MB /秒

从刚刚开始在泳池上的邦妮,同时收集以下信息.与以前不一样,没有任何改变.

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   103  99 207518  43 108810  24   342  98 302350  26 256.4  18

在写期间zpool iostat.对我来说似乎没问题.

                                                 capacity     operations    bandwidth
pool                                          alloc   free   read  write   read  write
--------------------------------------------  -----  -----  -----  -----  -----  -----
pool2                                         1.23T  2.39T      0  1.89K  1.60K   238M
  mirror                                       631G  1.20T      0    979  1.60K   120M
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469      -      -      0   1007  1.60K   124M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX      -      -      0    975      0   120M
  mirror                                       631G  1.20T      0    953      0   117M
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536      -      -      0  1.01K      0   128M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE      -      -      0    953      0   117M

重写期间zpool iostat.我想,对我来说似乎没问题.

                                                 capacity     operations    bandwidth
pool                                          alloc   free   read  write   read  write
--------------------------------------------  -----  -----  -----  -----  -----  -----
pool2                                         1.27T  2.35T   1015    923   125M   101M
  mirror                                       651G  1.18T    505    465  62.2M  51.8M
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469      -      -    198    438  24.4M  51.7M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX      -      -    306    384  37.8M  45.1M
  mirror                                       651G  1.18T    510    457  63.2M  49.6M
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536      -      -    304    371  37.8M  43.3M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE      -      -    206    423  25.5M  49.6M

这就是我想知道发生了什么

阅读期间zpool iostat

                                                 capacity     operations    bandwidth
pool                                          alloc   free   read  write   read  write
--------------------------------------------  -----  -----  -----  -----  -----  -----
pool2                                         1.27T  2.35T  2.68K     32   339M   141K
  mirror                                       651G  1.18T  1.34K     20   169M  90.0K
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469      -      -    748      9  92.5M  96.8K
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX      -      -    623     10  76.8M  96.8K
  mirror                                       651G  1.18T  1.34K     11   170M  50.8K
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536      -      -    774      5  95.7M  56.0K
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE      -      -    599      6  74.0M  56.0K

iostat -x在同一个读操作期间.注意IO％不是100％.

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdb               0.60     0.00  661.30    6.00 83652.80    49.20   250.87     2.32    3.47    3.46    4.87   1.20  79.76
sdd               0.80     0.00  735.40    5.30 93273.20    49.20   251.98     2.60    3.51    3.51    4.15   1.20  89.04
sdf               0.50     0.00  656.70    3.80 83196.80    31.20   252.02     2.23    3.38    3.36    6.63   1.17  77.12
sda               0.70     0.00  738.30    3.30 93572.00    31.20   252.44     2.45    3.33    3.31    7.03   1.14  84.24

zpool和测试数据集设置：

atime is off

compression is off

ashift is 0 (autodetect – my understanding was that this was ok)

zdb says disks are all ashift=12

module – options zfs zvol_threads=32 zfs_arc_max=17179869184

sync = standard

编辑 – 2015年10月30日

我做了一些测试

dataset bonnie++ w/recordsize=1M = 226MB write,392MB read much better

dataset dd w/record size=1M = 260MB write,392MB read much better

zvol w/ext4 dd bs=1M = 128MB write,107MB read why so slow?

dataset 2 processess in parallel = 227MB write,396MB read

dd direct io makes no different on dataset and on zvol

随着记录大小的增加,我对表现更加满意.几乎每个池上的文件都超过1MB.所以我会这样离开.磁盘仍未获得100％的利用率,这让我想知道它是否仍然可以更快.而现在我想知道为什么zvol性能如此糟糕,因为这是我(轻松)使用的东西.

我很乐意提供评论/答案中要求的任何信息.在我的另一个问题中也发布了大量的信息：Slow copying between NFS/CIFS directories on same server

我完全清楚,我可能只是不明白某些东西,这根本不是问题.提前致谢.

为了说清楚,问题是：为什么ZFS池不像我预期的那样快？也许还有其他错误吗？

解决方法

我设法让速度非常接近我期待的数字.

我一直在寻找400MB /秒,管理392MB /秒.所以我说这是问题解决了.随后添加了一个缓存设备,我管理了458MB /秒的读取时间(我相信缓存).

1.这首先是通过将ZFS数据集recordsize值增加到1M来实现的

zfs set recordsize=1M pool2/test

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

改变后的结果

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

当我添加缓存设备(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

缓存设备的技巧是在/etc/modprobe.d/zfs.conf中设置l2arc_noprefetch = 0.它允许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倍.如果我再次进行基准测试,我会再次更新此答案.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!