📚 课程目录第4章网络性能监控工具

4. 网络性能监控工具

4.1 核心原理：从“黑盒”到“白盒”的观测层次

RoCE（RDMA over Converged Ethernet）网络性能问题的定位，往往比传统 TCP/IP 网络更困难，因为其数据路径涉及 网卡硬件、驱动、协议栈、交换机缓存和远端节点 多个层面。仅靠“业务变慢”或“丢包计数”这类黑盒指标，很难判断瓶颈究竟在 PCIe 带宽、网卡队列、拥塞窗口还是链路误码。因此，需要分层采集数据，将网络行为逐步“白盒化”。

本节介绍的四个工具分别覆盖不同观测层次：

perf：基于内核性能事件，观测 CPU 与网卡中断、软中断（SoftIRQ）、内存带宽等系统级资源消耗，用于判断是否因 CPU 处理不过来导致 RoCE 报文延迟。
ethtool：直接读取网卡寄存器、统计计数器和链路状态，是获取物理层与 MAC 层丢包、CRC 错误、缓冲区溢出等硬指标的最快途径。
tcpdump：在内核协议栈旁路抓取数据包，虽然 RoCE 的 RC（可靠连接）流量通常不经过传统 TCP/IP 栈，但可用于抓取 CNP（拥塞通知报文）、RoCEv2 的 UDP 封装包以及 DCQCN 相关控制报文。
Wireshark：作为 tcpdump 的图形化增强，提供 RoCE 协议解析、InfiniBand 头部解码和流分析能力，适合离线深度分析。

关键认知：RoCEv2 报文外层是 UDP（目的端口 4791），但内层是 IB（InfiniBand）头部。因此 tcpdump 抓到的“UDP 包”需要 Wireshark 或特定解码器才能看到完整的 RC 操作码、PSN（包序列号）和重传信息。

4.2 方法流程：四步采集法定位热点

推荐按“先链路、再网卡、后协议、终分析”的顺序执行，避免盲目抓包导致数据量过大。

Step 1：链路健康检查（ethtool -S）
登录两端节点，分别执行 ethtool -S eth0 查看网卡统计。重点关注 rx_crc_errors、rx_length_errors、tx_dropped、rx_errors 等计数器。若 CRC 错误持续增长，说明物理链路存在信号质量问题，应先排查光模块、线缆或交换机端口。
Step 2：CPU 与中断分布（perf top / perf record）
执行 perf top -C 0-7 观察 CPU 软中断占比。RoCE 流量会触发网卡中断和 SoftIRQ，若某个 CPU 核的 softirq 占比超过 30%，则可能存在中断不均或 RPS（Receive Packet Steering）配置不当。
Step 3：定向抓包（tcpdump 过滤 RoCE 端口）
使用 tcpdump -i eth0 -s 96 -w roce.pcap 'udp port 4791' 仅抓取 RoCEv2 数据面报文。若需同时抓取 CNP 控制报文，则增加过滤条件 or 'udp port 4791' or 'icmp'（CNP 通常使用 UDP 目的端口 4791 的特定队列）。
Step 4：Wireshark 协议分析
将 pcap 文件导入 Wireshark，启用 RoCE 解析器（Analyze → Reload as RoCE）。查看 BTH 中的 OpCode（如 SEND、WRITE、READ）、PSN 序列号是否连续，以及是否存在 NAK（否定应答）或重传。

工具	采集对象	典型命令	关键输出指标
ethtool	网卡硬件统计	`ethtool -S eth0`	rx_crc_errors, tx_dropped, rx_alloc_fail
perf	CPU/中断/内存	`perf top -C 0-7`	softirq 占比, cache-misses, cycles
tcpdump	RoCEv2 报文	`tcpdump -i eth0 -s 96 -w roce.pcap 'udp port 4791'`	报文速率, 重传包, CNP 频率
Wireshark	协议解析	导入 pcap 后解码	OpCode, PSN 序列, NAK 类型

4.3 案例：一次“间歇性丢包”的定位过程

某分布式存储集群使用 RoCEv2 组网，业务反馈“写入延迟偶尔飙升到 200ms”。初步检查交换机端口无告警，但存储节点上 ibstat 显示丢包计数不为零。我们按四步法排查：

第一步：ethtool 发现物理层异常

# 在存储节点执行
ethtool -S enp175s0f0 | grep -E "crc|error|drop"
rx_crc_errors: 1287
rx_length_errors: 0
tx_dropped: 0
rx_errors: 1290

rx_crc_errors 持续增长，说明存在物理层误码。但更换光模块后问题依旧，于是怀疑是交换机端口协商问题。

第二步：perf 排除 CPU 瓶颈

perf top -C 4-7 --sort comm,softirq
# 观察到 softirq 占比仅 8%，排除 CPU 过载

第三步：tcpdump 抓取重传特征

tcpdump -i enp175s0f0 -s 96 -w /tmp/roce_delay.pcap 'udp port 4791' -c 50000
# 抓取完成后用 tcpdump 统计重传包数量
tcpdump -r /tmp/roce_delay.pcap 'tcp[13] & 8 != 0' | wc -l

第四步：Wireshark 定位 PSN 空洞
导入 pcap 后，在 Wireshark 中启用 RoCE 解析，发现 BTH 的 PSN 序列在 0x3a2f 到 0x3a30 之间出现跳变，且伴随一个 NAK（类型为“序列错误”）。这说明接收端确实丢了一个报文，但物理层 CRC 错误与 PSN 空洞在时间上并不完全吻合——CRC 错误发生在交换机上行口，而 PSN 空洞发生在存储节点接收口。

  结论：最终定位为交换机某端口因缓存不足触发了隐式 PFC（优先级流控）暂停帧，导致 RoCE 报文被交换机丢弃。虽然物理层 CRC 错误是诱因，但真正丢包发生在交换机内部队列。修复措施是调整交换机端口 buffer-size 并启用 ECN 标记。

4.4 常见误区与复盘

误区一：只抓数据面，忽略控制面。
RoCE 的拥塞控制依赖 CNP 报文和 PFC 暂停帧。如果只过滤 udp port 4791，会漏掉 CNP（通常使用同一端口但不同队列）和 PFC（以太网控制帧，目的 MAC 01:80:C2:00:00:01）。建议同时抓取 ether proto 0x8808（PFC 帧）和 udp port 4791。

误区二：perf 只看 CPU 使用率，忽略 cache-misses。
RoCE 网卡通过 DMA 将数据直接写入内存，CPU 主要处理控制面。若 cache-misses 比例超过 5%，说明内存访问局部性差，可能因 NUMA 架构下网卡与 CPU 跨节点访问导致。应使用 perf stat -e cache-misses,cache-references 检查。

复盘要点：工具组合比单一工具更有效。ethtool 告诉你“链路有没有错”，perf 告诉你“CPU 忙不忙”，tcpdump 告诉你“报文有没有丢”，Wireshark 告诉你“协议层怎么丢”。四者结合才能区分物理层误码、交换机丢包、网卡队列溢出和协议重传这四类不同原因。

推荐采集基线：在业务低峰期运行 10 分钟，记录以下指标作为健康基线：

rx_crc_errors 增长速率（应 < 1/分钟）
softirq 占比（应 < 15%）
CNP 报文速率（应 < 100 pps）
重传率（应 < 0.01%）

当业务异常时，对比基线即可快速判断是突发流量导致，还是硬件劣化导致。建议将上述命令封装为脚本，配合 cron 定期执行，并将输出保存到日志文件，为后续的根因分析保留原始证据。