3. 性能测试核心指标
RDMA（Remote Direct Memory Access）性能评估的复杂性在于：单一指标无法反映真实网络能力，而多个指标之间又存在强耦合关系。例如，提升带宽利用率往往伴随CPU中断开销上升，降低延迟又可能牺牲报文速率。本章将系统定义六大核心指标——带宽、延迟、吞吐量、IOPS、CPU占用率、报文速率，并给出各自的测量原理、工具选型与数据解读方法。理解这些指标的物理含义与测量边界，是构建基准评估体系的前提。
3.1 带宽（Bandwidth）与吞吐量（Throughput）
核心原理
带宽指物理链路或协议层能够承载的最大数据传输速率，RDMA场景下通常以 Gbps（线速）或 MB/s（有效载荷）表示。吞吐量则强调实际有效数据的传输速率，扣除协议头、重传、流控等开销。两者差异反映了协议效率。例如，100Gbps 的 InfiniBand NDR 链路，理论带宽 12.5GB/s，但实际有效吞吐量受报文大小、QP（Queue Pair）数量、MTU 设置影响，通常只能达到 85%~95%。
测量方法
- 工具选择：perftest 套件中的
ib_write_bw、ib_read_bw、ib_send_bw，支持 TCP/IP 与 RoCE 模式。 - 关键参数：
-s报文大小（1B~1MB）、-qQP 数量、-d运行时长、-x绑定网卡。 - 操作流程：服务端启动
ib_write_bw -s 65536 -q 4 -d 30，客户端连接后自动开始测试，输出带宽、消息速率、平均延迟。
# 服务端
ib_write_bw -s 65536 -q 4 -d 30 -x 3
# 客户端
ib_write_bw -s 65536 -q 4 -d 30 -x 3 192.168.1.10案例拆解：100Gbps RoCEv2 带宽调优
某分布式存储集群使用 Mellanox ConnectX-6 网卡，实测带宽仅 78Gbps，远低于预期。通过 ib_write_bw -s 1048576 -q 8 测试，发现单 QP 带宽 62Gbps，多 QP 提升有限。进一步检查发现：MTU 设置为 1500（默认），而 RoCEv2 推荐 4096；同时 PFC 优先级未正确配置导致丢包重传。调整 MTU 至 4096、开启 PFC 后，带宽提升至 94Gbps。此案例说明带宽测量需同时关注链路层配置与协议栈参数。
3.2 延迟（Latency）
核心原理
延迟是 RDMA 最核心的优势指标，指从发送端发起操作到接收端完成操作的时间差。分为单向延迟（One-way Latency）和往返延迟（Round-trip Time, RTT）。RDMA 延迟通常以微秒（us）计，包含软件开销（驱动、协议栈）、硬件处理（网卡 DMA、SerDes）、链路传播（光纤/铜缆）三部分。测量延迟时需区分 空载延迟（无并发流量）与 负载延迟（有背景流量），后者更接近生产环境。
测量方法
- 使用
ib_send_lat或ib_read_lat，报文大小固定为 2B~64B（小包延迟更有意义）。 - 关闭中断合并（
mlxconfig -d /dev/mst/mt4123_pciconf0 set INT_MODERATION=0），否则延迟虚高。 - 记录 P50、P99、P999 分位值，而非仅平均值——长尾延迟对存储场景影响更大。
| 报文大小 | 平均延迟(us) | P99延迟(us) | 说明 |
|---|---|---|---|
| 2B | 1.2 | 2.8 | 纯软件开销 |
| 64B | 1.4 | 3.1 | 典型控制消息 |
| 4KB | 2.1 | 4.5 | 数据块传输 |
实战场景：存储集群延迟敏感型业务
某 AI 训练集群使用 NVMe-oF over RDMA，要求端到端延迟 < 20us。实测发现 P99 延迟达到 45us，排查发现交换机 QoS 队列配置错误，将 RDMA 流量映射到低优先级队列。调整 DSCP 映射后，P99 降至 18us。此案例强调延迟测量必须结合网络 QoS 配置验证。
ibstat 中链路速率是否为预期值（如 100Gb/s）。若显示降速，延迟数据无效。
3.3 IOPS 与报文速率（PPS）
核心原理
IOPS（Input/Output Operations Per Second）衡量每秒完成的 I/O 操作数，主要面向块存储场景（如 NVMe-oF）。报文速率（Packets Per Second, PPS）衡量每秒处理的报文数量，反映网卡的小包处理能力。两者均受限于网卡硬件处理能力、CPU 中断频率、内存带宽。RDMA 网卡通常内置硬件卸载引擎，IOPS 可达数百万，PPS 可达数十 Mpps。
测量方法
- IOPS 测试：使用 fio 的 RDMA engine，命令示例：
fio --name=test --ioengine=rdma --rw=randrw --bs=4k --size=1G --iodepth=32 --numjobs=4。需关注队列深度（iodepth）对 IOPS 的影响，通常 32~64 达到峰值。 - PPS 测试：使用
ib_pps工具或硬件计数器（ethtool -S eth0 | grep pps）。小包（64B）测试最能体现极限 PPS，但需注意丢包率。
# fio RDMA 随机读写测试
fio --name=randread --ioengine=rdma --rw=randread --bs=4k --size=10G --iodepth=64 --numjobs=8 --time_based --runtime=60案例拆解：数据库日志盘 IOPS 瓶颈
某 Oracle 数据库使用 RDMA 存储，日志写入 IOPS 要求 50 万。实测仅 32 万，通过 perf top 发现 CPU 软中断占比 45%。优化方案：将网卡中断绑定到独立 CPU 核，并启用 mlx5_core 的 dim（动态中断调节）功能。调整后 IOPS 提升至 55 万，CPU 占用率下降 20%。此案例说明 IOPS 与 CPU 占用率强相关，需联合调优。
3.4 CPU 占用率
核心原理
CPU 占用率反映 RDMA 操作对主机计算资源的消耗。RDMA 的核心优势是卸载 CPU，但实际仍存在驱动处理、中断响应、内存注册等开销。测量需区分：用户态 CPU（应用逻辑）、内核态 CPU（驱动与协议栈）、软中断 CPU（网络处理）。理想情况下，RDMA 的 CPU 占用率应低于传统 TCP/IP 的 1/3。
测量方法
- 使用
mpstat -P ALL 1实时监控各核使用率，重点关注软中断（%soft）与内核态（%sys）。 - 使用
perf stat -e task-clock,context-switches,cpu-migrations统计上下文切换与迁移次数。 - 对比测试：分别运行 TCP 与 RDMA 相同负载，记录 CPU 占用率差值。
| 协议 | 带宽(Gbps) | CPU占用率(%) | 每Gbps CPU成本 |
|---|---|---|---|
| TCP/IP | 40 | 65 | 1.63% |
| RoCEv2 | 94 | 18 | 0.19% |
| InfiniBand | 96 | 12 | 0.13% |
实战场景：多租户云环境 CPU 隔离
某云服务商在裸金属服务器上同时运行多个 RDMA 租户，发现某租户的 CPU 占用率异常高。通过 mpstat 定位到软中断集中在 CPU0，导致其他租户性能受损。解决方案：使用 mlx5_ib 的 set_irq_affinity 脚本将中断分散到多个核，并设置 cgroup CPU 配额。调整后各租户 CPU 占用率均衡，整体吞吐量提升 15%。
vmstat 的 r 列（运行队列）与 pidstat 的线程级数据。
3.5 指标关联分析与综合评估
核心原理
六大指标并非孤立存在，而是存在内在关联：带宽与吞吐量受报文大小影响，延迟与 IOPS 受队列深度影响，CPU 占用率与 PPS 受中断频率影响。综合评估需建立指标矩阵，在不同负载模型下同步采集所有指标，形成基准基线。
评估流程
- 步骤1：确定测试场景（存储、网络、混合），选择报文大小矩阵（64B、256B、4KB、64KB、1MB）。
- 步骤2：固定队列深度（如 16），扫描报文大小，记录带宽、延迟、PPS。
- 步骤3：固定报文大小（如 4KB），扫描队列深度（1、8、32、64、128），记录 IOPS 与延迟。
- 步骤4：同步采集 CPU 占用率，计算每 Gbps 带宽的 CPU 成本。
案例拆解：存储网关全指标基准
某存储网关产品需通过 400Gbps RDMA 性能验收。测试团队采用上述流程，发现 64KB 报文下带宽 380Gbps，但 IOPS 仅 12 万（目标 20 万）。进一步分析发现，IOPS 瓶颈在内存注册（Memory Registration）开销。优化方案：使用 ibv_reg_mr 的 IBV_ACCESS_ON_DEMAND 按需注册，减少页表锁定。优化后 IOPS 提升至 22 万，带宽保持 375Gbps。此案例展示了多指标联合调优的价值。