Linux 服务器被占满 CPU 之后，第一时间该怎么排查

CPU 飙高时，先判断是瞬时波动还是持续异常

Linux 服务器 CPU 被占满之后，最怕的是一上来就重启服务或者杀进程。因为 CPU 高占用有时只是短暂尖峰，例如批处理任务、缓存预热、索引更新或访问高峰造成；但也可能是代码死循环、数据库查询异常、爬虫冲击、恶意程序甚至系统级故障引起。排查时第一步应该先区分这是瞬时波动还是持续异常，只有先看清持续时间和影响范围，后面动作才不会过激。

先找出哪个进程在吃 CPU，再谈处理

高 CPU 问题最核心的切入点，是先确定是谁在消耗资源。是 Web 服务、数据库、某个脚本任务，还是系统进程本身？不同类型的进程意味着完全不同的处置方式。比如应用进程异常，可能要看代码逻辑和请求来源；数据库占用高，可能要看慢查询和索引；系统进程异常，则要继续排查内核、驱动或底层组件。先定位对象，才可能找到正确方向。

负载、日志和请求来源要结合着看

只盯着 CPU 数值本身，往往还不够。很多时候真正有价值的，是把系统负载、应用日志、访问日志和任务计划一起串起来看。比如 CPU 飙高是不是总发生在某个整点、是否伴随某类请求暴增、有没有异常脚本在同一时间启动、错误日志里是否出现大量重试或超时。高 CPU 本身只是结果，把相关线索组合起来，才能更快接近原因。

别忘了排除资源配置与业务变化因素

有些 CPU 高占用问题，不一定是“系统坏了”，而可能只是业务规模变了。访问量上来之后，原有规格不再够用；新增了定时任务，却没有重新评估资源；或者某个版本更新后单次请求的计算量明显增加。这类情况如果只靠排障思路，很容易来回修修补补。把资源配置、业务变化和程序行为一起纳入判断，才能决定是优化程序、拆分服务，还是直接扩容更合适。

稳定排查比盲目止血更有价值

Linux 服务器 CPU 高占用确实可能影响业务，但越是这个时候，越要避免“先重启再说”的惯性。重启虽然有时能暂时恢复，却也会抹掉很多重要现场。更稳的做法，是尽量先保留关键指标和日志，再做必要的限流、熔断或服务调整。真正成熟的运维，不只是把 CPU 降下来，而是让类似问题下次来时更快被识别、更容易被解释，也更容易被提前避免。