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 在跑满。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
TIMER softirq 持续高触发的典型原因
TIMER softirq 由内核定时器到期后触发，高频触发往往意味着有大量短周期 timer 在反复注册/触发，或存在 timer 延迟堆积：
- 用户态程序滥用
setitimer()、timerfd_settime()（如某些监控 agent、glibc 的nanosleep实现） - 内核模块注册了未正确 cancel 的低精度 timer（尤其在高负载下被延迟，触发后立即重设）
- RCU 回调积压（
RCUsoftirq 虽不直接计入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。
