【更新】在Linux下 SMB RDMA/TCP 的存储性能测试
本帖最后由 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占有率有明显降低。
后面还会做进一步的测试 感觉非常牛，有详细点的步骤吗，炒个作业[傻笑] https://static.chiphell.com/forum/202304/03/202422g85lxvtt8v5fw4ok.jpg
NAS赶上SSD，100GbE网络大升级，升完只差100G
看起来目前版本没有比samba快多少, 而且你那还是傲疼, 只比我这堆机械ZFS池快那么点. 我如果上ksmbd还提升不到你的水平
另外ksmbd配置起来太阴间了, 感觉还得等再填一两年坑才能达到可用的状态 awpak78 发表于 2024-2-29 17:15
NAS赶上SSD，100GbE网络大升级，升完只差100G
看起来目前版本没有比samba快多少, 而且你那还是傲疼, 只 ...
配置确实难受。先达成跑通，标准测试后面再弄，现在数据只是个雷电外挂 awpak78 发表于 2024-2-29 17:15
NAS赶上SSD，100GbE网络大升级，升完只差100G
看起来目前版本没有比samba快多少, 而且你那还是傲疼, 只 ...
换了个100GbE测 iooo 发表于 2024-2-29 16:59
感觉非常牛，有详细点的步骤吗，炒个作业
谢谢，还有调试要做，后面会出个长文 你说的这个我也配置成功了，接下来尝到甜头之后，你就会琢磨如何提高4k性能以便加快小文件读写速度。然后你就会发现，底层spdk加ksmbd是最优解。我目前就到了这一步。但是ksmbd不太稳定，因此我就没有在平时用这个方案，等上游更新吧 期待楼主的总结贴，我也很想抄个作业。
rdma的优势在这种低速环境下根本不在速度啊，要不你看看我的nas，猜猜这个是什么系统 summerq 发表于 2024-3-1 02:23
你说的这个我也配置成功了，接下来尝到甜头之后，你就会琢磨如何提高4k性能以便加快小文件读写速度。然后你 ...
KSMBD是个内核空间的服务，SPDK是个用户空间的工具包。
SPDK的优势就是在内核空间IO，它的传输方案SPDK nvmeOF也是用户空间的应用。
如果要结合的话，要建立个抽象层，在用户空间和内核空间并行实现SMB协议，你是怎么结合的？ 本帖最后由 Dolfin 于 2024-3-1 10:11 编辑
QSG 发表于 2024-3-1 09:36
rdma的优势在这种低速环境下根本不在速度啊，要不你看看我的nas，猜猜这个是什么系统 ...
我这是Windows NAS，不用猜了。 本帖最后由 赫敏 于 2024-2-29 21:14 编辑
光看数据我还以为七彩虹固态。结果905p
RDMA是条死路，上限太低了尤其是4k。等哪天有DPU大船了再来组NAS
https://www.storagereview.com/review/fungible-fs1600-pushes-hyperscale-storage-to-the-data-center 本帖最后由 Exfat 于 2024-3-1 10:42 编辑
赫敏 发表于 2024-3-1 10:11
光看数据我还以为七彩虹固态。结果905p
RDMA是条死路，上限太低了尤其是4k。等哪天有DPU大船了再来组NAS
dpu大船早就有了 博通的ps225 而且bf2的价格已经算是很便宜了 赫敏 发表于 2024-3-1 10:11
光看数据我还以为七彩虹固态。结果905p
RDMA是条死路，上限太低了尤其是4k。等哪天有DPU大船了再来组NAS
按你的理解，RDMA是死路，所以DPU就跟RDMA没关系了？ Dolfin 发表于 2024-2-29 21:46
按你的理解，RDMA是死路，所以DPU就跟RDMA没关系了？
原理上肯定用到了RDMA，但现在所指的RDMA在99.99%的情况都不是DPU Exfat 发表于 2024-2-29 21:36
dpu大船早就有了 博通的ps225 而且bf2的价格已经算是很便宜了
这样啊。我去了解下 Dolfin 发表于 2024-3-1 10:09
我这是Windows NAS，不用猜了。
你不是ubuntu吗 本帖最后由 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内存共享在内核空间与用户空间来传递数据的。 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自身没有更高版本的内核，我也不想自己打补丁编译。目前就这么个状态吧 赫敏 发表于 2024-3-1 10:11
光看数据我还以为七彩虹固态。结果905p
RDMA是条死路，上限太低了尤其是4k。等哪天有DPU大船了再来组NAS
dpu都是提供块设备共享，没有基于文件的。你可千万别买那个辣鸡博通的dpu，因为块设备共享你用nvmeof就完事了 summerq 发表于 2024-2-29 22:38
dpu都是提供块设备共享，没有基于文件的。你可千万别买那个辣鸡博通的dpu，因为块设备共享你用nvmeof就完 ...
这是自然，没有cpu当然不能想文件系统的事
我也没打算买博通，只是对bf2有点兴趣 summerq 发表于 2024-3-1 11:05
实际上我是分成两步的。首先是spdk通过vhost target来提供块存储空间到qemu，然后虚拟机的内核空间通过vi ...
这个方案约等于SPDK用Vhost给VM提供了块存储，而QEMU还是运行在用户空间，SPDK也在用户空间。我并没有虚拟化的场景，如果要上SPDK的话，可能需要用UBLK把用户空间的存储暴露给内核，来给主机使用。
KSMBD这边，我内核也是6.5，现在还没遇到无响应的问题，还算稳定。 Dolfin 发表于 2024-3-1 15:43
这个方案约等于SPDK用Vhost给VM提供了块存储，而QEMU还是运行在用户空间，SPDK也在用户空间。我并没有虚 ...
对 你这个应用可以用spdk创建本地的bdev，然后ksmbd通过hugepage来交换数据。这样overhead应该比我还小很多。主要还是看你对4kq1有没有需求了。如果没有的话，不用上spdk。如果有的话，10块optane分配6个cpu内核，单线程轻松跑10m iops…… Dolfin 发表于 2024-3-1 10:09
我这是Windows NAS，不用猜了。
为啥你这个cdm跑出来顺序写入这么低呢？顺读都11G/s了写咋才5G/s aixunxian 发表于 2024-3-2 14:55
为啥你这个cdm跑出来顺序写入这么低呢？顺读都11G/s了写咋才5G/s
硬盘规格就不行，写入指标不到读取的一半 aixunxian 发表于 2024-3-2 14:55
为啥你这个cdm跑出来顺序写入这么低呢？顺读都11G/s了写咋才5G/s
另外这有缓冲区的影响 本帖最后由 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:08
有几个方向可以试试。
1. 排除掉硬盘带来的影响。用tmpfs创建一个64g的挂载点，然后用ksmbd来试试。ramdisk ...
另外补充一下，windows本身可能是瓶颈，不妨换linux用FIO看一下。如果你一定要用windows客户端就算了 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了。 summerq 发表于 2024-3-3 03:11
另外补充一下，windows本身可能是瓶颈，不妨换linux用FIO看一下。如果你一定要用windows客户端就算了 ...
从我的理解来看，小文件随机读写使用的是模式是RDMAsend/receive操作，是一种双边操作，而不像 RDMA read/write 这个模式下的单边操作。前者也更像 TCP下的 send/receive，同时还需要额外的拆解重组，所以效率更低。
SMB Direct 小文件随机读写性能降低就出在这个原因上。
页:
[1]
2