告别单盘组建TrueNAS SCALE终极家用OpenZFS File Server, VM & More

T.JOHN · 发表于 2022-3-26 22:39

我并不觉得scale性能会比core差到哪里去，openzfs代码统一以后区别只是freebsd和linux两个底层操作系统较量。测试zfs性能也不可能用samba，而是fio测本地性能
在代码一致的情况下arc命中率是没区别的，而性能差异只能是操作系统内核层面的差异，即便bsd内存管理更高效也高了极其有限。至于生态linux不是针对谁，服务器领域其他操作系统都是垃圾。

如果只用来存视频或大文件recordsize设置为1MiB是很合理，这样scrub做checksum的时候效率是128k的8倍，只有专门跑mysql这种数据库会调到16k。而且recordsize可以随时改，只有ashift无法改。不过以楼主的硬件，跑读写密集的工作都在ssd上，用不到这个pool。

除了压缩方式可以从lz4改成zstd，楼主的方案基本没什么可优化的地方了。

楼主的方案过设计了，zfs其实最朴实就是64G~1T ECC mem+HDD x N+16G 傲腾 slog就行了，除了重建的时候CPU占用高一些，其他时候不太占资源

dsboylw · 发表于 2022-3-26 23:00

oldnetdog 发表于 2022-3-26 21:17
这个机箱不是只能18个3.5的HDD吗？怎么可以安装24块盘的？

水冷机上不是放了一摞硬盘吗？箱子也没盖盖子，应该是minisas拉出来一根

jerrytsao · 发表于 2022-3-26 23:12

linchen0950 发表于 2022-3-26 21:00
超过26个硬盘，编号是sdaa开始吗

嗯, Linux都一样的

jerrytsao · 发表于 2022-3-26 23:14

oldnetdog 发表于 2022-3-26 21:45
J叔不是写了24块盘，不知道咋安装上的。

晚些会定制个32盘机箱, 目前8盘放在外面的笼子, 不想用机柜...

堕天使星颖 · 发表于 2022-3-26 23:23

FlexRAID官网都没了。。

雨前龙井 · 发表于 2022-3-26 23:24

豪华

jerrytsao · 发表于 2022-3-26 23:34

堕天使星颖发表于 2022-3-26 23:23
FlexRAID官网都没了。。

这东西一直没细看, 已经Dead了

推荐列表里删掉

jerrytsao · 发表于 2022-3-26 23:42

本帖最后由 jerrytsao 于 2022-3-26 23:45 编辑

T.JOHN 发表于 2022-3-26 22:39
我并不觉得scale性能会比core差到哪里去，openzfs代码统一以后区别只是freebsd和linux两个底层操作系统较量 ...

选ZSTD无后缀, ZSTD-1还是ZSTD-19, 看了些文档还不是很明确, 7T83确实应该利用其压缩/解压性能优势

goat · 发表于 2022-3-26 23:43

jerrytsao 发表于 2022-3-26 21:46
UnRAID更多的是Marketing, 就像一个魔改版JBOD, Parity不完全, Reliability也不够, 还要付费, 唯一的强项 ...

但是现在snapraid要跑crontab，flex好像几乎处于停滞状态。开箱即食，又可以整合一堆乱乱七八糟容量且带实时校验的没选了

哪位大佬快点整合一个带mergerfs的nas系统吧

leeosx · 发表于 2022-3-26 23:53

T.JOHN 发表于 2022-3-26 22:39
我并不觉得scale性能会比core差到哪里去，openzfs代码统一以后区别只是freebsd和linux两个底层操作系统较量 ...

大佬。我全默认设置 18个18t...为啥samba共享下面读写速度基本上就是600/200的样子raidz2...文件是单个60g的
64g内存

blasaw · 发表于 2022-3-27 00:36

这机箱是怎么装24个机械盘的。。

Juzi丶 · 发表于 2022-3-27 05:57

jerrytsao 发表于 2022-3-26 23:42
选ZSTD无后缀, ZSTD-1还是ZSTD-19, 看了些文档还不是很明确, 7T83确实应该利用其压缩/解压性能优势 ...

zstd速度太慢
而且对于多媒体内容的压缩率是毫无意义的（因为根本没得压）
但不能也不建议关闭压缩
所以默认lz4就是最好使的

https://github.com/openzfs/zfs/pull/10278
https://github.com/openzfs/zfs/pull/12805

Juzi丶 · 发表于 2022-3-27 06:12

T.JOHN 发表于 2022-3-26 22:39
我并不觉得scale性能会比core差到哪里去，openzfs代码统一以后区别只是freebsd和linux两个底层操作系统较量 ...

至于性能这个不信的话你可以自己测一下看看，我又不是瞎吹

就记录大小来举例

1MiB的块大小就算是最外圈拿常见的HC320来算也需要200ms以上的io时间，而128KiB则是18±6ms之间

kingkiss · 发表于 2022-3-27 08:23

期待关于网络配置和测试的文章，我也组了个TRUENAS SCALE，全NVME固态池25G网卡SMB读取只能跑1.2G/S还很不稳定，写入只有500M-800/S，一直都没弄明白为什么。

T.JOHN · 发表于 2022-3-27 10:44

jerrytsao 发表于 2022-3-26 23:42
选ZSTD无后缀, ZSTD-1还是ZSTD-19, 看了些文档还不是很明确, 7T83确实应该利用其压缩/解压性能优势 ...

偏向省空间选5，偏向性能得选1，或者负值。可以参考 https://community.centminmod.com ... p2-vs-xz-etc.18669/

zstd算是19/20年引入zfs最重要两个特性之一了，同期还有个特性就是本地加密，类似bitlocker，0.8.0引入，0.8.4切换成aes-256-gcm算法。不过它没bitlocker方便，把秘钥存在微软服务器上，得把一长串字符给本地记下来，否则无了。

作为存储文件系统能省空间是很有必要的。在此之前lz4和gzip是zfs主要压缩方式，所以他主要用来对标gzip，比gzip压缩率高，占用资源更少，解压速度远高于gzip，属于gzip完全上位的算法。

facebook 2015年开始从新造轮子主要是它网站fb+ins数据量实在太大了，压缩能省非常多得成本，但又不能影响用户体验，所以设计一个压缩率优秀，但更重要的是可以"在线解压"的压缩方式，也就是解压速度要能很快加载这些网页内容。所以和传统备份压缩算法追求极致压缩率的bzip，xz之类目的不一样。我觉得是很适合需要在线读取内容的服务器用，也不用我觉得，反正facebook验证过显然很靠谱，至于lz4基本就没什么压缩，聊胜于无的类型。

不过楼上说了对，如果全视频文件，是没什么可以压的了，而且recordsize设成了1MiB就更没什么可以压的了，甚至可以不开压缩。不过我觉得也不能所有文件都是h.264/hevc之类的视频，总要有些文档之类的，而且那么强的性能开lz4肯定不如zstd。

T.JOHN · 发表于 2022-3-27 10:56

Juzi丶发表于 2022-3-27 06:12
至于性能这个不信的话你可以自己测一下看看，我又不是瞎吹

就记录大小来举例

视频文件不需要高IOPS，而且楼主qbit临时文件放在ssd上，下载下来得视频就没有随机读取，自然也不需要寻道。

我不是没看过zfs性能测试，ddg搜索前三条都是一个人测的 https://openbenchmarking.org/result/2109269-IB-DEBXCPNGT86
它测的都是网络性能，是scale和core综合对比。但zfs本地性能它没测，显然这里有两部分，一部分是zfs本地性能，另一部分是网络性能iscsi，nfs和smb，第二部分显然和zfs无关，是应用层的事情了。像我这种用zfs，不用truenas显然不能被它的测试代表

T.JOHN · 发表于 2022-3-27 12:24

本帖最后由 T.JOHN 于 2022-3-27 12:38 编辑

leeosx 发表于 2022-3-26 23:53
大佬。我全默认设置 18个18t...为啥samba共享下面读写速度基本上就是600/200的样子raidz2...文件是单个60 ...

先查本地性能再查smb问题

1. 本地性能可以用fio测

fio -ioengine=libaio -bs=128k -direct=1 -thread -rw=read -filename=/zpool/test -name="BS 128k read test" -iodepth=1 -numjobs=1 -size=100G -runtime=60

复制代码

rw 把read改成write就是写
filename - 你读的时候可以找个池里大文件读。写的时候文件名别和其他不要一样，否则会覆盖掉
size - 是文件大小，你的盘多，100G写入很快的，你可以调整
runtime - 是最多跑1分钟

18个18T，我不知道你的盘结构，假设你是raidz2，就是16个盘工作，单盘算平均150mb/s，连续读的速度2.4G，算上损耗*0.8，应该2G左右，写会比读慢，大约就一半。

2. samba可以先更新下版本，输入smbd -V，如果太老更新下

其次看协议是否都正常开启了，用nmap扫描，

nmap --script smb-protocols IP

复制代码

IP改成你服务器局域网IP

现在基本都不用1.0了，你尽量保证3.11开启以适配你win10或者win11

然后你可以调优smb参数，配置文件一般在/etc/samba/smb.conf

use sendfile = yes
server multi channel support = yes
aio read size = 1
aio write size = 1
write cache size = 262144 -- 这一条参数在4.12版本以后没了
min receivefile size = 16384
getwd cache = yes
unix extensions = yes
socket options = TCP_NODELAY IPTOS_LOWDELAY

复制代码

这些是我用的，具体说明参考
https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html
https://wiki.archlinux.org/title/Samba_(%E7%AE%80%E4%BD%93%E4%B8%AD%E6%96%87)

编辑：注释write cache size参数为无效

leeosx · 发表于 2022-3-27 12:26

T.JOHN 发表于 2022-3-27 12:24
先查本地性能再查smb问题

1. 本地性能可以用fio测

谢谢。。我晚点从新装个truenas scale试试看。。谢谢

rakuhin · 发表于 2022-3-27 18:22

好贴，不知道在esxi下装truenas scale会不会有性能损失，比较习惯用esxi装虚拟机。

kingkiss · 发表于 2022-3-27 19:02

T.JOHN 发表于 2022-3-27 12:24
先查本地性能再查smb问题

1. 本地性能可以用fio测

大神按照你的方法用FIO测试了一下各个池读取都正常但是写入诡异的只有430MB/S左右，一个8盘HDD raidz2,一个4盘U2 raidz1,不知道咋回事

T.JOHN · 发表于 2022-3-27 19:51

本帖最后由 T.JOHN 于 2022-3-27 19:53 编辑

kingkiss 发表于 2022-3-27 19:02
大神按照你的方法用FIO测试了一下各个池读取都正常但是写入诡异的只有430MB/S左右，一个8盘HDD raidz2, ...

上面给的命令是测区块大小128k，单线程，单队列深度的吞吐量。

8盘HDD raidz2 430MB/S偏低，但我不能说不正常。我6盘hc320 mirror大概是544MiB/s (571MB/s)，供你参考。如果你想好看，可以把numjob调到2甚至更多，然后增加个参数-group_reporting，你就会看到吞吐量显著提升，因为是多线程速度。如果想看raidz2性能，你尝试BS设成1M，iodepth适当增加，比如4/8/16。

fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=write -filename="/storage/test" -name="BS 4k write test" -iodepth=1 -numjobs=1 -size=10G -runtime=60 ###测试命令
BS 1M write test: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=1
fio-3.7
Starting 1 thread
Jobs: 1 (f=1): [W(1)][100.0%][r=0KiB/s,w=551MiB/s][r=0,w=141k IOPS][eta 00m:00s]
BS 4k write test: (groupid=0, jobs=1): err= 0: pid=7595: Mon May 18 09:42:34 2020
write: IOPS=139k, BW=544MiB/s (571MB/s)(10.0GiB/18809msec)
slat (usec): min=3, max=2060, avg= 6.11, stdev= 9.35
clat (nsec): min=591, max=167075, avg=713.06, stdev=690.50
lat (usec): min=4, max=2068, avg= 6.91, stdev= 9.45
clat percentiles (nsec):
| 1.00th=[ 604], 5.00th=[ 612], 10.00th=[ 612], 20.00th=[ 620],
| 30.00th=[ 620], 40.00th=[ 628], 50.00th=[ 652], 60.00th=[ 684],
| 70.00th=[ 700], 80.00th=[ 700], 90.00th=[ 716], 95.00th=[ 796],
| 99.00th=[ 1144], 99.50th=[ 1512], 99.90th=[12480], 99.95th=[13248],
| 99.99th=[17536]
bw ( KiB/s): min=518648, max=644352, per=99.95%, avg=557217.08, stdev=24743.32, samples=37
iops : min=129660, max=161088, avg=139304.27, stdev=6185.89, samples=37
lat (nsec) : 750=94.30%, 1000=4.04%
lat (usec) : 2=1.25%, 4=0.05%, 10=0.06%, 20=0.30%, 50=0.01%
lat (usec) : 250=0.01%
cpu : usr=17.50%, sys=81.11%, ctx=7348, majf=0, minf=105
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,2621440,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: bw=544MiB/s (571MB/s), 544MiB/s-544MiB/s (571MB/s-571MB/s), io=10.0GiB (10.7GB), run=18809-18809msec

复制代码

U.2盘你测错目录了？没道理那么低的，除非你CPU 100%满了。U.2你可以尝试把iodepth调到32再测一遍，和上面一样，numjob调高后你会看到很爆炸的数据，甚至超过理论值。另外你的系统是裸装的还是虚拟机直通的？虚拟机会有损失，可能各种各样问题，建议裸系统测，以下9200max的单盘zfs数据供你参考

[root@server ~]# fio -ioengine=libaio -bs=128k -direct=1 -thread -rw=write -filename=/NVMe/test -name="BS 128k write test" -iodepth=32 -numjobs=1 -size=10G -runtime=60 -group_reporting
BS 128k write test: (g=0): rw=write, bs=(R) 128KiB-128KiB, (W) 128KiB-128KiB, (T) 128KiB-128KiB, ioengine=libaio, iodepth=32
fio-3.19
Starting 1 thread
BS 128k read test: Laying out IO file (1 file / 10240MiB)
Jobs: 1 (f=1): [W(1)][100.0%][w=1628MiB/s][w=13.0k IOPS][eta 00m:00s]
BS 128k read test: (groupid=0, jobs=1): err= 0: pid=383810: Sun Mar 27 19:32:04 2022
write: IOPS=16.5k, BW=2058MiB/s (2158MB/s)(10.0GiB/4976msec); 0 zone resets
slat (usec): min=27, max=480, avg=58.48, stdev=39.37
clat (usec): min=2, max=5006, avg=1883.69, stdev=624.91
lat (usec): min=36, max=5153, avg=1942.43, stdev=641.04
clat percentiles (usec):
| 1.00th=[ 1057], 5.00th=[ 1172], 10.00th=[ 1237], 20.00th=[ 1336],
| 30.00th=[ 1450], 40.00th=[ 1582], 50.00th=[ 1696], 60.00th=[ 1876],
| 70.00th=[ 2147], 80.00th=[ 2442], 90.00th=[ 2835], 95.00th=[ 3097],
| 99.00th=[ 3589], 99.50th=[ 3818], 99.90th=[ 4424], 99.95th=[ 4621],
| 99.99th=[ 4883]
bw ( MiB/s): min= 1639, max= 2870, per=100.00%, avg=2082.28, stdev=528.17, samples=9
iops : min=13114, max=22964, avg=16658.11, stdev=4225.28, samples=9
lat (usec) : 4=0.01%, 50=0.01%, 100=0.01%, 250=0.01%, 500=0.01%
lat (usec) : 750=0.01%, 1000=0.01%
lat (msec) : 2=64.79%, 4=34.98%, 10=0.21%
cpu : usr=8.36%, sys=66.07%, ctx=13714, majf=0, minf=2113
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued rwts: total=0,81920,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=32
Run status group 0 (all jobs):
WRITE: bw=2058MiB/s (2158MB/s), 2058MiB/s-2058MiB/s (2158MB/s-2158MB/s), io=10.0GiB (10.7GB), run=4976-4976msec

复制代码

kingkiss · 发表于 2022-3-27 19:57

本帖最后由 kingkiss 于 2022-3-27 20:01 编辑

T.JOHN 发表于 2022-3-27 19:51
上面给的命令是测区块大小128k，单线程，单队列深度的吞吐量。

8盘HDD raidz2 430MB/S偏低，但我不能说 ...

用新的代码测试了一下，写入速度还是只有500M/S，盘是铠侠CD6 7.68T 4个，组的raidz1,读取速度倒是正常的，另外一个两盘PM1733组的mirror池也一样写入只有450MB/S

kaixin_chh · 发表于 2022-3-27 20:02

神贴留个名，等以后发达了再来抄作业

T.JOHN · 发表于 2022-3-27 20:25

kingkiss 发表于 2022-3-27 19:57
用新的代码测试了一下，写入速度还是只有500M/S，盘是铠侠CD6 7.68T 4个，组的raidz1,读取速度倒是正常的 ...

读速度正常说明硬件都没问题，你所有池的写卡450MB/S就很奇怪了，所以我觉得测错目录了，除此之外我想不出啥原因了。有report没？我怕U.2利用率都没10%，

解决办法可能把zfs版本升级一下可能解决，zfs -V可以看版本，最新稳定版本是2.0.7或2.1.4

kingkiss · 发表于 2022-3-27 20:46

T.JOHN 发表于 2022-3-27 20:25
读速度正常说明硬件都没问题，你所有池的写卡450MB/S就很奇怪了，所以我觉得测错目录了，除此之外我想不 ...

$X%3]13RTDW_VF{VPU]@J8]E.jpg$ FCJE@LW{3WT[DB3OA0DYDNH.jpg

我也觉得很奇怪，一直找不到原因

T.JOHN · 发表于 2022-3-27 21:36

kingkiss 发表于 2022-3-27 20:46
我也觉得很奇怪，一直找不到原因

你写的时候clat percentiles(us)是HDD水平，lat(msec) 10=89.7%，意思延时总体是10ms，我看了下我之前机械单盘测试结果就是这水平，显然你写在了HDD的池子里。你可以再测一次，跑机箱旁边听听声音就知道了，必定有硬盘咔咔的声音。

你读的时候lat(nsec) 500=93.34%，意思是总体延时500ns，属于SSD水平。500ns和10ms差了2万倍。

至于为啥你读写路径一样，却没写到SSD池，我也不知道。你可以用

zfs get mountpoint

复制代码

检查挂载点，别把固态池放在机械池的子目录下，也许能解决问题。

jerrytsao · 发表于 2022-3-27 23:04

本帖最后由 jerrytsao 于 2022-3-27 23:28 编辑

T.JOHN 发表于 2022-3-27 10:44
偏向省空间选5，偏向性能得选1，或者负值。可以参考 https://community.centminmod.com/threads/round-4- ...

每个原盘文件夹下(除BDMV子文件夹之外)有一些小文件, 其它基本都是视频文件了

反正CPU性能高, 主存容量也够大, 我直接选了ZSTD-19, 对视频文件也没啥影响

T.JOHN · 发表于 2022-3-28 00:26

jerrytsao 发表于 2022-3-27 23:04
每个原盘文件夹下(除BDMV子文件夹之外)有一些小文件, 其它基本都是视频文件了

反正CPU性能高, 主存容量 ...

19我只能说充分利用CPU

scrub和smart长测我觉得不用两周一次那么频繁的，一个月一次就很充分了。白嫖王是万年不维护才丢的数据，一方面WD和ST两家的企业盘都很可靠，另一方面有ECC内存出错概率很低。
主要smart长测的时候真的非常吵，尤其盘多情况下，18T估计要20小时+，我已经懒到半年测一次了，平时用10天一次的短测替代。

jerrytsao · 发表于 2022-3-28 00:38

T.JOHN 发表于 2022-3-28 00:26
19我只能说充分利用CPU
scrub和smart长测我觉得不用两周一次那么频繁的，一个月一次就很充分了。白 ...

建议不错

风车车 · 发表于 2022-3-28 01:25

风车车看不懂这些，因为他买不起你们这些高端电脑！

账号		自动登录	找回密码
密码			加入我们

[NAS] 告别单盘组建TrueNAS SCALE终极家用OpenZFS File Server, VM & More