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

明白了，你希望做一个 完整、系统、实践可操作的文档，涵盖 IRQ affinity → RX 队列 → RSS，并且特别关注 如何严谨判断 CPU 100% 是否由 IRQ 引起。我会分成 概念、作用、查看方法、验证瓶颈、优化建议五个部分，并提供 可落地命令与示例。我会重点说明为什么 单看 mpstat 或 CPU 占满并不能直接说明 IRQ 是原因。

下面是完整整理：

---

网络中断与 CPU 占用优化实践文档

---

一、IRQ Affinity（中断亲和性）

1. 概念

• IRQ（Interrupt Request）是硬件触发 CPU 处理的请求。

• IRQ Affinity：指定特定 CPU 核心来处理特定设备的中断。

• 目的是避免：

  • 所有中断集中在某个核 → CPU 过载。

  • CPU cache 被频繁切换 → 性能下降。

2. 作用

• 分散中断负载，提高多核 CPU 利用率。

• 减少 CPU cache miss，提高网络处理效率。

• 与 RX 队列 和 RSS 配合，可做到中断和网络流量的合理分配。

3. 查看方法

1. 查看网络设备中断：

cat /proc/interrupts | grep eth0

输出示例：

  32:    1234567   0   0   0   0   0   0   0  IR-PCI-MSI  eth0-TxRx-0
  33:    2345678   0   0   0   0   0   0   0  IR-PCI-MSI  eth0-TxRx-1

• 32、33 为 IRQ 号，每列对应 CPU 核心处理次数。

2. 查看当前 CPU affinity：

cat /proc/irq/32/smp_affinity

• 输出是 16 进制掩码，表示允许哪些 CPU 处理此 IRQ。

4. 验证 CPU 是否因 IRQ 占用

关键点：不能仅凭 mpstat -P ALL CPU 100% 就认为 IRQ 占用高。

1. 查看软中断（softirq）：

cat /proc/softirqs

2. 查看具体 IRQ 处理：

grep eth0 /proc/interrupts

3. 比较 CPU 利用率：

watch -n 1 "cat /proc/interrupts | grep eth0"

• 如果 CPU 某核心中断计数极高且增长快，同时 softirq 对应 net_rx、net_tx 显著上升 → IRQ 相关。

• 注意：用户态高 CPU (top/us) 不一定是 IRQ 引起，可能是应用处理网络包本身。

5. 优化建议

• 使用 smp_affinity 分配 IRQ 到空闲核心。

• 对多队列网卡，建议每队列单独绑定核心。

• 可用 irqbalance 自动平衡，但对高性能网络需手动调优。

---

二、RX 队列（Receive Queue）

1. 概念

• NIC（网卡）接收数据包后放入 RX 队列，由 CPU 处理。

• 多队列网卡可分布到不同 CPU 核心，提高并发处理能力。

2. 作用

• 配合 RSS，将流量分散到多个队列/CPU。

• 防止单核心成为瓶颈。

• 提升高吞吐网络性能。

3. 查看方法

1. 查看网卡队列数：

ethtool -l eth0

示例输出：

Channel parameters for eth0:
Pre-set maximums:
RX: 8
TX: 8
Current hardware settings:
RX: 4
TX: 4

2. 查看队列分配 CPU：

cat /proc/irq/32/smp_affinity

• 对应 RX 队列的 IRQ 号。

4. 验证瓶颈

• 高 CPU 占用但 RX 队列计数低 → 可能队列太少。

• 单队列被某核心独占 → CPU 饱和。

• 使用 perf、top、htop、watch -n 1 cat /proc/interrupts 可观察各队列增长。

5. 优化建议

• 增加 RX 队列数：

ethtool -L eth0 rx 8 tx 8

• 每队列绑定一个 CPU 核心。

• 注意 RSS 与 IRQ affinity 配合。

---

三、RSS（Receive Side Scaling）

1. 概念

• RSS 是 NIC 的硬件功能。

• 通过哈希（如四元组 IP/Port）将流量分散到多个 RX 队列。

• 可以实现网络包在多 CPU 上并行处理。

2. 作用

• 提升多核 CPU 网络性能。

• 避免单核网络包处理过载。

• 与 IRQ affinity + RX 队列一起工作。

3. 查看方法

1. 查看 RSS 队列哈希：

ethtool -n eth0

• 显示当前 RSS hash 配置。

2. 查看队列绑定 CPU：

cat /proc/irq/<IRQ>/smp_affinity

4. 验证瓶颈

• 高流量下，如果单队列 CPU 饱和 → RSS 没生效。

• 使用：

watch -n 1 "cat /proc/interrupts | grep eth0"

• 或者 perf top 观察 softirq、net_rx_action 调度是否集中在某核。

5. 优化建议

• 启用 RSS，设置合适的哈希算法。

• 调整队列数量与 CPU 核心数匹配。

• 对大流量应用，可手动绑定队列到 CPU。

---

四、严谨判断 CPU 是否由 IRQ 占用

不要只看 mpstat -P ALL 1 或 CPU 100%

1. 命令组合

# 查看 CPU 使用情况
mpstat -P ALL 1

# 查看软中断
cat /proc/softirqs

# 查看硬件中断
cat /proc/interrupts | grep eth0

# top/htop 查看 user/system CPU
top -H -p <PID>   # 查看某进程线程 CPU

2. 判断逻辑

1. 若 CPU system/softirq 高 → 与中断相关。

2. 交叉验证：

   • CPU 某核心硬中断计数快速增长。

   • 对应 softirq net_rx/net_tx 显著增加。

   • 同时 user-space 应用 CPU 占用低 → 说明中断处理是瓶颈。

3. 否则，CPU 可能是应用层处理网络流量高导致的。

3. 样例分析

假设 eth0 的 IRQ 32：

CPU0 CPU1 CPU2 CPU3
32: 100000 2000 3000 1000

• CPU0 处理绝大部分中断 → CPU0 system/softirq 高 → 需要调整 affinity。

---

五、整体优化建议

1. 确认问题来源

   • top、mpstat、/proc/interrupts、/proc/softirqs 结合判断。

2. IRQ Affinity

   • 将高负载队列 IRQ 分散到空闲核心。

3. RX 队列

   • 增加队列数，确保每队列有独立 CPU。

4. RSS

   • 启用 RSS，确保流量按哈希均匀分配。

5. 监控

   • 持续 watch /proc/interrupts 和 softirqs。

   • 高负载时用 perf top -g 定位热点。

---

✅ 重要总结（重复三遍）

1. CPU 100% ≠ IRQ 占用，必须通过 /proc/interrupts + /proc/softirqs + mpstat/perf 综合验证。

2. IRQ affinity + RX 队列 + RSS 配合调整，才能真正解决 CPU 网络瓶颈。

3. 监控和验证是关键，不要凭直觉或单一工具判断。

---

我可以帮你做一个 可直接执行的验证脚本示例，一键输出 CPU/IRQ/RX 队列/softirq 数据，并计算是否 IRQ 成为瓶颈，直接落地生产环境。

你希望我帮你写这个脚本吗？