Linux CPU调度延迟高通常源于内核软中断堆积、中断亲和性失衡、实时任务抢占或驱动问题，而非CPU算力不足；需检查ksoftirqd负载、IRQ分布、实时进程、网卡驱动及卸载配置，并用bpftrace等工具精准定位NET_RX软中断延迟。
Linux CPU调度延迟高，往往不是CPU算力不够，而是任务得不到及时调度或被阻塞在某个环节。真实瓶颈常藏在内核软中断、中断亲和性、实时任务抢占或驱动行为中，而不是 top 里排第一的用户进程。
看软中断是否堆积在单个 CPU 上
ksoftirqd 延迟高，本质是网络收包、定时器等 softirq 任务积压后，内核线程无法及时获得 CPU 时间片。这不是“CPU 慢”，而是调度不均。
- 用 cat /proc/interrupts 查网卡 IRQ 是否集中在某一个 CPU 核（比如所有 eth0 的 RX/TX 行只在 CPU0 上计数飙升）
- 运行 top -H，观察 ksoftirqd/0、ksoftirqd/1 等线程的 CPU 占用是否持续偏高且不均衡
- 检查是否启用了 irqbalance：systemctl status irqbalance；若关闭，手动绑定 IRQ 到多核：echo 2 > /proc/irq/$(grep eth0 /proc/interrupts | head -1 | awk '{print $1}' | tr -d ':')/smp_affinity_list
查是否有高优先级任务长期霸占 CPU
实时进程（SCHED_FIFO/SCHED_RR）哪怕只占 5% CPU，也可能把 ksoftirqd 挤出调度队列，造成毫秒级抖动。
- 执行 ps -eo pid,tid,class,rtprio,ni,pri,pcpu,comm --sort=-pcpu | head -20，重点关注 class 列为 FF 或 RR、rtprio > 0 的进程
- 用 chrt -p PID 查具体进程调度策略；临时降级可执行 chrt -o -p 0 PID
- 检查是否启用了 watchdog、某些硬件监控工具或自定义实时服务
确认网卡中断与驱动是否引发调度失衡
老旧驱动或错误的卸载配置（如 TSO/GSO）会导致 hardirq 执行时间过长，挤压 softirq 处理窗口，最终表现为 ksoftirqd 调度延迟。
- 运行 ethtool -i eth0 查驱动名和固件版本，比对厂商最新 release（尤其 Intel I210、Realtek RTL8169 等常见问题型号）
- 临时禁用卸载功能测试：ethtool -K eth0 tso off gso off gro off，观察延迟是否收敛
- 检查 dmesg | grep -i "irq\|error\|firmware" 是否有中断丢失、DMA timeout 或固件告警
用 bpftrace 快速验证 softirq 实际延迟
别只信 top 或 /proc/stat，真实 NET_RX 软中断耗时得靠 eBPF 抓取上下文。
- 安装 bpftrace：yum install -y bpftrace（CentOS/RHEL）或 apt install -y bpftrace（Debian/Ubuntu）
- 运行脚本检测超 100ms 的 NET_RX 延迟：bpftrace -e 'kprobe:net_rx_action { @start[tid] = nsecs; } kretprobe:net_rx_action /@start[tid]/ { $delta = nsecs - @start[tid]; if ($delta > 100000000) {@hist = hist($delta); printf("NET_RX >100ms: %d ns\n", $delta); } delete(@start[tid]); }'
- 若输出频繁，再结合 /proc/interrupts 和 perf record -e irq:softirq_entry -a sleep 10 定位触发源
