zfs 随机性能讨论.2020.05.22周末更

findlcy

2020.05.22更新：
结合原帖的回复和更多的google，周末又跑了几次fio，对zfs的认识再多了几分。
1. 很多回复指出zfs对内存的依赖，fio太小的数据集跑出来的分数过于理想化，实际参考意义不大。后来找到一篇来在NetApp的技术博客（https://cloud.netapp.com/blog/aws-netapp-baseline-performance-testing），里面关于使用fio测试随机性能的方法给我在接下来的跑分一个很好的参考，回帖也有建议选用数倍于内存的数据集大小。

2. 下面这个回帖非常在理：

其实硬件的规格是确定的，优化其实就是靠软件，哪怕固件等算法本质也是软件，只不过是更底层一点的软件

开这个贴的主题还是围绕软件层面的讨论，如果只是去惊叹Optane 900p随机跑分的话我应该把贴开去硬件开箱区了。

3.这个贴只讨论随机性能，周末跑分的时候按900p的4k实际基础性能51万IOPS作为参照。发现只要把数据集size放大到超过内存，900p做L2ARC的zpool 4k随机读取成绩真的是惨不忍睹(1.5万IOPS)，只有900p基础性能的3%，符合一些大大们对L2ARC鸡肋的评价，至于具体原因和解决办法，欢迎大家跟帖讨论哈。

当发现了这个情况后，我多跑了一个测试，就是用两块900p组成mirror zpool（不要问为什么不用4块组类raid10，问就是没有钱.jpg)去测试随机读取，结果依然一样。这就让我非常疑惑了，按道理两块900p组的raid1，随机读取应该在100万IOPS(51万*2)上下，而不是只有可怜的几万IOPS。为了解决这个疑惑，我用mdadm给900p组了raid1，再用80G的数据集跑fio，结果轻松破百万IOPS，接下来我的目标是调高zpool（纯900p)的4k读取，欢迎各位大大给我一点方向哈。
  

1M_iops

----------------------------------------------------------------------
原帖

受上一贴关于raid卡性能的启发，意识到raid卡的性能和扩展性的限制。一番研究决定入坑zfs（还省钱）。
https://www.chiphell.com/thread-2207921-1-1.html

本人喜欢手动搭建的乐趣，而且所需功能简单，所以没有选择Freenas这种非常受欢迎的做法。

基本系统如下:

硬盘	4x Exos 8TB
CPU	Intel W-2295 (HT=off)
内存	128G ECC内存(8*16)
系统盘	Intel D3-S4610 SSD 240G
缓存	Optane SSD 900p 280G

系统	ubuntu 20.04 + Open-zfs 0.8.3

性能测试和研究只针对4K随机。
目前只是简单用了fio和diskspd 测试了一下，自己大体的结论是”相逢恨晚“，1G的NIC已经成为4K的瓶颈（mellanox的卡还在路上，到了以后再测）。

有时间的话也会用sql测试一下实际环境下的性能提升。

另外，900p也是一个令我眼前一亮的产品，就像第一次给电脑加固态硬盘的感觉。导致现在极度想入坑 DC Persistant Memory（我没有钱.jpg）

附上900p的4K成绩
读取，58万iops，关键是延迟非常爆炸且稳定，99th percentile只是109.9us，吊打市面任何SSD，

900pREAD

写入，59.5万iops，跟读取一样残暴。

900pWRITE

下面的测试结果全部采用3个主要前提：
1. 只测4K。
2. 全部是Queue depth = 8, Thread = 8，我知道提高T数能继续大幅度提高iops，但是已经脱离实际环境，所以只测T8。
3. 禁用缓存。

测试非常不严谨，只作抛砖引口水之用

先附上单一HDD的成绩作为基准，4K读取，IOPS=246


然后是两块HDD组成两个vdevs的zfs系统，没有SLOG，没有L2ARC，SYNC=Always，4K读取，IOPS=34.1万
这里产生了萌新的第一个问题，略微学习了一下zfs，明白这个成绩是由于ARC缓存的作用，暂时还不知道怎么禁用ARC去测试两块HDD组成的基础性能，欢迎大佬指教~

两盘读取

接着是两盘zfs的写入，没有SLOG，没有L2ARC，Sync=Always，4K写入，IOPS=821
我理解的arc只缓存读取操作，所以写入成绩正常，但对比单HDD的写入性能已经有非常明显提升。

两盘写入

接下来是4块HDD组成的mirror + stripe 的zpool（类似于普通的raid10），依然没有SLOG，没有L2ARC。
读取，IOPS=68.3万 和两盘的问题一样，-direct=1依然绕不过arc。

四盘读取

写入，依然Sync=Always，IOPS=891，跟两盘没有明显差别。

四盘写入

最后是4盘2vdevs + SLOG + L2ARC（ 900p缓存）
结构

结构

读取，IOPS=51.2万，反而没有像前面只有arc的高，但是分数非常稳定，在51万到53万之间浮动。

l2arc读取

写入，IOPS=34.1万，4块HDD坐上了火箭。

l2arc写入

以上就是学习zfs而进行初步的测试。目前来看，900P带来的最大提升是随机写入iops和残暴且稳定的低延迟，这不是一般nvme盘可以相提并论。
目前问题主要是针对随机读取的测试上，无法量化900P带来的提升。在最后4盘+900p的测试上，能观察到随机读取比之前的测试稳定，大部分时间都是51.5万iops，相较之下只有内存arc的测试分数非常分散，最低30万，最高70万。

具体原因就要请教论坛各位大佬了

测试非常不严谨，只作抛砖引口水之用

crye

看不懂，只能膜拜

tpxcer

用普通内存的我弱弱路过

findlcy

tpxcer 发表于 2020-5-22 09:30
用普通内存的我弱弱路过

我看过你的贴，还是毕竟喜欢手动挡，一起交流哈

hcgxxx

tpxcer 发表于 2020-5-22 09:30
用普通内存的我弱弱路过

ECC内存便宜。

eonghk

1. 你可以设置下primarycache来尝试关掉ARC
2. 正常情况不会开sync=always，这样等于禁用了内存的缓存写入功能，写内存快还是900p快？你可以关掉always再试试。
3. 写缓存适用于对数据安全性要求比较高的情况，比如数据库。
4. zfs严重依赖内存，L2ARC会增加内存需求量。L2ARC默认只对非连续的小块数据缓存。

shanicky

fio 有个参数 -sync https://fio.readthedocs.io/en/la ... #cmdoption-arg-sync

楼主测试的 fio size 好像是 2M，有点小，建议改大，最好超过内存数倍，size 太小情况下应该用不到 l2arc, 2M 甚至都没填满机械盘的缓存，测试的时候可以开一个 iostat 或者用 arc_stat 观察一下 arc/l2arc 的独写和命中率

另外楼主的 zfs 参数调整过么

vfs.zfs.l2arc_noprefetch 默认是 1，没有预读取
vfs.zfs.l2arc_write_max 默认是 8M，也就是说内存中的 arc 数据默认情况下是以 8M/s 的速度写到 l2arc 里面的，可以改大一点
vfs.zfs.l2arc_norw 默认是 0 还是 1 我忘了（看系统，调到 0 可以同时独写


我只用过 freenas 下面的 zfs，没怎么用过 zol， 参数可能不太一样但是整体应该差不多

findlcy

eonghk 发表于 2020-5-22 11:56
1. 你可以设置下primarycache来尝试关掉ARC
2. 正常情况不会开sync=always，这样等于禁用了内存的缓存写入 ...

关于你的第二点，我是特意sync=always来关掉内存缓存写入，目的是只比较单hdd 和hdd vdevs 的性能差别。

1. 我去试下哈
3.粗略阅读了一些文档，也发现了zfs对数据完整性的校验，数据一致性和快照等等的优点，所以才感觉相逢恨晚
4. 现在内存很便宜，分数也不错，有空会用自己的数据库测一下实际提升。

findlcy

shanicky 发表于 2020-5-22 12:07
fio 有个参数 -sync https://fio.readthedocs.io/en/latest/fio_doc.html#cmdoption-arg-sync

楼主测试的  ...

非常好的建议哈~（鲜花.jpg）

回去就翻一下这两个缓存的数据。

你提供的参数我也去研究一下哈。

magiclu

关于raid卡 我记得我看过level1tech的视频，那人说了，raid卡也就是一个小型的电脑，里面也有cpu，内存什么的

当年电脑cpu比较弱才有用，现在是用不到了，多一点硬件，多一个会出事的地方

goat

hcgxxx 发表于 2020-5-22 11:49
ECC内存便宜。

那是R/ECC，单ECC么呵呵呵呵

findlcy

Keyco 发表于 2020-5-22 11:47
把同步选项关闭试试看。
另外压缩关闭了么？

压缩关了，打开sync是想测试hdd的真实性能，加上傲腾作缓存的时候关了。

wesleyxy

关HT是啥？有啥讲究的？

tedaz

太高深了，完全看不懂。

这个意思是水变成油了吗？

findlcy

wesleyxy 发表于 2020-5-22 19:34
关HT是啥？有啥讲究的？

关闭超线程，跟zfs没有关系的。

findlcy

tedaz 发表于 2020-5-22 22:47
太高深了，完全看不懂。

这个意思是水变成油了吗？

少数特殊场景下，如频繁的数据库写入（mysql），的确有水变油的感觉

一日

sync=always没有意义啊。sync=always开了，内存写入缓存就废了。不开这个，NIC基本上随便打满。

L2ARC不用开，128G内存稳稳的。SLOG用900p就可以了。

mrco

以我这么几年的zfs使用经验，Zpool最好是raidz-1*N这种布局，IOPS受限于一个VDEV的最低IOPS设备，简单说，假如一个盘IOPS为100，有6个，那么：

全部做raidz-1：整个pool的IOPS=100
条带化raidz-1：raidz-1*2，整个zpool的IOPS=100*2

增加ARC_L2对于缓存文件有那么点用，其余更多场景意义不是太大（我是kvm的虚拟机放在zfs dataset上，每次clone明显慢于相同配置的硬件raid）

之所以一直割舍不下zfs，还是COW的特性和扩展容易，有快照和加密。

awpak78

感觉ZFS的文件系统元数据非常占IOPS，实际上全靠内存硬撑，只要超出ARC马上死
跑fio要按内存x2来设置数据集，跑个200G就知道ZFS的性能有多差了。
不过你有128G内存，也不容易用完

L2ARC更拉跨，浪费一块SSD还不支持持久存储（重启后从零积累缓存），而且加速效果实在是对不起专门配块nvme SSD

SLOG对家用是纯鸡肋，直接把sync关了用内存缓存就行，反正一般都要配UPS的不会意外断电，独立的SSD SLOG也就没什么登场机会。

findlcy

mrco 发表于 2020-5-23 15:57
以我这么几年的zfs使用经验，Zpool最好是raidz-1*N这种布局，IOPS受限于一个VDEV的最低IOPS设备，简单说， ...

非常中肯的意见~刚接触的东西，我都只是从性能上简单评价。
我在开头也说了，扩展性也是我入坑zfs的原因之一。

想不到大家对L2ARC和SLOG的评价比较一般，之后我也会用sql测一下这两块缓存的提升作用。

对zfs其他很多的特性也在慢慢学习中，一起交流哈。

findlcy

awpak78 发表于 2020-5-23 21:42
感觉ZFS的文件系统元数据非常占IOPS，实际上全靠内存硬撑，只要超出ARC马上死
跑fio要按内存x2来设置数据集 ...

结合了楼上几位的意见，fio测试的时候用500M*8的数据集就已经能让zfs脱去ARC的外衣了，用不了200G。

我的理解是SLOG 还是应该设一个，然后SYNC=standard，让应用决定是否调用sync()？不知道这样理解对不对。

我目前还没理解到L2ARC的应用机制，本以为l2arc是一个比arc容量大，速度差一个级别的缓存，但目前看来又不是这么一回事，还望指教。

awpak78

findlcy 发表于 2020-5-23 23:57
结合了楼上几位的意见，fio测试的时候用500M*8的数据集就已经能让zfs脱去ARC的外衣了，用不了200G ...

要搞清楚SLOG，首先要搞清楚同步写和异步写

异步写就是数据一堆丢过来，自己看着写，写好了报告一下就行
同步写是给一个数据，等你写，报告写好了再给下一个。也就是磁盘测试的4K Q1T1那种模式。
像数据库之类安全要求高的全都是同步写，以保证意外断电的数据完整性。

显然，同步写完全无法使用内存缓存，会非常的慢，IOPS等于整个池中最慢的一块盘。

ZFS为了加速同步写，引入了SLOG，同步写请求来了往SLOG里一丢，就报告写好了，有空了再把SLOG里的写请求誊到真正的数据区域去。
即使不加额外的SSD，SLOG也存在于储存池的机械硬盘上。

所以，SLOG是为了加速同步写，同步写是为了防意外断电。
既然都配了UPS几乎不会意外断电，直接关掉sync，把所有的操作都视为异步写就行了，充分利用内存加速。

awpak78

findlcy 发表于 2020-5-23 23:57
结合了楼上几位的意见，fio测试的时候用500M*8的数据集就已经能让zfs脱去ARC的外衣了，用不了200G ...

L2ARC有用的前提是日常访问数据量可以轻易的塞满ARC。

虽然用的是SSD，但是索引是全在内存的ARC中的，一旦关机内存都没了，L2ARC也就相当于清空了，下一次开机会从0再来。

虽然NAS不会轻易关机，但一月一重启的频率还是有吧，就算不重启也得apt升级吧。
按我把电影游戏PT挂机都装NAS上的玩法，L2ARC能塞满SM961 256G就不错了，至于缓存命中率，基本是心理安慰。

断电持久化L2ARC的事情已经吹了好几年，最新进展是这个功能暂时不会开发


就算能塞满，命中率高，由于ZFS冗杂的元数据，日常写入量爆炸，实际加速性能也会远差于直接用SSD本身的性能。