ksoftirqd 高占用但 net_rx/softnet 正常的 timer / block softirq 分析

ksoftirqd CPU 占用高但 net_rx/softnet 不涨，说明软中断高负载来自 TIMER 或 BLOCK 类型而非网络收包；通过 /proc/softirqs 观察其短时增量并结合 perf 分析调用栈可定位根因。

为什么 ksoftirqd CPU 占用高，但 net_rx/softnet 却不涨？

这说明软中断（softirq）的高负载并非来自网络收包路径（NET_RX），而是其他 softirq 类型在持续触发，最常见的是 TIMER 和 BLOCK 。linux 内核中 softirq 是按类型独立调度的，ksoftirqd 线程会轮询所有 pending 的 softirq 位图，哪怕只有 TIMER 或 BLOCK 长期置位，也会导致其持续运行、CPU 占用飙升。

如何确认是 TIMER / BLOCK softirq 引发的？

直接看 /proc/softirqs 各列累计计数，重点关注 TIMER 和 BLOCK 行在短时间内的增量：

watch -n 1 'grep -E "^(TIMER|BLOCK)" /proc/softirqs'

若某 CPU 的 TIMER 或 BLOCK 计数每秒增长数百甚至上千，而 NET_RX 几乎不动，基本可锁定问题来源。注意：该文件显示的是**自启动以来的总次数**，必须观察差值；同时要结合 top -H -p $(pgrep ksoftirqd) 看具体哪个 CPU 上的 ksoftirqd/N 在跑满。

TIMER softirq 持续高触发的典型原因

TIMER softirq 由内核定时器到期后触发，高频触发往往意味着有大量短周期 timer 在反复注册/触发，或存在 timer 延迟堆积：

• 用户态程序滥用 setitimer()、timerfd_settime()（如某些监控 agent、glibc 的 nanosleep 实现）
• 内核模块注册了未正确 cancel 的低精度 timer（尤其在高负载下被延迟，触发后立即重设）
• RCU 回调积压（RCU softirq 虽不直接计入 TIMER，但常与 timer 调度耦合，可通过 /proc/sys/kernel/rcu_normal 等排查）
• CONFIG_HIGH_RES_TIMERS=y 但硬件时钟源不稳定（如虚拟机中 TSC 不可靠），导致 hrtimer 层频繁 fallback 到低精度路径

BLOCK softirq 高但 I/O 并不繁忙？可能卡在哪儿

BLOCK softirq 主要处理 IO 完成回调（如块设备中断后的 bio 完成、request_queue 处理），高占用但磁盘 I/O 统计（iostat、/proc/diskstats）正常，常见于：

• IO 调度器死锁或 hang 住（如 mq-deadline 在特定队列深度下触发 spin-wait）
• 底层存储驱动 bug：完成回调未及时唤醒等待线程，导致 request_queue 中 completion work 积压
• 使用了 blk-mq 但硬件队列数配置不当（/sys/block/*/mq 下队列数远超物理队列），造成 softirq 在空转轮询
• ext4/xfs 日志提交（jbd2 或 xfslogd）卡在 barrier 或 fsync 等待，间接阻塞 block softirq 的 completion 处理链

可配合 perf record -e 'irq:softirq_entry' --Filter 'vec==1' -C N（N 为对应 CPU）抓取实际进入 TIMER softirq 的调用栈，或用 cat /proc/interrupts | grep -i 'timer|block' 看硬中断是否也异常——如果硬中断正常而 softirq 暴涨，基本排除硬件问题，聚焦内核路径逻辑缺陷或 misconfiguration。