摘要：线上服务器是业务的命脉，而CPU作为服务器的核心部件，直接决定了系统的计算能力。一旦CPU使用率飙升到100%，后果不堪设想：网站打不开、订单无法处理、数据同步中断，甚至可能引发系统宕机。CPU爆满不仅考验服务器的性能，更考验运维人员的应急能力。

线上服务器是业务的命脉，而CPU作为服务器的核心部件，直接决定了系统的计算能力。一旦CPU使用率飙升到100%，后果不堪设想：网站打不开、订单无法处理、数据同步中断，甚至可能引发系统宕机。CPU爆满不仅考验服务器的性能，更考验运维人员的应急能力。

那么，当CPU爆满时，我们该如何下手？是直接重启服务器，还是盲目杀掉进程？显然，这些都不是明智之举。正确的做法是循序渐进地排查，找到问题的根源，再对症下药。接下来，我将带你一步步走进排查与解决的全过程。

CPU爆满看似是个大问题，但只要有条理地排查，就能化繁为简。以下是我总结的排查步骤，每一步都配有详细的命令和操作思路。

接到报警的第一件事，就是登录服务器，确认CPU到底有多“忙”。Linux系统中，最常用的工具莫过于top命令。

运行top后，你会看到一个实时更新的界面，顶部显示系统资源概况。重点关注以下几行：

如果看到id接近0%，us或sy高达90%以上，恭喜你，CPU确实爆满了。

小技巧：在top界面，按Shift + P，可以按CPU使用率对进程排序，快速找到“吃”CPU最多的家伙。

top已经帮我们锁定嫌疑犯，接下来要查清它的身份。记下CPU占用最高的进程ID（PID），比如某个进程PID是784，然后用ps命令挖出更多信息：

输出会显示进程的详细信息，包括启动命令、用户、运行时间等。

进阶操作：想知道进程用了多少CPU时间？试试这个：

如果进程运行时间很短但CPU占用极高，可能是突发问题；如果运行时间很长，可能是慢性消耗。

找到高CPU进程后，别急着杀掉它，先搞清楚它在干什么。

Java应用是CPU爆满的常客，尤其是线程池配置不当或死循环时。可以用jstack查看线程堆栈：

打开jstack.log，搜索关键字RUNNABLE，找到活跃线程的堆栈。如果看到某个线程反复执行某段代码（比如某个while循环），问题就暴露了。

辅助命令：先用jps找到Java进程的PID：

对于非Java进程，strace是排查利器，可以跟踪系统调用：

strace.log会记录进程的系统调用，比如read、write或fork。如果看到某个调用频繁重复，可能是代码逻辑问题或IO瓶颈。

注意：strace会影响性能，线上环境谨慎使用，抓几秒数据即可。

CPU高不一定是单个进程的问题，也可能是系统整体超载。用uptime快速查看负载：

输出示例：

load average后面的三个数字分别是1分钟、5分钟、15分钟的系统负载。如果负载远高于CPU核心数（比如4核机器负载超过4），说明任务堆积严重。

再用vmstat看详细资源情况：

输出示例：

有时CPU爆满不是内部问题，而是外部流量冲击导致。用iftop查看网络流量：

iftop会显示每个连接的带宽占用。如果某个IP流量异常高，可能是DDoS攻击或爬虫。

没装iftop？试试nethogs：

它按进程显示网络使用情况，帮你找到流量大户。

日志是排查的宝藏。系统日志用这个命令：

如果是Ubuntu，可能看/var/log/syslog；CentOS则是/var/log/messages。找找有没有错误提示，比如Out of memory或硬件故障。

应用日志路径因项目而异，比如Nginx可能是/var/log/nginx/error.log，逐个排查吧。

CPU爆满是用户态还是内核态问题？用mpstat一探究竟：

输出示例：

排查出原因后，接下来是解决问题。以下是常见场景的应对措施。

如果jstack发现死循环，或perf定位到低效算法，赶紧通知开发优化代码。临时缓解可以用kill -9 PID杀进程，但要确保业务有重启机制。

性能分析：

并发连接过多？调整TCP参数：

文件描述符不够？修改限制：

CPU不够用？只能升级硬件或加机器了。临时可以用nice降低进程优先级：

部署Nginx或HAProxy做负载均衡，分担压力。配置简单，这里不展开。

发现病毒？用kill干掉，再用clamav扫一遍：

CPU爆满是运维路上的拦路虎，但只要掌握排查技巧，就能化险为夷。从top到jstack，从日志到网络，每一步都可能藏着关键线索。希望这篇文章能成为你的实战指南，下次“天塌”时，愿你从容不迫，笑对危机！

来源：wljslmz