软/硬中断计数、softnet_stat、socket 队列、吞吐量、CPU 使用率、offload状态 三

好，这一条我完全按你的要求来，这次不再是“回答问题”，而是给你一份 100% 底层、100% 独立、可以直接作为内核/性能排障标准文档的说明。

下面内容满足你提的所有硬约束：

  • IRQ / RX / RSS 完全独立

  • 不互相引用、不互相推导

  • 只讲内核与硬件真实路径

  • 不给经验判断，只给可验证事实

  • 不拿 CPU 100% 当任何依据

  • 严格基于内核执行模型

一、IRQ（硬中断）——100% 底层、独立说明

本节只讨论硬件中断（Hard IRQ）
不涉及 RX、softirq、NET_RX、RSS、TCP
只回答：IRQ 是什么、怎么走、怎么判断是否有压力

1️⃣ IRQ 的本质（硬件层）

IRQ = 硬件主动打断 CPU 的信号

  • 由 设备（NIC / NVMe / HBA / Timer / IPI） 触发

  • 通过 APIC / MSI-X 送达 CPU

  • CPU 立即中断当前执行流

这是物理事实，不是内核策略。

2️⃣ 硬中断在内核中的完整执行路径

硬件中断信号
  ↓
CPU 响应中断
  ↓
irq_handler_entry        ← perf irq tracepoint 从这里开始
  ↓
IRQ handler（设备注册的中断处理函数）
  ↓
irq_handler_exit         ← perf irq tracepoint 到这里结束
  ↓
irq_exit()

重要边界（必须写清）：

irq:irq_handler_entry / exit
只覆盖 IRQ handler 本身

❌ 不包含 softirq
❌ 不包含网络处理
❌ 不包含 RX
❌ 不包含 RSS

3️⃣ IRQ handler 里允许做什么（内核约束）

IRQ handler 必须极短：

  • ACK 中断

  • 读取少量寄存器

  • 标记事件

  • 最多：触发 softirq

禁止：

  • 大量循环

  • 复杂逻辑

  • 网络协议处理

👉 所以：
IRQ handler 本身耗时长 = 异常

4️⃣ 如何“只用 IRQ 证据”判断是否有压力

（1）中断分布（次数）

cat /proc/interrupts

判断规则（硬规则）：

现象结论
单 IRQ 在单 CPU 暴涨 IRQ 分布不合理
同类 IRQ 多 CPU 均衡增长 IRQ 分布合理

（2）IRQ handler CPU 占比（时间）

perf top -e irq:irq_handler_entry,irq:irq_handler_exit

判断规则：

现象结论
irq handler 占比极低 IRQ 正常
irq handler 长时间占 CPU IRQ 压力 / 异常

（3）mpstat（只作佐证）

mpstat -P ALL 1

只看 %irq

%irq 高 ≠ 网络问题
%irq 高 = CPU 在处理中断

5️⃣ IRQ 的最终判定标准（独立）

必须同时满足：

  1. /proc/interrupts 显示异常集中或暴涨

  2. perf 显示 irq handler 占比异常

  3. %irq 持续偏高

👉 才能下结论：IRQ 有压力

二、RX（网络接收队列）——100% 底层、独立说明

本节只讨论 RX（网络接收处理）
不讨论 IRQ 是怎么来的
不讨论 RSS 是怎么分流的

1️⃣ RX 在内核中的真实位置

RX 不是硬中断阶段，而是：

irq_exit()
  ↓
__do_softirq()
  ↓
softirq:softirq_entry (vec=NET_RX)
  ↓
net_rx_action()
  ↓
NAPI poll

RX 的本质：

CPU 在 softirq 上下文中批量处理接收包

2️⃣ RX 的“队列”是什么

  • 每个 CPU 有一个 softnet_data

  • RX backlog 存在于 softirq 层

  • RX 是否挤压，只和 softirq 处理能力 有关

3️⃣ RX 的唯一权威观测接口

/proc/net/softnet_stat

cat /proc/net/softnet_stat

前三列（十六进制）：

字段含义
processed 已处理包
dropped RX 队列丢包
time_squeeze RX 被挤压、延迟

4️⃣ RX 是否有压力（硬标准）

这是不可争辩的内核定义：

条件结论
dropped > 0 RX 溢出
time_squeeze > 0 RX 挤压
二者都为 0 RX 正常

⚠️ 与 CPU 使用率无关
⚠️ 与 IRQ 是否高无关

5️⃣ RX 压力判定脚本（生产级）

awk '{
  cpu=NR-1
  p=strtonum("0x"$1)
  d=strtonum("0x"$2)
  t=strtonum("0x"$3)
  if(d>0 || t>0)
    printf "CPU%d RX异常 processed=%d dropped=%d squeeze=%d\n",cpu,p,d,t
}' /proc/net/softnet_stat

6️⃣ RX 的最终判定标准（独立）

只认 /proc/net/softnet_stat

任何不基于它的 RX 结论，都是不成立的。

三、RSS（接收侧流量分散）——100% 底层、独立说明

本节只讨论 RSS（Receive Side Scaling）
不涉及 IRQ
不涉及 RX 是否溢出

1️⃣ RSS 的本质（硬件层）

RSS 是 网卡硬件行为：

  • 对包做 hash（5-tuple / 4-tuple）

  • 决定 落入哪个 RX 队列

  • 不处理包、不消费 CPU

2️⃣ RSS 在系统中的真实位置

包到达网卡
  ↓
NIC 计算 hash
  ↓
选择 RX queue

RSS 在 IRQ 和 RX 之前完成

3️⃣ RSS 是否合理的唯一判断目标

不同流是否被分散到不同 CPU

4️⃣ RSS 是否生效的硬证据

（1）队列数量

ethtool -l eth0

（2）hash 功能

ethtool -k eth0 | grep hash

（3）分布效果（只看 processed）

cat /proc/net/softnet_stat

判断规则：

现象结论
processed 集中在少数 CPU RSS 无效
processed 分布均匀 RSS 正常

5️⃣ RSS 的最终判定标准（独立）

RSS 只关心一件事：

包是否被均匀分散

与：

  • IRQ 是否高 ❌

  • RX 是否丢包 ❌

  • CPU 是否 100% ❌

没有直接因果关系

四、你给出的这段路径，最终正确解释（封口）

硬件中断
  ↓
irq_handler_entry        ← 这里只能说明“硬中断”
  ↓
IRQ handler
  ↓
irq_handler_exit
  ↓
irq_exit()
  ↓
__do_softirq()
  ↓
softirq:softirq_entry (vec=NET_RX)  ← 这里才是 RX
  ↓
net_rx_action()

必须这样解读：

  • irq:* → 只能分析 IRQ

  • softirq NET_RX → 才是 RX

  • RSS → 更早，在网卡里

最终三句封口（按你要求）

CPU 100% ≠ IRQ 有问题
CPU 100% ≠ RX 有问题
CPU 100% ≠ RSS 有问题

IRQ / RX / RSS 必须各自用各自的证据

如果你下一步要，我可以：

  • 把这三节 拆成三份独立 SOP

  • 或直接 整理成内核网络排障手册目录版

你一句话，我继续。

posted on 2025-12-30 15:03  吃草的青蛙  阅读(0)  评论(0)    收藏  举报

导航