有服务器的朋友经常会遇到CPU 跑满，很多人的做法是重启。重启能让监控暂时变绿，问题多半会在下一次流量上来时重演。先看清是哪个进程在吃 CPU、吃的是用户态还是内核态，再决定杀进程、加配置还是改代码。

先分清是哪种"满"

top 输出里，%us、%sy、%wa 三个值要一起看。us 高，说明应用在算，常见于死循环、慢查询、压缩加密；sy 高，说明内核在忙，多半是系统调用频繁、网络包处理或上下文切换；wa 高，CPU 其实不忙，是在等磁盘或网络，load average 会很高，CPU 还有空闲。三者混在一起看，定位方向完全不同。

还有个容易忽略的对照：load average 除以核数。4 核机器 load 到 8，说明排队已经翻倍；32 核机器 load 到 8，只是正常波动。别只看百分比，不看核数。

五个常见"元凶"

一、挖矿木马或入侵进程

特征是 CPU 长期贴着 90% 以上，业务却没什么流量。进程名常伪装成 kworker、dbus、sshd 之类，路径却在 /tmp、/dev/shm 或用户目录。查 /proc/<pid>/exe 的真实指向，再看 crontab 有没有陌生任务。这种情况 kill 掉通常几分钟又起来，得先断外网、清定时任务、改密码，必要时重装。

二、数据库慢查询

mysqld 占用高，QPS 却不高，多半是某条 SQL 在扫全表。开慢查询日志，看执行时间和扫描行数，缺索引的补索引，一次性拉全表的改成分批。慢查询不解决，加核数只是让全表扫得更快。

三、Web 应用进程打满

php-fpm 子进程数量失控，或者 Java 频繁 Full GC、线程死循环，都会把 us 拉高。top -Hp <pid> 看线程，jstack 抓栈，php-fpm 看 pm.max_children 和慢日志。进程数开太大，内存先崩；开太小，请求排队。这个值要按内存和单请求耗时算，不是越大越好。

四、备份、压缩和日志轮转

tar、gzip、logrotate 这类任务平时不显眼，一旦和业务高峰撞上，CPU 立刻被吃掉。cron 里几个任务都排在凌晨 2 点，机器同时压缩十几个 GB 日志，白天正常、夜里告警，就是这种。错峰、限速（nice、ionice）、只压增量，能缓解大半。

五、采集、爬虫和同步脚本

Python 爬虫、rsync、wget 这类脚本，单次跑不重，怕的是没加锁。上一个实例没跑完，下一个又起来，进程越叠越多。查 ps 的父子关系和启动时间，给脚本加文件锁或 flock，限制并发数，问题基本能压住。

定位到具体线程和文件

top 找到 PID 后，top -Hp <pid> 看是哪个线程在跑；ps -ef --forest 看父子进程，判断是不是被别的脚本拉起来的；ls -l /proc/<pid>/exe 看可执行文件的真实路径，专治伪装；crontab -l 和 /etc/cron.d 查定时任务；iostat -x 1 看磁盘是否拖后腿。几步下来，元凶基本能锁定。

处置顺序 

业务正在受影响，先限流、降级、重启单个进程，把服务拉回来；确认是挖矿或入侵，先断外网再处置，别只 kill；慢查询先加索引或限流，再改 SQL；定时任务先错峰加锁，再考虑换机器。整机重启放在兜底，不要当成常规动作。

平时怎么防

给 CPU、load、进程 TOP 配监控和告警，知道自己的正常水位；root 登录关掉，改用密钥，定期查 crontab 和 /tmp 下的可执行文件；重要数据做快照。机器是租的，排查思路是自己的，这套基线建起来，下次再满能省很多时间。

选机器时留一点余量

CPU 长期跑到 70% 以上，说明这台机器已经没什么余量，一次活动或一个慢查询就能打满。选 服务器租用 时按峰值留出三成余量，比事后扩容省事。托管客户可以让 服务器托管 的 机房 开带外管理和监控，了解更多详情咨询我们，为您提供更多的解决方案。