不能单凭softirq高就增加worker数量，因其属内核层而worker属用户态，二者层级不同；应先用watch -d 'cat /proc/softirqs'定位net_rx、timer、rcu/block异常源，仅当%us持续>60%、%sy
不能单看 softirq 占用率就决定增加 worker 数量。softirq 高往往反映的是内核网络或定时器等底层处理压力大，而 worker 进程属于用户态服务层，二者不在同一执行层级——增加 worker 不仅无法缓解 softirq 压力，还可能因更多进程争抢 CPU、加剧软中断排队，反而恶化延迟。
先区分 softirq 高的真正来源
运行 watch -d 'cat /proc/softirqs'，重点关注三类指标：
- NET_RX 持续快速上升 → 网络入包多，但不等于应用层需要更多 worker；更可能是网卡收包后软中断处理不过来
- TIMER 显著偏高 → 可能是大量定时任务（如连接超时、健康检查）触发，需检查业务逻辑或连接管理策略
- RCU 或 BLOCK 异常增长 → 通常与内核锁竞争或块设备 I/O 延迟有关，和 worker 数量基本无关
判断是否该调 worker 的关键信号
只有当满足以下全部条件时，才可考虑增加 worker：
- top 中 %us（用户态）持续高于 60%，且主要消耗来自你的服务进程（如 nginx、OpenNJet）
- 同时 %sy（系统态）和 %si（softirq）处于正常范围（例如 sy
- 请求队列积压明显：如 nginx 的 ngx_http_request_t pending 数上升、或 access log 中 503/504 增多、或 upstream queue time 显著拉长
softirq 高时更应做的三件事
比起加 worker，优先做这些调整：
- 启用 RPS/RFS：把 NET_RX 负载分散到多个 CPU，避免单核 ksoftirqd/0 过载（尤其在单队列网卡场景）
- 检查网卡多队列并绑定中断：用 ethtool -l eth0 查队列数，再通过 smp_affinity_list 将不同 RX/TX 队列绑定到不同 CPU 核心
- 降低单 worker 处理压力：比如 OpenNJet 中启用 sysguard_cpu 模块，让 worker 数随平均 CPU 使用率自动伸缩，而非盲目固定高位
softirq 是内核调度层的问题，worker 是应用服务层的配置。两者要分开诊断、分类应对。误把软中断瓶颈当成并发不足，容易引发资源错配和性能震荡。
