pidstat -u 5 不显示软中断，因其运行于内核上下文且无进程归属；应聚焦“谁未及时收包”“谁绑定单核网卡”“谁导致接收缓冲区满”等行为模式，结合ss、mpstat、/proc/softirqs等定位根因。
pidstat -u 5 不显示进程产生的软中断，它压根不采集软中断数据——软中断运行在内核上下文，不属于任何用户进程，pidstat 看不见它。
要查“哪个进程和软中断强相关”，得换思路：不是看“进程触发了软中断”，而是看“哪个进程的行为导致软中断持续高负载”。
软中断没有归属进程，但有触发源头
软中断（如 NET_RX）由硬中断唤醒，而硬中断来自网卡、磁盘等设备；设备被谁驱动？往往是用户进程发起的 I/O 请求（比如 recv() 调用不及时，导致接收队列堆积，进而让 NAPI 持续轮询、刷 NET_RX）。所以真正可追溯的是「行为模式」，不是调用栈归属。
查哪些进程在拖慢 NET_RX 处理
当 NET_RX 单核飙升时，常见原因是应用没及时从 socket 读数据，导致内核不断搬运包进 backlog，软中断反复执行。验证方法：
- 用
ss -i查每个 socket 的rcv_ssthresh和rcv_space：若rcv_space长期接近 0 或远小于rcv_ssthresh，说明接收缓冲区满，应用读太慢 - 用
cat /proc/net/snmp | grep -A1 Tcp | grep -E "InSegs|EstabResets"看是否有大量重传或连接异常重置，间接反映应用处理延迟 - 用
perf record -e syscalls:sys_enter_recvfrom -C 0 -- sleep 5抓目标 CPU 上的 recv 系统调用频次，低频 +NET_RX高增 = 典型读取不足
查哪个进程绑定了高中断网卡
如果某进程通过 setsockopt(SO_BINDTODEVICE) 或 DPDK 绑定到特定网卡，而该网卡硬中断全打在单核上，那它的流量就会集中触发对应 CPU 的 NET_RX。确认方式：
- 先用
grep enp3s0f0 /proc/interrupts确认该网卡 IRQ 分布 - 再查该网卡是否被进程独占：
lsof -i | grep enp3s0f0（仅对 socket 绑定有效）；DPDK 进程需看其启动参数或cat /proc/$(pid)/maps | grep hugepages - 用
cat /proc/irq/*/affinity_list对照网卡 IRQ 和进程 CPU 亲和性（taskset -cp $(pid)），重叠即存在竞争风险
别信 perf -p 对软中断的“归因”
perf record -e irq:softirq_entry -p $(pgrep -f myapp) 几乎总为空——因为 softirq_entry 事件运行在 ksoftirqd/CPUx 线程上下文，不属于用户进程 PID。你看到的“关联”，其实是采样时碰巧该进程在同 CPU 上调度，不是因果关系。
真正有效的做法是：把 mpstat -P ALL 1 的 %soft、watch -n 1 'grep NET_RX /proc/softirqs' 的增长速率、ss -tin 的 rcv_rtt 和 retrans 字段三者对齐，才能判断是驱动、网卡配置，还是应用读取逻辑的问题。
软中断本身不可归属，但它的爆发点永远藏在“谁没及时收包”“谁把中断钉死在一核”“谁让网卡只能单队列干活”这些具体动作里。盯着进程列表找“软中断制造者”，方向就错了。
