%si偏高且集中于单核暴露网络I/O处理不均衡，需结合top每核视图、ethtool查RSS队列、ps查worker绑定CPU、RPS分散软中断及NUMA亲和优化。
直接看 %si 不能判定 Worker 进程的网络 I/O 分布健康度，它反映的是 CPU 处理软中断的开销，不是进程级行为。但 %si 偏高且集中在个别 CPU 核上，往往暴露了网络 I/O 处理不均衡的问题——这正是 Worker 进程（尤其是 Nginx、HAProxy、Java Netty 等）实际运行时的典型隐患。
先确认 %si 是否真高且不均
运行 top 后按 1 显示每核 CPU，观察：
- 单核 %si > 10% 且持续波动，其它核
- 所有核 %si 总和 > 5% 且 wa 很低（如
- 注意对比 %sy（内核态）是否同步升高——若 sy 也高，可能是协议栈处理繁重（如 TLS 卸载、连接跟踪）
定位软中断来源：查 /proc/interrupts 和 softirqs
执行以下命令快速判断是否为网络收包中断主导：
-
cat /proc/interrupts | grep -E "(NET_RX|RX)"—— 查看各 CPU 上 NET_RX 中断计数分布；若某核数值远超其它核（比如差 5 倍以上），说明网卡 RX 队列绑定失衡 -
cat /proc/softirqs | grep "NET_RX"—— 确认软中断总耗时中 NET_RX 占比；若占比 > 80%，基本锁定网络收包路径 - 结合
ethtool -l eth0查看网卡 RSS（接收侧缩放）队列数，再用ethtool -x eth0看当前 hash 表分布——不均的 hash 映射会导致流量全打到 1–2 个队列
关联 Worker 进程与 CPU 绑定关系
%si 不均常导致 Worker 进程“看不见”的负载倾斜：
- 用
ps -eo pid,comm,psr | grep worker查看各 Worker 进程当前运行在哪颗 CPU 上（psr 列） - 若多数 Worker 被调度到 %si 高的核，它们会频繁被软中断抢占，表现为响应延迟抖动大、吞吐上不去，即使 top 里 us/sy 看似不高
- 检查是否启用了 CPU 亲和（如 Nginx 的
worker_cpu_affinity或 systemd 的CPUAffinity=）；若未设置，内核默认调度容易加剧热点
验证与调优建议
不要只盯着 top 的瞬时 %si，需结合业务表现交叉验证：
- 用
ss -s观察 ESTAB 连接数 +netstat -s | grep "packet receive"看丢包/错包是否上升——软中断过载可能导致 netdev backlog 溢出丢包 - 临时启用 RPS（Receive Packet Steering）：
echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus（f 表示前 4 核），让软中断分散到多核处理 - 对多队列网卡，用
taskset -c 0-3 numactl --cpunodebind=0 nginx等方式，把 Worker 进程和对应网卡 RX 队列尽量绑定在同一 NUMA 节点
