📚 课程目录第3章性能监控工具

3、性能监控工具：使用 ibstat、ibstatus、perfquery 等工具监控网络状态

核心原理：从“链路通断”到“性能画像”的监控分层

InfiniBand 网络的性能监控不能停留在“ping 得通”的层面。IB 网络的核心优势在于 RDMA 与高吞吐低时延，因此监控必须覆盖物理层、链路层、端口层与流量层。常用的监控工具分别从不同视角提供数据：ibstat 读取内核驱动的端口状态与链路参数，ibstatus 汇总本地所有 IB 设备的运行状态，perfquery 则直接访问硬件性能计数器（Performance Counter），获取累计发送/接收字节、错误包计数、链路恢复次数等细粒度指标。理解这些工具的输出差异，是定位性能瓶颈的第一步。

监控分层要点：物理层关注信号完整性（如链路降速），链路层关注重传与 CRC 错误，端口层关注缓存溢出与流控，网络层关注拥塞与路由均衡。不同工具对应不同层次，切勿混用。

方法流程：三工具协同的监控操作路径

在实际运维中，三个工具需要配合使用，形成“状态确认 → 计数器采集 → 趋势分析”的闭环流程。以下为推荐的执行顺序与关键命令：

快速健康检查：使用 ibstatus 查看所有本地端口的链路状态，确认是否全部处于 Active，速率为预期的 EDR（100Gb/s）或 HDR（200Gb/s）。
端口级细节确认：使用 ibstat 检查单个端口的物理状态、链路层、端口 GUID 以及 LinkDownedCounter 等累计值。
性能计数器采集：使用 perfquery 读取端口的收发字节数、错误包计数、缓存溢出计数等硬件计数器。
持续监控与阈值告警：将上述命令封装为脚本，定时采集并比对历史数据，当错误计数增量超过阈值时触发告警。

# 1. 查看所有 IB 设备汇总状态
ibstatus

# 2. 查看指定端口的详细状态
ibstat mlx5_0

# 3. 查询端口性能计数器（默认读取端口 1）
perfquery -p 1 mlx5_0

# 4. 持续监控（每 2 秒刷新，类似 top 风格）
perfquery -p 1 -c 5 mlx5_0

工具	核心输出字段	典型瓶颈指示
`ibstatus`	State、PhysicalState、Rate、LinkLayer	State 非 Active、速率低于预期
`ibstat`	PortGUID、LinkDownedCounter、Firmware版本	LinkDownedCounter 持续增长
`perfquery`	XmitDataBytes、RcvDataBytes、RcvErrors、SymbolErrorCounter	RcvErrors 非零、SymbolError 激增

案例场景：perfquery 定位“间歇性丢包”瓶颈

某超算集群运行分布式训练任务，用户反馈跨节点通信时吞吐量从 180Gb/s 骤降至 40Gb/s，且呈周期性波动。初步使用 ibstatus 检查所有端口均为 Active，速率显示为 EDR，未发现链路降速。随后使用 perfquery 对交换机上行端口进行连续采样：

# 每 5 秒采样一次，共 10 次
for i in $(seq 1 10); do
  perfquery -p 36 -c 1 switch_guid | grep -E "RcvErrors|SymbolError|LinkDowned"
  sleep 5
done

输出显示 RcvErrors 从 0 增长到 1,024，再增长到 2,560，而 SymbolErrorCounter 同步增长。进一步检查物理连接，发现交换机端口 36 连接的光模块接收光功率为 -14.2dBm，接近 -15dBm 的告警阈值。更换光模块后，错误计数停止增长，吞吐恢复至 178Gb/s。此案例说明：链路状态正常不代表物理信号健康，必须结合 perfquery 的错误计数器才能发现隐性劣化。

关键误区：不要只依赖 ibstatus 的 Active 状态判断链路健康。IB 链路在信号劣化时不会立即降速或断开，而是先出现可恢复的前向纠错（FEC）与重传，此时吞吐已受损但状态仍显示 Active。务必定期采集 perfquery 的 SymbolErrorCounter 与 RcvErrors。

误区与复盘：监控工具使用的常见陷阱

误区一：混淆端口号与设备名。perfquery 的 -p 参数指定的是物理端口号（从 1 开始），而 ibstat 输出中的端口号可能从 0 开始。例如 ibstat mlx5_0 显示 Port 1，但 perfquery 中对应 -p 1，而某些固件版本中 Port 2 对应 -p 2，需仔细核对。
误区二：忽略计数器溢出。perfquery 的计数器为 64 位，但在高速流量下（200Gb/s），32 位计数器可能在数分钟内回绕。若使用旧版工具或脚本读取 32 位值，会得到错误数据。建议使用 -x 参数读取 64 位扩展计数器。
误区三：只看瞬时值不看增量。单次 perfquery 输出的是累计值，无法反映当前速率。必须两次采样后计算差值，再除以时间间隔，才能得到实时吞吐与错误率。
误区四：忽略交换机侧监控。多数排查只关注 HCA 端口，但拥塞往往发生在交换机内部。使用 perfquery 时需指定交换机的 GUID，并监控其所有下行端口，才能发现流量不均或缓存溢出。

  复盘建议：建立“每日基线”机制。每天固定时间运行一次 ibstatus 与 perfquery，将关键计数器的绝对值存入日志。当性能问题发生时，对比基线数据即可快速判断是突发错误还是长期劣化。例如，若 SymbolErrorCounter 每日增长不超过 100，而故障当天增长 10,000，则说明物理层出现急性问题。

通过上述工具的组合使用，管理员可以从“链路通断”的粗粒度监控，升级为“信号质量 + 错误计数 + 流量分布”的精细化性能画像。这不仅是故障定位的手段，更是预防性维护的基础——当错误计数呈现持续增长趋势时，即使当前吞吐未下降，也应提前更换光模块或线缆，避免业务中断。