5分钟内用top、ps、uptime、vmstat定位高cpu进程及原因，10分钟内按场景kill、降权或限流止血，并记录现场防复发。
发现 CPU 高负载，第一反应不是慌，而是快准稳：5 分钟内锁定问题进程，10 分钟内判断是否可临时缓解。核心目标是止血——不让系统彻底卡死、不引发连锁故障（如服务超时、连接堆积、日志刷屏）。
一、5分钟内定位“真凶”进程
别等界面刷新，用命令直取关键信息：
- top -b -n 1 | head -20：静默输出一次快照，按 CPU 排序，一眼看到前几位 PID 和命令名；
- ps -eo pid,ppid,%cpu,cmd --sort=-%cpu | head -10：列出真实 CPU 占比最高的 10 个进程，含父进程和完整启动命令，便于溯源；
- uptime：看 load average 三个值，若 1 分钟值 > CPU 核心数（如 8 核机器 load > 8），确认已过载；
- vmstat 1 5：重点看 us（用户态）、sy（内核态）、wa（I/O 等待）三列——us 高指向业务程序，sy 高可能有锁竞争或中断风暴，wa 高则说明 CPU 在干等磁盘，实际不是“忙”，而是“闲等”。
二、区分场景，选择止血动作
根据上一步判断，走不同路径：
- 如果是单个用户进程（如 java、python、nginx worker）持续占满一个或多个核：先 sudo kill -15 PID 尝试优雅终止；若无响应且业务允许，再 sudo kill -9 PID；Java 类进程可配合 top -Hp PID 找出高耗线程，转成十六进制后用 jstack PID | grep -A20 0x... 查堆栈，确认是否死循环或频繁 GC；
- 如果是大量短生命周期进程（如 cron 脚本、监控采集器密集拉起）：用 ps auxf 看进程树，定位父进程或触发源，临时禁用对应定时任务（crontab -e 注释掉）；
- 如果 wa 明显偏高（>20%），且 load 很高但 us/sy 不高：运行 iotop -o 找出真正在做 I/O 的进程，再结合 iostat -x 1 3 看 await 和 %util，确认是否磁盘瓶颈；此时 CPU 高是假象，重点应查存储层，而非杀进程；
- 如果 sy 异常高（>30%），且 cs（上下文切换）数值巨大：执行 cat /proc/interrupts 查看中断分布，是否存在某 CPU 核被网卡或 NVMe 长期霸占；也可临时关闭 NMI watchdog：echo 0 > /proc/sys/kernel/nmi_watchdog（仅应急，事后需恢复）。
三、临时降权，争取排查时间
无法立即终止又影响业务时，用资源调控“拖时间”：
- 降低进程优先级：sudo renice 10 PID（值越大越低，范围 -20~19），让其让出 CPU 时间片；
- 限制 CPU 使用率：安装 cpulimit 后执行 cpulimit -p PID -l 50（限制最多用 50% CPU），适合 Java 或 Python 类长期运行服务；
- 暂停非关键服务：systemctl stop snapd lxd docker（视环境而定），减少后台干扰；
- 清空 pagecache（谨慎）：sync && echo 3 > /proc/sys/vm/drop_caches，仅在确认是缓存抖动引发的短暂 spike 时使用，避免误伤。
四、止血后必须做的两件事
应急结束不等于问题消失：
- 记录原始现场：保存 top、ps、vmstat、iostat、dmesg -T | tail -50 的输出，为后续复盘留据；
- 检查是否有自动恢复机制被触发：比如 systemd 的 Restart=on-failure 是否反复拉起崩溃进程，或 kubernetes 中的 Pod 重启风暴——这类“止血后复发”最易被忽略。
