R4930G5H3网卡iperf带宽异常

问题根源深度解析

您的分析完全正确，问题的核心不在于100G网络本身，而在于服务器​​内存子系统无法为网络子系统提供足够的数据吞吐能力​​。

1. 1.

   ​​iperf的传统工作模式​​：

   • •

     iperf（尤其是默认的TCP测试）是一个运行在​​操作系统内核空间​​的应用程序。

   • •

     其数据流需要经历多次内存拷贝：应用层内存 -> 内核缓冲区 -> 网卡驱动缓冲区。这正是您提到的“两次数据拷贝”。

   • •

     这个过程需要CPU大量参与，消耗巨大的​​CPU周期​​和​​内存带宽​​。

2. 2.

   ​​内存带宽瓶颈​​：

   • •

     ​​理论值​​：双路海光7380（16通道DDR4）的理论内存带宽非常高。以DDR4-3200为例，单通道理论带宽约25.6 GB/s，16通道可达 ​​~409.6 GB/s​​。

   • •

     ​​实测值​​：您用MBW测出的​​36 GB/s​​是一个非常重要的指标，说明当前配置远未达到理论性能。这通常是由于：

     • •

       ​​内存频率未达最大值​​：可能在BIOS中运行在较低频率。

     • •

       ​​NUMA架构影响​​：海光7380是双路CPU，构成两个NUMA节点。如果应用程序（或iperf进程）在一个NUMA节点上运行，而它访问的内存位于另一个NUMA节点（​​远程访问​​），延迟会显著增加，带宽会大幅下降。​​这是最常见的原因之一​​。

     • •

       ​​内存条配置未优化​​：没有在所有内存通道上安装内存条，或者安装方式无法实现最大通道带宽。

3. 3.

   ​​性能折算​​：

   • •

     正如您所说，iperf等传统网络基准测试工具的效率约为内存带宽的1/3。

   • •

     36 GB/s 内存带宽 ≈ 288 Gb/s，除以3后，​​理论最大网络吞吐量即为 ~96 Gb/s​​，这与您的90Gb测试结果高度吻合。

解决方案与优化建议

要突破这个瓶颈，必须从“减少数据拷贝”和“优化内存访问”两个方向入手。

方向一：优化服务器基础配置（治标）

1. 1.

   ​​BIOS设置优化​​：

   • •

     ​​确保内存频率运行在最高档​​：例如DDR4-3200。检查BIOS中是否有降频情况。

   • •

     ​​启用NUMA模式​​：确保BIOS中NUMA功能为 Enabled。

   • •

     ​​检查电源性能模式​​：设置为 Performance最高性能模式，而非 Power Saving。

2. 2.

   ​​操作系统与进程绑定（NUMA优化）​​：

   • •

     ​​确认NUMA拓扑​​：使用 numactl -H命令查看NUMA节点的分布情况。

   • •

     ​​绑定进程与内存​​：运行iperf时，将其绑定到同一个NUMA节点上，并指定内存分配策略。

     • •

       例如，如果网卡p1p1挂在NUMA Node 0上：

       # 将iperf服务端绑定在Node 0，并且只在Node 0上分配内存 numactl --cpunodebind=0 --membind=0 iperf3 -s
     • •

       在另一台机器上启动客户端测试。

   • •

     ​​IRQ中断绑定​​：将网卡的中断请求（IRQ）也绑定到对应的NUMA节点的CPU核心上，这通常需要手动脚本或通过irqbalance配置完成。

方向二：采用高性能网络测试方法（治本）

这是最能体现100G网络性能的方案，旨在彻底绕过传统TCP/IP栈的开销。

1. 1.

   ​​使用RDMA进行测试​​：

   • •

     既然您已经配置了​​RoCE​​，就应该使用支持RDMA的测试工具，这才是100G网络的“正确打开方式”。

   • •

     RDMA实现了“内核旁路”（Kernel Bypass）和“零拷贝”（Zero-Copy），数据直接从用户内存传输到网卡，几乎不消耗CPU，也极大减轻了内存带宽压力。

   • •

     ​​推荐工具​​：

     • •

       ​​perftest​​ 工具包中的 ib_send_bw和 ib_write_bw。

     • •

       ​​NVIDIA的 nv_rdma​​ 工具。

   • •

     ​​示例命令​​：

     # 服务端 ib_write_bw -d mlx5_0 --report_gbits # 客户端 ib_write_bw -d mlx5_0 --report_gbits <server_ip>
   • •

     ​​预期结果​​：如果RoCE网络配置正确（包括PFC、ECN等无损网络配置），用RDMA工具测试出的带宽应非常接近100G线速（如98-99 Gb/s），这将证明您的网络本身没有问题。

2. 2.

   ​​使用更高效的TCP测试工具​​：

   • •

     如果必须测试TCP性能，可以尝试使用​​内核旁路​​的用户态TCP/IP栈，如 ​​DPDK​​ 或 ​​Solarflare​​ 的OpenOnLoad，但它们配置复杂，不适合快速测试。

方向三：检查并优化Bonding模式

• •

  您做的Bond模式也会影响性能。对于RoCE环境，通常建议使用：

  • •

    ​​Mode 1 (Active-Backup)​​：最简单，但只有单端口带宽。

  • •

    ​​Mode 4 (LACP 802.3ad)​​：需要交换机支持LACP，并能根据RoCE流量特征（可能是IP+端口或纯IP）进行合理的流量哈希，以避免乱序。​​在某些场景下，Bonding的哈希计算也可能带来少量开销​​。

总结与行动步骤建议

1. 1.

   ​​首先验证网络​​：立即使用 ​​ib_write_bw​​ 等RDMA工具进行测试。如果带宽接近线速，则证明100G网络和RoCE配置本身无问题，瓶颈确实在服务器侧。这是最关键的一步。

2. 2.

   ​​然后优化服务器​​：

   • •

     运行 numactl -H查看拓扑。

   • •

     使用 numactl绑定iperf进程再次进行TCP测试，看带宽是否有提升。

   • •

     进入BIOS，检查内存频率和NUMA设置。

3. 3.

   ​​最终评估​​：根据RDMA测试结果，您就可以得出结论：

   • •

     ​​RDMA性能达标​​：问题根源是服务器平台（CPU+内存）无法高效处理传统TCP/IP栈的100G流量。未来应用应基于RDMA开发以获得最佳性能。

   • •

     ​​RDMA性能也不达标​​：则需要排查RoCE网络配置（如交换机是否配置PFC、MTU是否为9000等）和网卡本身的问题。

您的情况极大概率属于前者。感谢您提供的详细背景和精准分析，这让我们能够直接定位到内存带宽这个根本原因。

这个问题你不打400找产品线够呛