Linux CPU抖动是多因素叠加导致的响应延迟突增，需区分软中断压核、内存颠簸、cgroup开销过大及定时任务干扰四类根因，各自有对应诊断命令与修复策略。
Linux CPU抖动通常不是单一原因造成，而是多个层面问题叠加触发的响应延迟突增现象。关键要区分是“软中断压核”“内存颠簸”“cgroup开销过大”，还是“定时任务干扰”——它们表现相似（如%si飙升、RTT波动、sys占比异常），但根因和修复路径完全不同。
软中断不均导致的CPU抖动
当网卡收包压力集中到某一个CPU核时，该核的NET_RX软中断会持续占用大量时间，表现为top中%si长期超10%，perf top看到net_rx_action高频出现。
- 用
cat /proc/interrupts | grep eth0确认硬中断是否只打在单个CPU上 - 检查
/proc/softirqs中NET_RX列，看是否存在某CPU数值比其他高10倍以上 - 若RPS未启用，可手动开启：
echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus（按实际CPU数调整掩码） -
net.core.netdev_budget不宜盲目调大；千兆网建议60–120，万兆120–240，并同步增大net.core.netdev_max_backlog
内存系统性颠簸（thrashing）
这不是CPU忙，而是CPU空转却响应极慢——因为大量时间花在页面换入换出上。典型特征是free显示内存几乎耗尽、swap使用率上升、pgpgin/pgpgout值剧烈跳动。
- 运行
vmstat 1 10，关注si（swap in）和so（swap out）列是否持续非零 - 用
cat /proc/vmstat | grep -E "pgpgin|pgpgout|pgmajfault"观察缺页频率是否陡增 - 若
pgmajfault每秒数百次，说明工作集远超物理内存，需减少并发进程数或优化应用内存驻留行为 - 避免全局置换策略滥用，对关键服务可考虑memcg限制+LRU隔离
cgroup数量过多引发内核开销抖动
尤其在容器密度高的宿主机上，memory子系统遍历成千上万个cgroup会显著拖慢memcg_stat_show等内核函数，导致sys CPU飙升、请求延时毛刺明显。
- 执行
cat /proc/cgroups，重点关注memory行的num_cgroups是否超过1000 - 用
perf record -a -g sleep 10 && perf report，若memcg_stat_show或mem_cgroup_iter占比超20%，基本可锁定 - 清理闲置cgroup：删除无用容器后，确保其cgroup目录被自动回收（检查
/sys/fs/cgroup/memory/下残留） - 生产环境建议控制cgroup层级≤10，总数≤1000，避免嵌套过深或命名爆炸
外部周期性干扰源
看起来像CPU抖动，实则是计划任务、监控采集、日志轮转等每分钟/每5秒规律性触发造成的假象。这类问题常被忽略，因为top、htop等工具刷新间隔太长，看不出瞬时峰值。
- 用
sar -u 1 60抓取1秒粒度的CPU使用率，观察是否呈现严格周期性尖峰 - 检查
crontab -l和/etc/cron.d/下是否有高频任务，尤其是涉及find、grep、journalctl等I/O密集型命令 - 查看
/var/log/cron确认执行时间点是否与抖动时刻吻合 - 对低配机器，可将非关键cron任务错峰执行，或改用anacron降低并发压力
