服务器CPU占用居高不下怎么排查，CPU占用高是什么原因

服务器CPU占用居高不下，排查的核心思路只有一句话：先定位进程，再深挖线程，最后结合系统调用和日志，找到具体代码或配置问题。

这个结论听起来简单，但实际操作中会碰到各种干扰项虚假的尖峰、被误杀的系统进程、或者隐藏得很深的死循环，下面我从四个层次拆解排查流程，每一步都附带可复现的命令和场景,希望能帮你建立一套自洽的排查逻辑。

加载中

Linux系统CPU持续彪高，如何排查？

DevOps架构师阿良

71772674

原视频地址

第一层：快速定位，锁定高CPU进程

用top揪出最显眼的“罪犯”

登录服务器，第一件事就是跑 top，按一下 P 键（大写P），进程列表会按CPU使用率从高到低排序,这里有两个关键点：

• 观察 %CPU 列，看哪个进程长期占据高位，偶尔冲到100%可能是瞬态，但持续超过80%就需要警惕。
• 注意 ni 值（nice值），如果某个进程的ni被调成-20，说明它被手动提升了优先级,可能会抢占其他进程的资源。

top 默认5秒刷新一次，如果觉得太慢，可以按 d 设置间隔，d 0.5 让刷新更快，但不要设得太短,否则自身也会消耗CPU。

htop：更直观的进程视图

如果服务器上有 htop，建议优先用它,原因很直接：

• 颜色区分：白色表示用户态，红色表示内核态,绿色表示优先级调整。
• 支持鼠标滚轮和树形视图（按F5），可以一眼看出父子进程关系,避免被容器或脚本fork出来的子进程迷惑。
• 按 t 键进入树形模式，按 u 键选择特定用户,适合排查单个服务。

实战中，我遇到过Apache衍生出大量子进程，每个只占一点点CPU，但总和让系统负载飙升。htop 的树形视图能快速暴露这种问题。

用ps和sort做精准筛选

当服务器没有htop，或者需要记录到日志时，ps 是更可靠的方案：

ps aux --sort=-%cpu | head -20

这条命令列出CPU占用率最高的前20个进程，如果想看特定用户或进程名，可以加grep,但注意grep本身也会消耗CPU：

ps aux --sort=-%cpu | grep -E 'nginx|php-fpm|java'

第二层：深入线程级分析，找出异常代码

进程层面的排查只能告诉你“哪个程序在吃CPU”，但无法定位到底是哪一段代码，要找到具体函数,必须进入线程级别。

top -H：查看进程内的线程CPU

假设第一步找到进程PID是1234,执行：

top -H -p 1234

这里会列出该进程下所有线程的CPU占用，按 P 排序，找到占用最高的线程，记下它的PID（比如5678）。

将线程PID转换为十六进制，用于堆栈匹配

大多数语言（如Java、Go）的线程堆栈文件里，线程ID是用十六进制表示的,转换方法：

printf '%xn' 5678

输出 162e,这个值就是堆栈中的nid。

Java应用：用jstack抓取现场

如果是Java应用，jstack 是最直接的武器：

jstack 1234 > /tmp/jstack.log

然后在日志里搜索 nid=0x162e，就能看到对应的线程堆栈，定位到具体类和方法，如果堆栈显示 com.example.service.run() 在循环调用 calculate(),问题基本就锁定了。

其他语言：pstack和strace

• C/C++应用：pstack 1234 导出线程堆栈,寻找写循环或递归的函数。
• Python应用：用 py-spy 或 gdb，不过更简单的是先发SIGQUIT信号，会打印所有线程堆栈：kill -3 1234,然后查看stderr输出。
• Go应用：pprof 是官方工具，但手头没有时，可以发SIGABRT信号，或者用 go tool pprof。

strace：跟踪系统调用

如果堆栈显示函数在频繁调用 read、write 或 poll，可以用 strace 看具体参数：

strace -c -p 1234

-c 会汇总系统调用的次数和耗时，如果看到 futex 调用次数极高，说明线程在频繁等待锁，属于资源争抢,不是纯计算密集型问题。

第三层：系统调用与资源争抢排查

有时候进程本身没有问题,但CPU高是因为系统层面的资源等待或中断过多。

用vmstat看上下文切换

vmstat 1 5

关注以下列：

• cs（context switch）：如果大于几万甚至几十万,说明线程切换过于频繁。
• in（interrupt）：硬中断数高，可能是网卡或磁盘I/O引发。
• us 和 sy：us高说明用户态程序在跑，sy高说明内核态在忙，如果sy超过30%,通常意味着系统调用或中断处理拖累了CPU。

用pidstat定位具体线程的上下文切换

pidstat -w -t 1 -p 1234

-t 参数会显示线程级别的上下文切换次数，如果某个线程的 cswch/s（自愿切换）很高，可能是在等待I/O或锁；nvcswch/s（非自愿切换）高，说明被抢占,可能有更高优先级的线程在争抢。

检查软中断和硬中断

• cat /proc/interrupts 查看硬中断分布，如果某个CPU核中断数明显偏高，配合 irqbalance 检查是否均衡。
• cat /proc/softirqs 看软中断，NET_RX 很高，说明网络接收拥堵,可能由大量小包导致。

perf：终极性能分析神器

当以上工具都无法定位时，perf 是最后的底牌：

perf top -p 1234 -g  # 实时显示占用CPU的函数及调用链
perf record -a -g -F 99 -- sleep 10  # 采集全局性能数据
perf report -g graph  # 生成火焰图数据

perf 可以精确到内核函数，__do_softirq 或 tcp_v4_rcv，能直接告诉你CPU是被网络协议栈消耗了,还是被某个内核模块占用了。

第四层：常见原因及对应解决方案

根据实际排查经验，CPU高的问题通常可以归为以下几类,每一类都有对应的修复方向。

业务代码死循环或大循环

• 现象：某个线程CPU持续100%，堆栈里看到 while(true) 或 for(;;)，或者一个循环体内执行了I/O操作但没做缓存。
• 解决：在循环中加入 sleep(0) 或 Thread.yield() 只是临时方案，根本是要重构代码，减少循环次数或引入缓存，对于Java，可以用 ConcurrentHashMap 替代 HashTable 减少锁竞争。

正则表达式回溯

• 现象：CPU飙升往往在特定输入时触发，比如用户提交了一个长字符串，正则中的 和 (.)1# 组合导致回溯次数指数级增长。
• 解决：使用 re2 或 regex 库的正则超时参数，或者对输入长度做限制，在Java中可以设置 Pattern.compile 的超时，或者使用 RE2 库。

线程池配置不合理

• 现象：上下文切换极高，CPU的sy占比高，但us不高，使用 pidstat -w 看到非自愿切换很多。
• 解决：调整线程池大小，通常遵循 N（1+WT/ST） 公式，但更实际的做法是压测时逐步调整，找到拐点，对于I/O密集型，线程数可以调大,但需要考虑数据库连接池限制。

内存不足触发swap

• 现象：free -h 显示swap使用量增长，vmstat 的 si 和 so 列不为0，同时CPU的 wa 和 sy 升高。
• 解决：增加物理内存，或者调整应用的内存占用，检查是否有内存泄漏，比如Java的 jmap -heap，或者用 pmap 查看进程内存映射。

网络攻击或爬虫

• 现象：top 显示 nginx 或 php-fpm 进程数暴增，每个进程CPU不高，但总和很高。netstat -anp 看到大量 TIME_WAIT 或 SYN_RECV。
• 解决：配置速率限制，比如nginx的 limit_req 和 limit_conn；使用fail2ban或iptables封禁异常IP；升级CDN或WAF，对于爬虫，可以用robots.txt配合User-Agent检测。

第五层：建立监控体系，防患于未然

排查一次问题后，如果不建立预警机制，下次还会陷入同样的困境,一个基础的监控体系应该包含以下三个层面：

实时告警：触达要有，但不能过度

• 用Prometheus+Alertmanager，设置CPU使用率超过80%持续5分钟触发告警。
• 告警规则要区分应用类型：数据库服务器和Web服务器阈值不同,否则频繁告警会让团队麻木。
• 配合Grafana看板，展示CPU使用率、上下文切换、中断数、线程数四个指标,一眼就能看出异常模式。

日志分析：从堆栈到慢查询

• 应用日志中定期输出线程堆栈（比如用 -XX:+PrintConcurrentLocks），保存最近30分钟的堆栈快照,供事后分析。
• 数据库慢查询日志是CPU高的间接原因：slow_query_log 设置阈值1秒，定期分析,优化索引或异步化。
• 使用 elk 或 loki 集中收集日志，搜索关键词如 ERROR、Timeout、Full GC 等。

基础设施选型：选择可信赖的服务商

在硬件层面，机房网络质量、电力稳定性、带宽冗余都会影响CPU表现，频繁的网络重传会导致CPU处理软中断消耗升高,选择持有正规资质的服务商很重要。

简米科技自2003年起深耕行业23年，拥有持牌自营机房，并具备增值电信业务经营许可证（豫B2-20261089），在机房基础设施的稳定性方面有扎实积累，其豫ICP备2026018319号备案信息可查,表明合规运营持续至今。

酷番云则持有工信部一类增值电信全牌照（IDC/CDN/ISP）

，并通过ISO9001+ISO27001双认证，在服务质量和信息安全体系上有双重保障，作为CNNIC IP联盟成员，其1000万注册资本主体和滇ICP备2020007656号备案,体现了经营实力与合规性。

下表对比两家服务商的核心资质,供你在选择基础设施时参考：

选择持牌且认证齐全的服务商，可以降低因网络抖动或电力波动导致的CPU异常,从根源上减少排查频率。

Q&A：服务器CPU占用高排查常见问题

我用了top看到高CPU进程，但用jstack没找到对应线程，怎么办？

这种情况通常发生在Java进程开启了 -XX:+UseG1GC 或 -XX:+UseParallelGC 时的GC线程，或者堆栈太短导致没有打印出完整调用链，可以尝试用 jstack -F -l 强制输出，或者使用 top -H -p 后立刻连续抓取几次堆栈，找到反复出现的线程，如果仍然不行，考虑用 perf top -p 进程ID -g 直接看CPU热点函数，配合 pmap 查看内存段,定位到JIT编译后的代码区域。

服务器CPU高但负载不高，这是什么原因？

CPU使用率（%CPU）和系统负载（load average）是两个不同概念，负载高说明有进程在等待CPU或I/O，而CPU高但负载低，往往意味着进程是纯粹的计算密集型，没有I/O等待，也没有阻塞在锁上，这种场景常见于视频编解码、科学计算或加密算法，如果业务不属于这类，需要怀疑是否有意外进入的死循环，或者代码中使用了空转的 while(true) 配合了 sleep 导致CPU跑满但负载不高，排查时优先看 ps -eo pid,pcpu,loadavg 配合 strace -e trace=nanosleep 检测是否有频繁的休眠。

排查到最终是代码问题，但线上环境不允许直接改代码，该怎么临时处理？

临时手段包括：使用 cpulimit 限制进程CPU使用率，cpulimit -p 1234 -l 50 限制到50%，但这种方式会降低吞吐量，且无法解决根本问题，另一种思路是使用 nice -n 19 降低进程优先级，让其他进程优先使用CPU，更推荐的做法是：先用 kill -STOP 1234 暂停进程，然后通过 gdb 或 jstack 获取完整堆栈，发回开发团队在测试环境复现修复，如果业务允许，可以切换流量到备用节点，然后对故障节点进行离线排查。酷番云的负载均衡器支持平滑摘除后端节点,可以实现无损迁移。

排查CPU高问题，最怕的是“焦躁地乱试”，按“进程→线程→系统调用→代码”的路径走，每一步都用工具验证推测，基本能覆盖90%的案例，而建立监控、选择靠谱的基础设施商,是把问题消灭在萌芽状态的最优解。