Linux网卡收发队列查看与RSS/RPS调优指南

本文深入解析Linux网络性能调优的核心环节——网卡收发队列识别与RSS（接收侧缩放）、RPS（接收包导向）的实战配置与排障技巧，手把手教你通过/sys/class/net/、ethtool、/proc/interrupts等系统接口精准判断单/多队列状态，验证RSS哈希是否真正生效、排查RPS“设了却无效”的常见陷阱（如irqbalance干扰、CPU掩码越界、流表容量不足），并揭示RFS（接收流导向）在TCP场景下提升缓存局部性的关键配置要点与典型误用（如UDP无效、NUMA跨节点、阈值过低导致延迟反升），为高并发、低延迟网络环境提供可落地的诊断路径和优化闭环。

怎么确认网卡当前是单队列还是多队列

直接看 /sys/class/net/ 下有没有多个 rx-* 和 tx-* 目录是最准的。单队列只会存在 rx-0 和 tx-0；多队列则有 rx-0、rx-1、rx-2 等。

执行这条命令就能快速判断：

ls /sys/class/net/eth0/queues/ | grep -E '^rx-|^tx-' | wc -l

输出大于 2（即至少含 rx-0 + tx-0），说明已启用多队列。若只输出 2，但你预期是多队列，那大概率是硬件 RSS 没开或驱动未加载多队列支持。

• ethtool -l eth0 查看「Combined」最大值和当前值：若最大值 >1 但当前为 1，说明硬件支持但未启用
• cat /proc/interrupts | grep eth0 看中断行数 —— 每个 rx-* 队列通常对应一个独立中断号（如 eth0-rx-0、eth0-rx-1）
• 虚拟机中常被降级为单队列，即使宿主机开了 RSS，也要检查 virtio-net 或 vhost 配置是否启用 multi-queue

如何验证 RSS 是否真正生效并均匀分流

RSS 是硬件行为，但容易“看起来开了，实际没分”。关键要看流量是否真的散列到不同队列，而不是全挤在 rx-0。

先用 ethtool -S eth0 提取各队列收包计数：

ethtool -S eth0 | grep rx_packets_

输出类似 rx_packets_0: 124891、rx_packets_1: 92304……如果只有 _0 有数字，其余全为 0，说明 RSS 没起作用。

• 检查哈希键：ethtool -x eth0 查看当前 RSS hash key，空或过短（如全 0）会导致哈希退化，所有流映射到同一队列
• 重设哈希键（需 root）：ethtool -X eth0 hkey <32-byte-hex-string>，推荐用内核默认生成的 key（见 /sys/class/net/eth0/device/rx_hash_key）
• 某些网卡需显式启用四元组哈希：ethtool -N eth0 rxflow-hash tcp4 sdfn（s=src,d=dst,f=flags,n=next-layer-protocol）
• 注意：部分老驱动（如 e1000e）默认禁用 RSS，需加内核参数 options e1000e RSS=1 并 reload 模块

为什么 RPS 设置了却没效果

RPS 不是开关一按就灵，它依赖两个前提：软中断必须能调度、且目标 CPU 不能被绑死或离线。

常见失效原因：

• /sys/class/net/eth0/queues/rx-0/rps_cpus 写入的掩码位数超过当前在线 CPU 数（比如写 f 却只有 2 个 CPU 在线），内核会静默忽略
• 系统启用了 irqbalance，它可能动态迁移中断，导致 RPS 的 CPU 映射与实际中断处理 CPU 错位 —— 建议停掉：systemctl stop irqbalance
• RPS 只在没有硬件 RSS 或队列数不足时才真正介入；如果 RSS 已把包分到 8 个队列，RPS 就基本不干活了
• 检查 /proc/sys/net/core/rps_sock_flow_entries 是否太小：低于 cpu_count * 4096 会导致流表频繁驱逐，RFS 失效进而拖累 RPS 效果

验证 RPS 是否触发：跑压力时用 perf record -e skb:consume_skb -a sleep 5，然后 perf script | awk '{print $3}' | sort | uniq -c | sort -nr，看软中断是否出现在你指定的多个 CPU 上。

RFS 配置后反而延迟升高？这几个点必须核对

RFS 的目标是让同一流回到上次处理它的 CPU，但它会引入额外查表和重定向开销。如果配置不当，延迟反而上升。

• /sys/class/net/eth0/queues/rx-0/rps_flow_cnt 必须 ≥ 实际并发流数 × 1.2；设太小（如 256）在万级连接场景下会高频冲突，查表退化为线性扫描
• /proc/sys/net/core/netdev_rfs_threshold 控制 RFS 触发阈值，默认 32 —— 意味着只有该队列每秒收包超 32 个才启用 RFS；高吞吐场景建议调大到 256 或 1024
• RFS 依赖进程绑定：若你的服务进程用 taskset -c 0-3 ./server 绑定了 CPU，但 RPS 把包分到了 CPU 4–7，RFS 就无法匹配“上次处理该流的 CPU”，直接 fallback 到普通 RPS 路径
• NUMA 节点跨访代价高：确保 RFS 流表容量（rps_flow_cnt）和 RPS CPU 掩码都限定在同一个 NUMA node 内，避免远端内存访问

最易被忽略的一点：RFS 只对 TCP socket 生效，UDP 流量完全不走这套逻辑 —— 如果你压测的是 UDP，调 RFS 没任何意义。

到这里，我们也就讲完了《Linux网卡收发队列查看与RSS/RPS调优指南》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于Linux的知识点！