线上服务器是业务的命脉，而CPU作为服务器的核心部件，直接决定了系统的计算能力。一旦CPU使用率飙升到100%，后果不堪设想：网站打不开、订单无法处理、数据同步中断，甚至可能引发系统宕机。CPU爆满不仅考验服务器的性能，更考验运维人员的应急能力。
那么，当CPU爆满时，我们该如何下手？是直接重启服务器，还是盲目杀掉进程？显然，这些都不是明智之举。正确的做法是循序渐进地排查，找到问题的根源，再对症下药。接下来，我将带你一步步走进排查与解决的全过程。
排查步骤：从混乱中找到线索
CPU爆满看似是个大问题，但只要有条理地排查，就能化繁为简。以下是我总结的排查步骤，每一步都配有详细的命令和操作思路。
第一步：确认CPU使用率，摸清现状
接到报警的第一件事，就是登录服务器，确认CPU到底有多“忙”。Linux系统中，最常用的工具莫过于top命令。
top 运行top后，你会看到一个实时更新的界面，顶部显示系统资源概况。重点关注以下几行：
- %Cpu(s)：展示CPU的使用情况。us（user）：用户态CPU使用率，通常是应用程序占用。sy（system）：内核态CPU使用率，通常与系统调用相关。id（idle）：空闲率，数值越低说明CPU越忙。
如果看到id接近0%，us或sy高达90%以上，恭喜你，CPU确实爆满了。
小技巧：在top界面，按Shift + P，可以按CPU使用率对进程排序，快速找到“吃”CPU最多的家伙。
第二步：定位高CPU进程，抓住元凶
top已经帮我们锁定嫌疑犯，接下来要查清它的身份。记下CPU占用最高的进程ID（PID），比如某个进程PID是784，然后用ps命令挖出更多信息：
ps -ef | grep 784 输出会显示进程的详细信息，包括启动命令、用户、运行时间等。
进阶操作：想知道进程用了多少CPU时间？试试这个：
ps -p grep -o %cpu,etime - %cpu：CPU使用百分比。
- etime：进程运行的总时间。
如果进程运行时间很短但CPU占用极高，可能是突发问题；如果运行时间很长，可能是慢性消耗。
第三步：分析进程行为，深入挖掘
找到高CPU进程后，别急着杀掉它，先搞清楚它在干什么。
如果是Java进程
Java应用是CPU爆满的常客，尤其是线程池配置不当或死循环时。可以用jstack查看线程堆栈：
jstack 784 > jstack.log 打开jstack.log，搜索关键字RUNNABLE，找到活跃线程的堆栈。如果看到某个线程反复执行某段代码（比如某个while循环），问题就暴露了。
辅助命令：先用jps找到Java进程的PID：
jps -l 如果是其他进程
对于非Java进程，strace是排查利器，可以跟踪系统调用：
strace -p 3049767 -o strace.log strace.log会记录进程的系统调用，比如read()、write()或fork()。如果看到某个调用频繁重复，可能是代码逻辑问题或IO瓶颈。
注意：strace会影响性能，线上环境谨慎使用，抓几秒数据即可。
第四步：检查系统负载，了解全局
CPU高不一定是单个进程的问题，也可能是系统整体超载。用uptime快速查看负载：
uptime 输出示例：
load average后面的三个数字分别是1分钟、5分钟、15分钟的系统负载。如果负载远高于CPU核心数（比如4核机器负载超过4），说明任务堆积严重。
再用vmstat看详细资源情况：
vmstat 1 输出示例：
- r：运行队列中的进程数，值过高说明CPU忙不过来。
- us、sy、id：与top类似，反映CPU使用分布。
第五步：监控网络流量，排除外部干扰
有时CPU爆满不是内部问题，而是外部流量冲击导致。用iftop查看网络流量：
iftop -i enp3s0 iftop会显示每个连接的带宽占用。如果某个IP流量异常高，可能是DDoS攻击或爬虫。
没装iftop？试试nethogs：
nethogs enp3s0 它按进程显示网络使用情况，帮你找到流量大户。
第六步：翻查日志，寻找蛛丝马迹
日志是排查的宝藏。系统日志用这个命令：
tail -f /var/log/syslog 如果是Ubuntu，可能看/var/log/syslog；CentOS则是/var/log/messages。找找有没有错误提示，比如Out of memory或硬件故障。
应用日志路径因项目而异，比如Nginx可能是/var/log/nginx/error.log，逐个排查吧。
第七步：分析CPU使用模式，分清主次
CPU爆满是用户态还是内核态问题？用mpstat一探究竟：
mpstat -P ALL 1 输出示例：
- %usr高：用户态问题，多半是应用代码。
- %sys高：内核态问题，可能涉及系统调用或驱动。
解决方法：对症下药，恢复稳定
排查出原因后，接下来是解决问题。以下是常见场景的应对措施。
场景1：应用代码问题
如果jstack发现死循环，或perf定位到低效算法，赶紧通知开发优化代码。临时缓解可以用kill -9 PID杀进程，但要确保业务有重启机制。
性能分析：
perf record -p 12345 perf report 场景2：系统配置不当
并发连接过多？调整TCP参数：
sysctl -w net.core.somaxconn=1024 文件描述符不够？修改限制：
ulimit -n 65535 场景3：硬件瓶颈
CPU不够用？只能升级硬件或加机器了。临时可以用nice降低进程优先级：
renice 10 -p 12345 场景4：负载过高
部署Nginx或HAProxy做负载均衡，分担压力。配置简单，这里不展开。
场景5：恶意进程
发现病毒？用kill干掉，再用clamav扫一遍：
clamscan -r / 预防措施：防患于未然
解决问题后，别忘了亡羊补牢：
- 监控：用Zabbix或Prometheus实时监控，设置CPU告警。
- 测试：上线前用ab压测：
ab -n 10000 -c 100 http://baidu.com/ - 审查：定期查代码，优化瓶颈。
- 规划：根据业务量预留20%-30%资源冗余。
- 安全：装防火墙，限制异常流量。
运维无小事，稳定是王道
CPU爆满是运维路上的拦路虎，但只要掌握排查技巧，就能化险为夷。从top到jstack，从日志到网络，每一步都可能藏着关键线索。希望这篇文章能成为你的实战指南，下次“天塌”时，愿你从容不迫，笑对危机！