服务器CPU占用高怎么排查?四步定位,动手前先确认归属

CPU占用高先别急着kill。按四步排查:对照负载与核数,分清持续还是瞬时、计算忙还是等IO;找到占用进程;判断成因类型;确认归属并留好日志后再处置,关键操作由人工确认。

要点速览

• 先用uptime对照CPU核数,分清负载是持续高还是瞬时高
• wa高说明在等磁盘IO,st高要找宿主机,不要只盯应用
• 占用进程分为业务、系统、来历不明三类,分别找对应的负责人
• kill、重启、改配置前,先确认归属、留存日志、准备好回退
• 托管服务器时,系统内排查通常归客户,签约前问清远程协助范围

服务器CPU占用高,排查顺序是先定性、再定位、后处置,不要一看到百分比高就去结束进程。可以按四步走:一看负载是持续高还是瞬时高,对照CPU核数判断机器是在计算,还是在等磁盘IO;二找占用进程,把它归到业务进程、系统进程或来历不明的进程;三判断成因属于应用问题、定时任务堆积、IO或换页拖累,还是疑似异常进程;四确认进程归属、能否重启、日志是否已经保存、出问题时怎么回退,再由有权限的人动手。下面每一步都按“看什么命令、读什么结果、什么情况停下来问人”展开。

步骤一:先分清持续高还是瞬时高,是在算还是在等

CPU曲线偶尔冲高再回落,通常是正常的业务波动,比如批处理、备份或流量高峰。值得排查的是持续偏高、伴随响应变慢或请求超时的情况。如果机器已经忙到远程登录都很吃力,可以先参照服务器SSH连不上的四段定位,确认是网络问题还是主机本身过载。

看什么

• uptime:输出三个平均负载值,分别对应1分钟、5分钟、15分钟。
• nproc:查看逻辑CPU核数,负载要和它对照着看。
• vmstat 1 5:每秒输出一次、共五次,重点看r、b、wa、si、so几列。
• top:顶部那一行CPU状态里的us、sy、wa、st。

读什么

• 三个负载值从左到右依次升高,说明压力正在上来;依次下降,说明高峰正在过去,可以先观察。
• 负载长时间明显高于核数,说明排队的任务多于可用的CPU。
• us高,一般是用户态程序在计算;sy高,往往和频繁的系统调用、大量小IO或网络中断有关。
• wa高、vmstat里b列不为零,说明进程在等磁盘。这时候CPU本身未必在忙,负载高是被IO拖出来的。
• 在虚拟机上,st偏高表示宿主机把资源分给了别人,问题不在你的系统内部。

什么情况停下来问人

负载高但us、sy都不高,wa或st却很突出时,不要急着在应用层找原因。前者要转向磁盘排查,后者需要联系虚拟化平台或云资源的负责人。

步骤二:找到占用进程,分成三类

定性之后,再把具体是谁在占找出来。

看什么

• top:按大写P以CPU排序,观察排在前面的几个进程是否稳定不变。
• ps -eo pid,ppid,user,%cpu,%mem,etime,cmd --sort=-%cpu | head:输出一份可以保存、可以对比的快照,其中etime能看出进程已经运行了多久。
• top -H -p 进程号:查看进程内部哪个线程在占用。Java程序可以把线程号换算成十六进制,再到jstack的输出里找到对应的调用栈。

读什么

1. 业务进程:属于应用账号、命令行里能看出服务名,比如Web服务、数据库、Java应用。这类进程要找业务负责人,不能自行处理。
2. 系统进程:名称用方括号括起来的内核线程,或者systemd、sshd一类系统服务。kswapd一类线程占用偏高,通常说明内存不够,系统在频繁换页。
3. 来历不明的进程:名称看起来像随机字符,或者模仿系统进程,却运行在临时目录下。可以用ls -l /proc/进程号/exe查看真实路径,再用cat /proc/进程号/cmdline查看完整启动参数。路径指向/tmp、/dev/shm,或者显示为已删除,都需要警惕。

什么情况停下来问人

找不到进程归属,或者进程属于你没有权限管理的账号时,先记录下来,不要动它。

步骤三:判断成因属于哪一类

同样是CPU高,成因不同,处置方式也完全不同。常见的有四类:

• 应用死循环或并发突增:单个业务进程长时间占满一个或几个核,线程栈反复停在同一段代码上,多半是程序问题;如果是访问量上涨导致的,应用日志和访问日志里会看到请求数明显增加。前者需要开发介入修复,后者要评估限流或扩容。
• 定时任务堆积:ps里出现大量同名进程,启动时间呈固定间隔。原因通常是上一轮任务没跑完,下一轮又被启动。可以用crontab -l和/etc/cron.d下的配置核对执行周期,再确认脚本有没有防重入的机制。
• 磁盘IO或内存换页引起:wa高、si和so持续不为零,free -h显示可用内存很少、交换分区正在被使用。这时候应该去查内存是谁占的、磁盘是谁在读写。iostat -x 1可以看各块磁盘的繁忙程度,这个命令需要安装sysstat工具包。如果磁盘空间也已经告急,可以参照服务器磁盘满了的四步定位一并处理。
• 疑似异常进程:来历不明、CPU长期满载、还有对外连接。可以用ss -tnp查看它连向哪里,再检查crontab、systemd服务和开机启动项里有没有被写入拉起它的配置。

什么情况停下来问人

只要判断为疑似异常进程,就转交安全负责人,不要自行结束。直接kill掉,往往还会被定时任务重新拉起来,而且会把排查需要的现场一起抹掉。涉及等保 2.0 要求的系统,还要按单位内部流程留存记录、上报事件。

步骤四:动手前确认归属、留证据、备回退

到了这一步,才开始讨论要不要动。kill进程、重启服务、修改配置都属于会影响业务的操作,建议逐项过一遍下面这份清单:

1. 归属:这个进程属于哪个业务、哪个负责人,对方是否知情并且同意处置。
2. 影响:当前是不是业务高峰,有没有主备或负载均衡可以先切走流量,重启需要多长时间。
3. 留证据:先执行top -b -n 1把输出保存成文件,再保存ps快照、线程栈、journalctl和应用日志的相关片段。重启之后,这些现场就没有了。
4. 由轻到重:能调低优先级(renice)的,先不结束进程;要结束的,先用kill -15让程序正常退出,确认无效后再考虑kill -9。
5. 回退:修改配置前备份原文件,写清楚改了哪一行、怎么改回去;处置完成后继续观察一段时间,确认负载回落、业务正常。

这五项里只要有一项答不上来,就先停下来问清楚。凌晨时段排障尤其容易因为着急而跳过“留证据”这一项。

在终端里让AI帮忙解读,执行仍由人确认

上面的流程里,真正耗时的往往不是敲命令,而是读懂输出:vmstat的十几列各代表什么,线程栈要怎么对应到代码,crontab里的周期写法是否会造成重叠。润迅的终端AI运维工具MaxTerm,适合放在这个环节使用。它支持macOS和Windows,个人可以免费使用,能在终端里辅助解读命令输出、标记可疑的进程和配置、起草下一步要执行的命令。

需要说清楚的是分工:AI负责整理信息、做初步判断和风险提示,是否执行kill、是否重启服务、是否修改配置,仍然由运维人员看过命令内容后确认。这和步骤四的清单是一致的,工具让人读得更快,并不替人做决定。

托管服务器时,CPU排查归谁负责

如果服务器放在IDC机房托管,责任一般这样划分:机房提供电力、制冷、网络,以及到场协助,比如重启电源、查看指示灯、插拔线缆;操作系统内部的CPU排查,通常由客户自己或其运维团队负责。润迅在深圳运营前海云与田心两座数据中心,提供机柜托管、网络带宽和配套的现场服务,也是按这样的边界和客户分工。

建议在签约前把这些问题问清楚:远程协助包括哪些操作,是否需要客户授权,响应流程怎么走,哪些操作要另外收费。服务器托管和其他资源形式在责任上的差别,可以参考服务器托管和机柜租用、云服务器、自建机房怎么区分。

行动建议

• 把四步流程整理成一页排障卡,标明每一步要执行的命令和需要停下来的条件,放进值班手册。
• 平时定期保存负载基线和进程快照,出现异常时才有可以对照的参照。
• 给kill、重启、改配置这三类操作设置审批人,AI工具起草的命令同样要经过确认才能执行。
• 正在选托管机房的团队,先把硬件、网络和系统内运维的责任边界写进合同,可以对照机柜托管与服务器托管的四项区别确定合适的方式,也可以拨打润迅业务热线400-854-5566咨询。

→ 联系润迅,聊聊你的场景,获取适合的方案