【更新】在Linux下 SMB RDMA/TCP 的存储性能测试

Dolfin · 发表于 2024-2-29 15:49

本帖最后由 Dolfin 于 2024-3-4 17:28 编辑

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

写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快多少, 而且你那还是傲疼, 只 ...

换了个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，猜猜这个是什么系统 ...

我这是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 小文件随机读写性能降低就出在这个原因上。

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

[网络] 【更新】在Linux下 SMB RDMA/TCP 的存储性能测试