当%si持续偏高（>10%～15%）且集中在少数cpu核时，表明net_rx软中断成瓶颈，需通过rps、绑定worker、调优netdev_budget（千兆60–120/万兆120–240）与backlog协同优化。
当 %si 在 top 中持续偏高（例如 >10%～15%），尤其集中在某几个 CPU 核上，说明软中断（尤其是 NET_RX）正在成为瓶颈，而 Nginx、Redis 或其他 worker 模型服务的并发处理能力会因此被拖慢——不是 CPU 算力不够，而是大量时间被内核收包、协议栈处理占用，worker 进程得不到及时调度。此时调优 worker 并发分布，核心是让 worker 与软中断处理在 CPU 层面协同，而非竞争。
先确认 %si 是否真由网络软中断主导
运行 cat /proc/softirqs，重点看 NET_RX、TIMER、SCHED 三列数值。若 NET_RX 占比超 80%，且某 CPU（如 CPU1）的该值远高于其他核（例如 120 万 vs 其他核均 net_rx_action 抢占。
绑定 worker 进程到非高 si 的 CPU
避开软中断热点核，把业务 worker 分散到低负载核上，能显著减少上下文切换和延迟抖动：
- Nginx 使用
worker_cpu_affinity显式绑定，例如 4 核机器中 CPU1 软中断高，则配置：worker_cpu_affinity 0001 0100 1000;（跳过 CPU1，用 0/2/3） - 自研服务启动时加
taskset -c 0,2,3 ./app，限制可用 CPU - 若使用 systemd，可在 service 文件中设置
CPUAffinity=0 2 3
启用 RPS 并对齐 worker 分布
RPS（Receive Packet Steering）能在软件层把软中断分发到多个 CPU，但必须与 worker 分布匹配，否则出现“包在 A 核处理，worker 在 B 核等待”的跨核缓存失效：
- 开启 RPS：写掩码到对应网卡队列，例如
echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus（启用 CPU0–3） - 确保
/proc/sys/net/core/rps_cpu_mask非空（推荐设为ff或按实际 CPU 数设） - worker 进程数建议 ≤ 启用 RPS 的 CPU 数；若启用了 3 个 CPU 处理软中断，worker 最好也控制在 3 个并分别绑定
配合调整 netdev_budget 与 backlog
net.core.netdev_budget 控制单次软中断最多处理多少包，默认 300。设得过大（如 600）会让单次 __do_softirq 占用太久，反而卡住 worker 调度：
- 千兆网卡建议设为 60–120，万兆设为 120–240
- 同步增大
net.core.netdev_max_backlog至 ≥5000，避免丢包转为延迟 - 仅调 budget 不开 RPS，效果有限；必须软中断能分发，worker 才能真正受益
