【微知】Mellanox网卡资源监控全解析：如何高效统计qp、mr、pd与cq数量？

1. 为什么你需要关注Mellanox网卡的资源使用情况？

如果你正在使用或者管理基于Mellanox网卡（现在应该叫NVIDIA ConnectX系列了）的服务器，特别是那些跑着高性能计算、AI训练、分布式存储或者数据库的机器，那你肯定对“性能”和“稳定”这两个词特别敏感。我见过太多这样的场景了：业务跑得好好的，突然延迟飙升，吞吐量断崖式下跌，查了半天应用日志和系统负载都正常，最后问题却出在了网卡这一层——资源用爆了。

这里的资源，指的不是CPU或者内存，而是RDMA（远程直接内存访问）特有的几种核心数据结构：QP（队列对）、MR（内存区域）、PD（保护域）和CQ（完成队列）。你可以把它们想象成高速公路系统：

• QP就是一条条车道，数据包在这些车道上飞驰。车道总数是有限的。
• MR像是道路两旁允许装卸货物的合法仓库区域。你的数据必须放在这些“注册”过的内存区域里，网卡才能直接访问。
• PD好比是不同物流公司的运营许可。MR必须挂在某个PD下，它起到了安全隔离的作用。
• CQ则是每个路口的事后报告亭，用来通知司机“货已送到”或“路上出事”。每个QP都需要关联CQ来接收完成通知。

当你的应用疯狂创建连接（QP）、注册大量内存（MR）时，这些硬件资源就会被快速消耗。一旦达到网卡芯片的硬件上限，新的连接就无法建立，内存注册会失败，整个RDMA通信就会卡住。更头疼的是，这些资源的使用情况，在常规的ifconfig或者ethtool里是根本看不到的，它们属于RDMA的“另一个世界”。

所以，学会查看和监控这些资源，不是“锦上添花”，而是“雪中送炭”的运维基本功。它能帮你：

1. 提前预警：在资源耗尽导致业务故障前，发现使用率过高的趋势。
2. 快速排障：当出现连接失败、内存注册错误时，第一时间定位是否是网卡资源瓶颈。
3. 性能调优：分析资源分配模式，优化应用配置，比如调整QP和CQ的比例，避免资源浪费。

接下来，我就带你深入这个“另一个世界”，用最直接的工具——rdma命令，把网卡的老底摸个清清楚楚。

2. 你的武器库：认识 rdma 命令家族

在动手查资源之前，我们得先熟悉一下工具。rdma这个命令，是Linux内核RDMA子系统提供给用户空间的主要管理工具，功能非常强大。它不像ip或ethtool那样广为人知，但却是管理InfiniBand和RoCE设备的瑞士军刀。

首先，确认一下你的系统里有没有这个命令。它通常包含在iproute这个包里面。你可以用rpm -qf来查一下（以RHEL/CentOS为例）：

which rdma rpm -qf $(which rdma)

输出可能会显示类似iproute-5.15.0-4.el8.x86_64这样的包名。如果没找到命令，安装iproute包即可。

rdma命令采用“对象-操作”的模式，结构很清晰。直接输入rdma help就能看到它的全貌：

rdma help

输出会列出所有可管理的OBJECT（对象）：

Usage: rdma [ OPTIONS ] OBJECT { COMMAND | help } where OBJECT := { dev | link | resource | system | statistic | help }

对我们监控资源来说，最重要的就是resource这个对象。其他几个也简单了解一下：

• dev：查看和设置RDMA设备本身的信息，比如设备名、所属网络命名空间等。
• link：管理RDMA链接，可以创建和删除基于物理网卡的SR-IOV虚拟函数（VF）的RDMA链接。
• system：查看和设置RDMA子系统级别的参数，比如网络命名空间的共享模式。
• statistic：这个非常有用，用于查询和绑定QP的计数器，做性能监控和数据分析时会用到。

每个OBJECT下面都有更具体的命令。想知道某个对象能干什么，就用rdma [OBJECT] help。比如，我们最关心的资源查看：

rdma resource help

这个命令输出的帮助信息，就是我们今天所有操作的核心指南，一定要仔细看。它列出了所有能查询的资源类型（qp, cm_id, pd, mr, cq, ctx, srq）以及查询的语法格式。原始文章里贴了一大段帮助信息，我们这里不照搬，而是理解它的结构：基本格式是rdma resource show [资源类型] [过滤条件]。

工具介绍完了，热身结束，下面我们进入实战环节，一个个资源揪出来看。

3. 实战：如何查看各类资源的总体数量？

最基础的查询，就是看看整张网卡上，各种资源总共用了多少。这里假设你的RDMA设备叫mlx5_0（这是最常见的一种Mellanox驱动设备名）。

3.1 一键总览：rdma res show

最简单粗暴的命令，就是：

rdma res show

或者用缩写：

rdma res show

这个命令会列出当前系统所有RDMA设备上所有类型资源的使用摘要。输出大概是这样的：

dev mlx5_0 qp 1024/1048576 pd 256/262144 mr 512/524288 cq 512/524288 dev mlx5_1 qp 512/1048576 pd 128/262144 mr 256/524288 cq 256/524288

这个输出非常直观，我们拆解一下dev mlx5_0 qp 1024/1048576：

• dev mlx5_0：设备名称。
• qp：资源类型。
• 1024：当前已使用的QP数量。
• 1048576：该设备支持的最大QP数量（硬件上限）。

一眼就能看出重点：使用量 / 硬件上限。如果1024这个数字快接近1048576了，那就亮红灯了。这个命令适合快速巡检，一眼扫过去所有设备的健康度。

3.2 分项细查：精准统计 qp, mr, pd, cq

有时候我们只想关注某一种资源，或者需要更详细的信息。这就需要用到针对特定资源类型的查询命令。

查看队列对（QP）数量：

rdma resource show qp

这个命令会列出所有设备上所有QP的详细信息，包括每个QP的编号、状态、上下文等，输出会非常长。如果你只关心mlx5_0设备上的QP总数和上限，更高效的方法是结合dev过滤器：

rdma resource show qp dev mlx5_0

但注意，这依然会列出每个QP的详情。如果仅仅为了看“总数”，之前rdma res show的摘要信息更高效。show qp的真正威力在于排查具体QP的状态，比如找出哪些QP处于ERROR状态。

查看保护域（PD）数量：

rdma resource show pd dev mlx5_0

这条命令会显示指定设备上所有PD的信息。PD的数量通常比QP少，因为一个PD可以被多个QP共享。监控PD的使用情况，对于多租户或安全隔离场景很重要。

查看内存区域（MR）数量：

rdma resource show mr dev mlx5_0

MR的数量往往是最容易爆掉的资源之一，特别是那些需要注册大量内存的应用（比如大规模稀疏模型训练）。这个命令会列出每个MR的起始地址、长度、关联的PD等信息。输出同样可能很长。

查看完成队列（CQ）数量：

rdma resource show cq dev mlx5_0

CQ负责异步通知。每个QP至少关联一个发送CQ和一个接收CQ（可以相同）。监控CQ数量有助于理解应用的完成事件处理模型。

一个实用技巧：直接运行这些show命令，输出可能刷屏。你可以用wc -l来快速统计行数，从而估算资源实例的数量（注意，标题行也算一行）：

rdma resource show qp dev mlx5_0 | wc -l

将输出行数减1，大致就是当前QP的数量。当然，最准确的还是看摘要信息里的那个使用量数字。

4. 进阶技巧：过滤与定位，让问题无处可藏

只会看总数，相当于只知道“仓库满了”，但不知道是哪个货架堆满了、是谁堆的。真正的运维高手，需要能定位到具体的“货架”甚至“订单”。这就需要用到rdma resource show强大的过滤功能。

帮助信息里已经给出了过滤的语法模板：

resource show qp link [DEV/PORT] [FILTER-NAME FILTER-VALUE]

常见的过滤器（FILTER-NAME）包括：

• pid：进程ID。这是最常用、最给力的过滤器！可以直接看到是哪个进程创建了这些资源。
• lqpn：本地QP编号。
• rqpn：远程QP编号。
• state：QP的状态（如INIT,RTR,RTS,ERROR等）。

4.1 按进程PID过滤：谁是大户？

当发现某类资源使用量异常高时，第一反应就是找出“罪魁祸首”。假设我们怀疑是某个PID为12345的进程创建了大量QP，可以这样查：

rdma resource show qp dev mlx5_0 pid 12345

这条命令会只显示由进程12345创建的所有QP。如果输出很多，那基本就实锤了。同样，你可以用这个命令查该进程创建的MR、CQ等：

rdma resource show mr dev mlx5_0 pid 12345 rdma resource show cq dev mlx5_0 pid 12345

实战案例：有一次我们遇到一台机器MR数量接近上限，应用报错。直接用rdma res show看到mr使用量很高，但哪个进程导致的？我们用了最“笨”但有效的方法：用ps列出所有可能使用RDMA的进程PID，然后写了个简单循环去挨个查：

for pid in $(pgrep -f “my_app_pattern\|nv_peer_mem”); do echo “PID $pid:”; rdma resource show mr dev mlx5_0 pid $pid 2>/dev/null | head -5; done

很快就锁定了某个内存数据库进程注册了海量的小内存块，导致了MR耗尽。解决方案是让应用修改内存注册策略，改用更大的内存块或池化技术。

4.2 按资源状态过滤：揪出异常资源

资源泄漏是另一个常见问题。比如QP创建后，因为程序bug没有正常销毁，留在了ERROR状态。这些“僵尸”资源会一直占用配额。我们可以用状态过滤器把它们找出来：

rdma resource show qp dev mlx5_0 state ERROR

清理这些残留资源通常需要重启对应的应用，或者在某些情况下，可以尝试通过驱动卸载/重新加载来强制清理（生产环境慎用）。

4.3 组合使用，精准打击

过滤条件可以组合吗？很遗憾，从当前rdma命令的帮助信息看，它似乎不支持在同一命令中指定多个[FILTER-NAME FILTER-VALUE]对。但是，我们可以通过管道传递给其他文本处理工具，比如grep和awk，来实现复杂查询。

例如，我想找出mlx5_0上所有状态为RTS（准备发送）且由PID12345创建的QP。可以先按PID过滤，再用grep筛选状态：

rdma resource show qp dev mlx5_0 pid 12345 | grep -E “lqpn.*state.*RTS”

虽然不如原生支持那么方便，但结合Shell脚本，已经能完成绝大部分的排查工作。

5. 监控与告警：让资源可视化

手动敲命令查看，只适合临时排查。对于一个稳定的生产集群，我们需要建立持续的监控和告警机制。这里分享几个思路。

思路一：通过脚本定期采集，集成到现有监控系统写一个简单的Shell或Python脚本，定期执行rdma res show，解析出每个设备上每种资源的使用量和上限，然后计算出使用率。输出格式可以做成key: value形式，方便被Prometheus Node Exporter的textfile collector抓取，或者直接推送到Zabbix、Open-Falcon等监控系统。

一个简单的脚本示例：

#!/bin/bash # 文件名：collect_rdma_resources.sh DEVICE=”mlx5_0” METRICS_DIR=”/var/lib/node_exporter/textfile_collector” OUTPUT_FILE=”${METRICS_DIR}/rdma_metrics.prom” # 执行命令并解析输出 # 假设输出是：dev mlx5_0 qp 150/1000000 pd 50/200000 mr 3000/500000 cq 100/200000 stats=$(rdma res show | grep “dev ${DEVICE}”) if [ -n “$stats” ]; then qp_used=$(echo $stats | awk ‘{print $3}’ | cut -d’/’ -f1) qp_max=$(echo $stats | awk ‘{print $3}’ | cut -d’/’ -f2) pd_used=$(echo $stats | awk ‘{print $5}’ | cut -d’/’ -f1) pd_max=$(echo $stats | awk ‘{print $5}’ | cut -d’/’ -f2) # 同理解析 mr, cq… # 生成Prometheus格式的指标 cat > ${OUTPUT_FILE} << EOF # HELP rdma_qp_used Current number of used Queue Pairs # TYPE rdma_qp_used gauge rdma_qp_used{device=”${DEVICE}”} ${qp_used} # HELP rdma_qp_max Maximum number of Queue Pairs # TYPE rdma_qp_max gauge rdma_qp_max{device=”${DEVICE}”} ${qp_max} # HELP rdma_qp_usage_ratio Usage ratio of Queue Pairs # TYPE rdma_qp_usage_ratio gauge rdma_qp_usage_ratio{device=”${DEVICE}”} $(echo “scale=4; ${qp_used} / ${qp_max}” | bc) EOF fi

然后通过crontab每分钟运行一次这个脚本。这样，在Grafana里就能画出资源使用率的曲线图，并设置当使用率超过80%时触发告警。

思路二：利用 rdma statistic 进行性能监控rdma statistic对象提供了更底层的性能计数器查询。例如，你可以监控特定QP的收发包数量、错误计数等。这对于深度性能分析和瓶颈定位至关重要。例如，查看设备上所有QP的统计信息：

rdma statistic qp show

你可以将这些统计信息也纳入监控，观察流量模式是否异常。

思路三：与应用程序日志关联当监控告警触发，提示某资源使用率过高时，运维人员需要快速行动。这时，如果你能同时提供一份“资源大户”排行榜（通过pid过滤定期扫描），就能立刻知道应该去检查哪个应用、哪个服务。把RDMA资源监控和应用的业务日志、系统监控大盘关联起来，能极大提升故障定位效率。

6. 常见问题与避坑指南

在实际使用中，我踩过不少坑，这里总结几个典型问题和注意事项：

1. 命令输出为空或“No such device”？首先确认RDMA驱动是否加载（lsmod | grep mlx），以及设备是否存在（rdma dev show）。如果使用RoCE模式，确保对应的以太网接口（比如ens1f0）的rdma_cm模块已加载，并且IP地址配置正确。有时候在容器或网络命名空间内执行命令，需要指定-n参数或进入正确的命名空间。

2. 资源使用量突然飙升，但应用看着正常？这可能是因为应用使用了连接池或资源池，在启动时预分配了大量资源。这是正常的设计。关键是要建立基线。在应用平稳运行期记录下正常的资源使用水平，后续的监控才更有意义。突增如果发生在业务低峰期，才值得警惕。

3. 硬件上限是多少？在哪里查？rdma res show输出的第二个数字就是硬件上限。这个上限由网卡芯片型号和驱动配置共同决定。你也可以通过更底层的工具查询，比如使用Mellanox的mlxconfig工具（需安装Mellanox Firmware Tools，即MFT包）：

mlxconfig -d /dev/mst/mt4125_pciconf0 q | grep MAX

但请注意，通过mlxconfig调整这些上限参数是高风险操作，通常不建议修改，除非你非常清楚自己在做什么，并且有充分的理由（比如芯片支持，但驱动默认值较低）。

4. 资源泄漏如何彻底清理？如果是用户态进程泄漏，最干净的办法是重启该进程。如果是内核模块或驱动异常导致资源未被释放，可能需要尝试卸载并重新加载mlx5_core、ib_core等内核模块（会中断所有RDMA业务，务必在维护窗口操作）：

modprobe -r mlx5_ib mlx5_core modprobe mlx5_core modprobe mlx5_ib

再次强调，生产环境操作前务必评估影响！

5. 虚拟化环境（SR-IOV）下的资源监控在SR-IOV场景下，物理功能（PF）和虚拟功能（VF）的资源是分开统计的。你需要分别查询PF设备（如mlx5_0）和各个VF设备（如mlx5_1）。VF的资源上限通常由PF在创建VF时分配。监控时需要注意，VF的资源耗尽同样会影响运行在其上的虚拟机或容器。

掌握rdma resource show及其过滤技巧，就像是拿到了Mellanox网卡资源世界的管理员钥匙。从日常的健康巡检，到突发的性能瓶颈排查，再到长期的容量规划，这套方法都能提供坚实的数据支撑。记住，监控的核心不是为了看数字，而是为了建立趋势、发现异常、快速定位。希望这些从实战中总结出来的经验，能让你下次再遇到RDMA相关问题时，心里更有底，手上更有招。