Chiphell - 分享与交流用户体验

标题: 【更新】在Linux下 SMB RDMA/TCP 的存储性能测试 [打印本页]

作者: Dolfin 时间: 2024-2-29 15:49
标题: 【更新】在Linux下 SMB RDMA/TCP 的存储性能测试
本帖最后由 Dolfin 于 2024-3-4 17:28 编辑

(, 下载次数: 85)

CPU占有率
IOmeter / 512KB顺序读取 / QD=16 / 12 Worker
吞吐 97Gb/s

(, 下载次数: 77)

写EPYC 9004 / NVMe RAID / 100GbE / RDMA 全闪NAS搭建与测试分享的时候一直执着于SMB RDMA上，所以是基于Windows Server文件存储上做的测试。近期成功在Linux上解决了SMB DIRECT的障碍，就也简单补充一下。

服务器：

9800X（8C16T) / X299 / 128G Ram / Optane 900P / ConnectX 4 40GbE / Ubuntu Server

客户端：

EPYC 9124 / 32G Ram / KIOXIA CM6 / ConnectX 4 40GbE/ Windows Server 2022

有以下猜想：
1.SMB DIRECT （RDMA）更适合大文件传输。
2.4K（小文件）传输会涉及额外开销，并不适合RDMA环境。
3.RDMA环境下，CPU占有率有明显降低。

后面还会做进一步的测试

作者: iooo 时间: 2024-2-29 16:59
感觉非常牛，有详细点的步骤吗，炒个作业

作者: awpak78 时间: 2024-2-29 17:15

NAS赶上SSD，100GbE网络大升级，升完只差100G

看起来目前版本没有比samba快多少, 而且你那还是傲疼, 只比我这堆机械ZFS池快那么点. 我如果上ksmbd还提升不到你的水平

另外ksmbd配置起来太阴间了, 感觉还得等再填一两年坑才能达到可用的状态

作者: Dolfin 时间: 2024-2-29 19:51

awpak78 发表于 2024-2-29 17:15
NAS赶上SSD，100GbE网络大升级，升完只差100G

看起来目前版本没有比samba快多少, 而且你那还是傲疼, 只 ...

配置确实难受。先达成跑通，标准测试后面再弄，现在数据只是个雷电外挂

作者: Dolfin 时间: 2024-2-29 21:48

awpak78 发表于 2024-2-29 17:15
NAS赶上SSD，100GbE网络大升级，升完只差100G

看起来目前版本没有比samba快多少, 而且你那还是傲疼, 只 ...

(, 下载次数: 83)
换了个100GbE测

作者: Dolfin 时间: 2024-2-29 21:54

iooo 发表于 2024-2-29 16:59
感觉非常牛，有详细点的步骤吗，炒个作业

谢谢，还有调试要做，后面会出个长文

作者: summerq 时间: 2024-3-1 02:23
你说的这个我也配置成功了，接下来尝到甜头之后，你就会琢磨如何提高4k性能以便加快小文件读写速度。然后你就会发现，底层spdk加ksmbd是最优解。我目前就到了这一步。但是ksmbd不太稳定，因此我就没有在平时用这个方案，等上游更新吧

作者: happysun110 时间: 2024-3-1 08:17
期待楼主的总结贴，我也很想抄个作业。

作者: QSG 时间: 2024-3-1 09:36
rdma的优势在这种低速环境下根本不在速度啊，要不你看看我的nas，猜猜这个是什么系统

作者: Dolfin 时间: 2024-3-1 09:45

summerq 发表于 2024-3-1 02:23
你说的这个我也配置成功了，接下来尝到甜头之后，你就会琢磨如何提高4k性能以便加快小文件读写速度。然后你 ...

KSMBD是个内核空间的服务，SPDK是个用户空间的工具包。
SPDK的优势就是在内核空间IO，它的传输方案SPDK nvmeOF也是用户空间的应用。
如果要结合的话，要建立个抽象层，在用户空间和内核空间并行实现SMB协议，你是怎么结合的？

作者: Dolfin 时间: 2024-3-1 10:09
本帖最后由 Dolfin 于 2024-3-1 10:11 编辑

QSG 发表于 2024-3-1 09:36
rdma的优势在这种低速环境下根本不在速度啊，要不你看看我的nas，猜猜这个是什么系统 ...

(, 下载次数: 81)

我这是Windows NAS，不用猜了。

作者: 赫敏 时间: 2024-3-1 10:11
本帖最后由赫敏于 2024-2-29 21:14 编辑

光看数据我还以为七彩虹固态。结果905p

RDMA是条死路，上限太低了尤其是4k。等哪天有DPU大船了再来组NAS
https://www.storagereview.com/re ... -to-the-data-center

作者: Exfat 时间: 2024-3-1 10:36
本帖最后由 Exfat 于 2024-3-1 10:42 编辑

赫敏发表于 2024-3-1 10:11
光看数据我还以为七彩虹固态。结果905p

RDMA是条死路，上限太低了尤其是4k。等哪天有DPU大船了再来组NAS

dpu大船早就有了博通的ps225 而且bf2的价格已经算是很便宜了

作者: Dolfin 时间: 2024-3-1 10:46

赫敏发表于 2024-3-1 10:11
光看数据我还以为七彩虹固态。结果905p

RDMA是条死路，上限太低了尤其是4k。等哪天有DPU大船了再来组NAS

按你的理解，RDMA是死路，所以DPU就跟RDMA没关系了？

作者: 赫敏 时间: 2024-3-1 10:56

Dolfin 发表于 2024-2-29 21:46
按你的理解，RDMA是死路，所以DPU就跟RDMA没关系了？

原理上肯定用到了RDMA，但现在所指的RDMA在99.99%的情况都不是DPU

作者: 赫敏 时间: 2024-3-1 10:57

Exfat 发表于 2024-2-29 21:36
dpu大船早就有了博通的ps225 而且bf2的价格已经算是很便宜了

这样啊。我去了解下

作者: QSG 时间: 2024-3-1 10:57

Dolfin 发表于 2024-3-1 10:09
我这是Windows NAS，不用猜了。

你不是ubuntu吗

作者: summerq 时间: 2024-3-1 11:05
本帖最后由 summerq 于 2024-3-1 11:41 编辑

Dolfin 发表于 2024-3-1 09:45
KSMBD是个内核空间的服务，SPDK是个用户空间的工具包。
SPDK的优势就是在内核空间IO，它的传输方案SPDK n ...

实际上我是分成两步的。首先是spdk通过vhost target来提供块存储空间到qemu，然后虚拟机的内核空间通过virtio scsi pcie设备来拿到数据，再通过ksmbd提供基于文件的存储空间。至于你说的问题，在spdk中是通过hugepage内存共享在内核空间与用户空间来传递数据的。

作者: summerq 时间: 2024-3-1 11:16

Dolfin 发表于 2024-3-1 09:45
KSMBD是个内核空间的服务，SPDK是个用户空间的工具包。
SPDK的优势就是在内核空间IO，它的传输方案SPDK n ...

另外还有一些比较特殊的心得体会。spdk的cas我试过，纸面上通过ram cache提高性能，实际上反而增加了延时，如果底层设备是optane就不要用。其次是虽然经过了qemu里的virtio scsi pcie虚拟设备，但损耗比收益小。最后就是ksmbd这边，我是用6.5的内核，不够稳定，忽然会失去响应。我在网上爬论坛看到也有人遇见同样的问题，据说要换到6.7的内核。但是我就没有换了，因为pve自身没有更高版本的内核，我也不想自己打补丁编译。目前就这么个状态吧

作者: summerq 时间: 2024-3-1 11:38

赫敏发表于 2024-3-1 10:11
光看数据我还以为七彩虹固态。结果905p

RDMA是条死路，上限太低了尤其是4k。等哪天有DPU大船了再来组NAS

dpu都是提供块设备共享，没有基于文件的。你可千万别买那个辣鸡博通的dpu，因为块设备共享你用nvmeof就完事了

作者: 赫敏 时间: 2024-3-1 13:13

summerq 发表于 2024-2-29 22:38
dpu都是提供块设备共享，没有基于文件的。你可千万别买那个辣鸡博通的dpu，因为块设备共享你用nvmeof就完 ...

这是自然，没有cpu当然不能想文件系统的事

我也没打算买博通，只是对bf2有点兴趣

作者: Dolfin 时间: 2024-3-1 15:43

summerq 发表于 2024-3-1 11:05
实际上我是分成两步的。首先是spdk通过vhost target来提供块存储空间到qemu，然后虚拟机的内核空间通过vi ...

这个方案约等于SPDK用Vhost给VM提供了块存储，而QEMU还是运行在用户空间，SPDK也在用户空间。我并没有虚拟化的场景，如果要上SPDK的话，可能需要用UBLK把用户空间的存储暴露给内核，来给主机使用。

KSMBD这边，我内核也是6.5，现在还没遇到无响应的问题，还算稳定。

作者: summerq 时间: 2024-3-1 16:39

Dolfin 发表于 2024-3-1 15:43
这个方案约等于SPDK用Vhost给VM提供了块存储，而QEMU还是运行在用户空间，SPDK也在用户空间。我并没有虚 ...

对你这个应用可以用spdk创建本地的bdev，然后ksmbd通过hugepage来交换数据。这样overhead应该比我还小很多。主要还是看你对4kq1有没有需求了。如果没有的话，不用上spdk。如果有的话，10块optane分配6个cpu内核，单线程轻松跑10m iops……

作者: aixunxian 时间: 2024-3-2 14:55

Dolfin 发表于 2024-3-1 10:09
我这是Windows NAS，不用猜了。

为啥你这个cdm跑出来顺序写入这么低呢？顺读都11G/s了写咋才5G/s

作者: Dolfin 时间: 2024-3-2 19:08

aixunxian 发表于 2024-3-2 14:55
为啥你这个cdm跑出来顺序写入这么低呢？顺读都11G/s了写咋才5G/s

硬盘规格就不行，写入指标不到读取的一半

作者: Dolfin 时间: 2024-3-3 02:31

aixunxian 发表于 2024-3-2 14:55
为啥你这个cdm跑出来顺序写入这么低呢？顺读都11G/s了写咋才5G/s

另外这有缓冲区的影响

作者: summerq 时间: 2024-3-3 03:08
本帖最后由 summerq 于 2024-3-3 03:19 编辑

有几个方向可以试试。
1. 排除掉硬盘带来的影响。用tmpfs创建一个64g的挂载点，然后用ksmbd来试试。ramdisk的4k性能是高过经过网络传输的性能的。这样约等于网卡rdma加ksmbd上限的一个测试。
2. 关掉rdma，再用ramdisk试一次。这样可以看出rdma的贡献
3. 关于底层文件系统的影响。我猜你是raid0。假设你用了4个900p，文件系统用了ext4，那么在挂载的时候可以在fstab里加上noatime试试。4k读写性能可能xfs好点。
4. 底层换spdk，用bdev创建挂载点，然后再试一次，这样做的话，底层基本上就没有瓶颈了。假设你4个optane做raid0，你就分配4个cpu物理核心跑

关于延迟，有篇文章讲的很棒
https://dl.acm.org/doi/fullHtml/10.1145/3462545

作者: summerq 时间: 2024-3-3 03:11

summerq 发表于 2024-3-3 03:08
有几个方向可以试试。
1. 排除掉硬盘带来的影响。用tmpfs创建一个64g的挂载点，然后用ksmbd来试试。ramdisk ...

另外补充一下，windows本身可能是瓶颈，不妨换linux用FIO看一下。如果你一定要用windows客户端就算了

作者: Dolfin 时间: 2024-3-3 13:36

summerq 发表于 2024-3-3 03:11
另外补充一下，windows本身可能是瓶颈，不妨换linux用FIO看一下。如果你一定要用windows客户端就算了 ...

ACM这个文得看一阵子了，感谢分享。
一些关于底层存储的额外说明：
1.实验只用了一块Optane，挂载XFS，测试结果看，Ramdisk还是Optane，在本地的性能都是达标的，不管是大文件顺序读写还是4k随机读写。（4k randread IOPS 均超过700K）

2.从SMB的结果来看，Windows下RDMA的小文件随机读写的衰减是显著的（200K上下），而TCP时可以接近700K。那么应该就是在传输这个环节出现了瓶颈，我的猜想就是RDMA对小文件处理并不理想。也期待你的测试，看是不是有类似情况。

3.有空换个系统作客户端再试一下，FIO的数据和CDM类似，都是性能差异过大。不过SMB Direct确实在Windows下场景多一些，要是Linux间的文件共享，也就不用SMB了。

作者: Dolfin 时间: 2024-3-3 15:54

summerq 发表于 2024-3-3 03:11
另外补充一下，windows本身可能是瓶颈，不妨换linux用FIO看一下。如果你一定要用windows客户端就算了 ...

从我的理解来看，小文件随机读写使用的是模式是RDMA send/receive操作，是一种双边操作，而不像 RDMA read/write 这个模式下的单边操作。前者也更像 TCP下的 send/receive，同时还需要额外的拆解重组，所以效率更低。

SMB Direct 小文件随机读写性能降低就出在这个原因上。

作者: summerq 时间: 2024-3-3 16:37
本帖最后由 summerq 于 2024-3-3 16:44 编辑

Dolfin 发表于 2024-3-3 13:36
ACM这个文得看一阵子了，感谢分享。
一些关于底层存储的额外说明：
1.实验只用了一块Optane，挂载XFS，测 ...

首先谢谢您的分享，很有帮助！
我这边会找时间测试一下。我的硬件没有你好，optane已经放在软路由上了，所以只能拿两个pm983做raid0，跑spdk+ksmbd作为服务端。客户端是vm上跑win server 2022。网卡也没有你的那么好，我目前能用的只有一个connectx-4 lx 25G

作者: Dolfin 时间: 2024-3-3 16:51
本帖最后由 Dolfin 于 2024-3-3 16:52 编辑

summerq 发表于 2024-3-3 16:37
首先谢谢您的分享，很有帮助！
我这边会找时间测试一下。我的硬件没有你好，optane已经放在软路由上了， ...

足够的。俩PM983 RAID0多线程高QD肯定也是准百万IOPS了，25GbE的CX4 应付六七十万的IOPS也没问题。就客户端那边控制RDMA开关就行，如果跟我的情况类似，肯定是巨大的差异。

作者: Bloodyevil 时间: 2024-3-3 18:06
小文件读写可以测试下iser应该可以提升不少，以前在Ubuntu环境下搭建过感觉跟本地盘无区别。

作者: Dolfin 时间: 2024-3-3 18:27

Bloodyevil 发表于 2024-3-3 18:06
小文件读写可以测试下iser应该可以提升不少，以前在Ubuntu环境下搭建过感觉跟本地盘无区别。 ...

Windows作为客户端，除了starwind可以加载iSer，还有什么推荐的？

作者: Bloodyevil 时间: 2024-3-4 11:39
iser干脆就通过IB卡PXE识别卷直接安装系统用了。至于windows客户端访问我没试过，设备也卖3年多了

作者: summerq 时间: 2024-5-15 02:38

Dolfin 发表于 2024-3-3 15:54
从我的理解来看，小文件随机读写使用的是模式是RDMA send/receive操作，是一种双边操作，而不像 RDMA re ...

今天跑了一下我只有25g网卡。linux端是connectx-4 lx，开rdma，ssd是大普微h3200。
window这边环境比较差，是跑在pve上面的一个server 2022虚拟机。cpu是9900k，网卡是connectx-6 dx
(, 下载次数: 53)

(, 下载次数: 55)

(, 下载次数: 46)

作者: Dolfin 时间: 2024-5-15 09:19

summerq 发表于 2024-5-15 02:38
今天跑了一下我只有25g网卡。linux端是connectx-4 lx，开rdma，ssd是大普微h3200。
window这边环境比较 ...

感谢测试，这次测试涉及到SPDK吗？还是只涉及到KSMBD。

从截图看，性能表现很好。
1.不过RDMA尚未开启。我这开启后，4k Q32T16这个测试就会锐降，几百兆的样子，还不知道该怎么解决。

2.我用KSMBD现在有个奇怪的问题，就是在Windows做客户端访问的时候，打开SMB挂载里的文件夹，经常会出现卡顿，好几秒的样子，切换几个文件夹，打开又会卡顿。不知道你有没有遇到过。

作者: summerq 时间: 2024-5-15 10:29

Dolfin 发表于 2024-5-15 09:19
感谢测试，这次测试涉及到SPDK吗？还是只涉及到KSMBD。

从截图看，性能表现很好。

1. 没有spdk，只有ksmbd。我这边没有遇见4k暴跌的问题
2. 以前遇见过，现在没有了。这个可能跟内核自带的ksmbd版本有关系。

作者: Dolfin 时间: 2024-5-15 11:15

summerq 发表于 2024-5-15 10:29
1. 没有spdk，只有ksmbd。我这边没有遇见4k暴跌的问题
2. 以前遇见过，现在没有了。这个可能跟内核自带的 ...

我看你现在的测试，1016MB/s 的4k q32t16的数据是在TCP下的成绩（资源管理器还能侦测流量），RDMA下能到多少？

作者: summerq 时间: 2024-5-15 11:24

Dolfin 发表于 2024-5-15 11:15
我看你现在的测试，1016MB/s 的4k q32t16的数据是在TCP下的成绩（资源管理器还能侦测流量），RDMA下能到 ...

rdma已经打开了你看我后面两张图 cpu没占用。之所以第一张图里有占用，是因为我用虚拟机，gui是web远程桌面，所以有一些

作者: summerq 时间: 2024-5-15 11:26

Dolfin 发表于 2024-5-15 11:15
我看你现在的测试，1016MB/s 的4k q32t16的数据是在TCP下的成绩（资源管理器还能侦测流量），RDMA下能到 ...

哦你说的对哦我再看看怎么回事谢谢

作者: summerq 时间: 2024-5-15 13:20
刚才又测试了一下：

服务端直通一个1.4T optane 905p
ksmbd已经启动
[attach]10870577[/attach]

rdma开启
[attach]10870578[/attach]

客户端win server 2022
[attach]10870576[/attach]

结论：
4K确实拉了。。。。。。
但不如你拉的那么厉害。。。。。。

作者: summerq 时间: 2024-5-15 13:20
刚才又测试了一下：

服务端直通一个1.4T optane 905p
ksmbd已经启动
(, 下载次数: )

rdma开启
(, 下载次数: )

客户端win server 2022
(, 下载次数: )

结论：
4K确实拉了。。。。。。
但不如你拉的那么厉害。。。。。。

作者: Dolfin 时间: 2024-5-15 19:16

summerq 发表于 2024-5-15 13:20
刚才又测试了一下：

服务端直通一个1.4T optane 905p

我q32t16从tcp的4000多直接拉到不到800。。我是没搞明白它的传输机制，而且为什么tcp能到那个数字，这超越了物理ssd的性能，内存肯定又参与了。

不过不管怎样，那个文件夹卡顿确实很头疼，重新编译了最新的ksmbd tools也一样，还是不用它搞smb了，弄个win吧

作者: summerq 时间: 2024-5-15 19:55

Dolfin 发表于 2024-5-15 19:16
我q32t16从tcp的4000多直接拉到不到800。。我是没搞明白它的传输机制，而且为什么tcp能到那个数字，这超 ...

拉到如此之低我怀疑跟rdma的驱动有关系。晚上我编译一个原厂驱动替换试试

作者: 老饭 时间: 2024-5-15 19:59
why not nvme-of

作者: Dolfin 时间: 2024-5-15 20:35

老饭发表于 2024-5-15 19:59
why not nvme-of

nvmf是传出去的是块，一对一的，而要共享的话只能用smb nfs这类的文件存储

作者: Dolfin 时间: 2024-5-15 20:39

summerq 发表于 2024-5-15 19:55
拉到如此之低我怀疑跟rdma的驱动有关系。晚上我编译一个原厂驱动替换试试 ...

我以前问过ksmbd的作者Namjae Jeon关于4k的状况，他推荐我看看这个，也分享给你。https://www.snia.org/sites/default/files/SDC/2017/presentations/smb/Li_Long_Implementing_SMBDirect_for_CIFS.pdf

作者: summerq 时间: 2024-5-16 19:19

Dolfin 发表于 2024-5-15 20:39
我以前问过ksmbd的作者Namjae Jeon关于4k的状况，他推荐我看看这个，也分享给你。https://www.snia.org/s ...

看过了。我粗略地理解就是 rdma做smb共享时数据包还是要经过内核tcp协议栈，而nvmeof + spdk不用，因此效率高。另外，我今天也试过用mellanox官方ofed驱动替换掉内核自带驱动，结果4k依然疲软。我看smb目前就是samba走tcp了，要么就两边都上windows

作者: summerq 时间: 2024-5-16 22:23

Dolfin 发表于 2024-5-15 20:39
我以前问过ksmbd的作者Namjae Jeon关于4k的状况，他推荐我看看这个，也分享给你。https://www.snia.org/s ...

我想我发现原因了。我是在pve内vm上跑ksmbd，nvme通过vfio直通。今天偶尔发现，vfuo的性能有问题。可能真的要在裸金属上直接测才有说服力。你的测试环境是在pve环境下还是裸金属啊？

作者: Dolfin 时间: 2024-5-16 23:12

summerq 发表于 2024-5-16 22:23
我想我发现原因了。我是在pve内vm上跑ksmbd，nvme通过vfio直通。今天偶尔发现，vfuo的性能有问题。可能真 ...

都测过，PVE是直通网卡，4k高QD都不过千。Windows对连的话，最高两千多吞吐，也就是500K IOPS的样子。当然nvmf轻松超百万

作者: Dolfin 时间: 2024-5-17 09:23

summerq 发表于 2024-5-16 19:19
看过了。我粗略地理解就是 rdma做smb共享时数据包还是要经过内核tcp协议栈，而nvmeof + spdk不用，因此效 ...

如果先不去管RDMA的事，ksmbd思路上还是比较高效的，在内核空间做了处理，省去了用户空间的拷贝。未来看的话，ksmbd + samba，samba + io_uring 都在进行中，还是可以展望的。

我现在的测试本意是想，在存储服务器上，建一个VM专门处理nvmf，再来一个VM专门处理SMB，结果ksmbd这出师不利。。。

欢迎光临 Chiphell - 分享与交流用户体验 (https://www.chiphell.com/)