![SMB 多通道固定几个 CPU 核心且不会达到 NIC 饱和](https://linux22.com/image/781795/SMB%20%E5%A4%9A%E9%80%9A%E9%81%93%E5%9B%BA%E5%AE%9A%E5%87%A0%E4%B8%AA%20CPU%20%E6%A0%B8%E5%BF%83%E4%B8%94%E4%B8%8D%E4%BC%9A%E8%BE%BE%E5%88%B0%20NIC%20%E9%A5%B1%E5%92%8C.png)
我有两台服务器,安装了启用了双 RDMA 的 25GbE NIC。目前,在测试期间,它们是直接连接的……它们之间没有交换机。如果我只在它们之间建立单个 SFP28 连接,我可以轻松使 25GbE 链路饱和。但是,当我设置第二个时,我最多可以达到 35Gbps,而不是所需的 50Gbps。
不想让您感到无聊,也不想详细介绍所有配置细节……我已经确定,在单个 25GbE 连接期间,SMB 多通道会自动为连接分配 4 个通道,这足以使 4 个 CPU 内核在长/大文件传输期间的利用率达到约 70%(125GB 传输约需 45 秒)。但是,当两个 NIC 配置在一起时,每个 NIC 仅分配 2 个通道……因此,总共只有 4 个。但是,此时,CPU 内核(而不是 NIC)是瓶颈,分配的 4 个内核达到 100% CPU,从而将吞吐量限制在 35Gbps。(值得一提的是,两侧的 NVMe 存储都开始略微紧张……但就我目前注意到的情况而言,没有任何存储资源的利用率超过 60%)
我无法找到一种方法来覆盖连接的分配通道。我想将其设置为每个 NIC 4 个(服务器到服务器连接总共 8 个),但我似乎找不到支持覆盖该设置的任何命令。运行获取 SmbServer 配置和获取 SmbClient 配置都显示每个服务器的最大连接数设置为 32。运行获取 SmbMultichannelConnection | FL将显示单独的连接设置...但是,似乎没有互补的“Set-Smb ...”命令来更改这些值。
我确信这很简单,我只是忽略了一些显而易见的事情……但是,到目前为止,搜索互联网并没有找到任何线索。因此,任何帮助都将不胜感激。
答案1
好的...因此,我最初发布的问题的答案隐藏在 Windows 注册表设置中。
HKLM\System\CurrentControlSet\Services\LanmanWorkstation\参数\ConnectionCountPerRdmaNetworkInterface
该键通常不存在于注册表中,如果未指定,则默认值为 2,但可以设置为 1 - 16。根据微软的这篇文章。
https://learn.microsoft.com/en-us/windows-server/administration/performance-tuning/role/file-server/
根据文章,这或多或少是一种“只可看不可摸”的设置。但奇怪的是,在同一地点有一个非常相似的设置……
HKLM\System\CurrentControlSet\Services\LanmanWorkstation\参数\ConnectionCountPerRssNetworkInterface
它也建议不要更改。但尽管如此,他们还是通过 PowerShell 公开了它,可以通过以下方式查看和更改它:获取\设置 SmbClientConfiguration。为什么他们选择揭露其中一个,而不揭露另一个,这有点令人费解。
编辑+完整答案:
系统信息参考:
CPU:AMD EPYC 7313P 操作系统:Windows Server 2022 NIC:Intel E810-XXVDA2 驱动程序:Intel ProSet 27.6.1 流量测试:Windows 文件复制(传输 +100 个随机生成的 1GB 数据文件)- 具有讽刺意味的是,这具有最佳和最一致的结果。DiskSpd(借助 Microsoft 的 Test-Rdma.ps1)- 我调整了脚本输出以显示 kb、Mb、Gb 等,以使其更易于阅读。iPerf3 - 由于某种原因,设置变化无常,并且运行结果通常不一致。更正:
在原始帖子中,我提到了在启用第二个 SFP28 连接之前连接数为 4,但在启用第二个 SFP28 连接之后连接数为 2。嗯……事后看来,这有点不正确。允许 4 对 2 的原因是,当只有一个连接时,我还没有在 NIC 上启用 RDMA。如果没有 RMDA,SMB MultiChannel 将使用 RSS,并且有一个不同的设置……它很方便地具有默认值 4(请参阅我在发布的答案中提到的注册表项)。所以,就从 4 切换到 2 而言……这是我的错误。
最终解决方案:
在浏览了大量网站、多次关闭并重新创建连接后,我终于弄清楚了发生了什么。我最终通过更改其他 2 个设置(而不仅仅是我正在寻找的注册表项)解决了这个问题。
首先,该领域的许多大公司(微软、英特尔、nVidia、联想等)都建议禁用标准 RX/TX 流量控制。嗯……对于我的特定用例来说,这是一个糟糕的建议。重新启用流量控制有很大帮助。关闭标准流量控制的建议是改用基于优先级的流量控制 (PFC) 和数据中心桥接 (DCB)。但是……要使其正常工作,您的交换机还需要支持 PFC。虽然服务器之间的直接连接对此没有问题,但部署后位于它们之间的交换机不支持 DCB……所以,我想在不使用此功能的情况下继续。此外,使用 iWARP 时并不严格需要 PFC(它有助于提高性能……但不是成败攸关的要求)。所以,从我的测试来看,如果您不能使用带 DCB 的 PFC,您至少应该回退到使用标准 RX/TX 流量控制……这是我应该早点注意的事情。
另一个来自权威人士的建议是更改中断调节率或中断节流率 (ITR) 的设置。默认设置为“自适应”,但建议将其设置为禁用或关闭。更改此设置是一种平衡行为,在提高速度和降低延迟与响应更多来自 NIC 的中断请求导致的更高 CPU 使用率之间进行权衡。由于我的 CPU 遇到了瓶颈,我将设置从 OFF 更改为 LOW。
无论如何……这些是我必须更改的关键设置,以最终解决我的特定 CPU 固定问题。希望如果有人偶然发现这篇文章并遇到同样的问题,这将帮助他们更接近解决方案。