服务器cpu占用过高是什么原因，如何排查与解决？

服务器CPU占用过高，绝大多数情况下不是硬件老化，而是业务层代码逻辑问题、数据库慢查询、恶意攻击或异常进程这四类原因中的一种在作祟。下文按排查顺序拆解根因和对应解法。

拿到一台CPU跑满的服务器，先别急着重启

重启确实能短暂清零负载,但如果不定位根因，业务一上线又会打满，按下面顺序来，十分钟内能圈定大致方向。

第一步：用top命令锁定肇事进程

登录服务器后直接执行：

top -c

按下大写 P 让进程按CPU使用率排序，重点看最上面三行，如果某个进程的CPU占用长期稳定在 90%以上，且进程名很陌生，比如一串随机字符或者kworker变体，那大概率是中招了，如果进程名是php-fpm、java、python这类常见服务，说明是应用自身的问题。

进一步确认进程身份：

ls -l /proc/进程PID/exe
cat /proc/进程PID/cmdline | tr '' ' '

这两条命令能查到可执行文件路径和完整启动命令,路径在/tmp、/var/tmp、/dev/shm下，基本可以断定是挖矿木马或恶意脚本。

第二步：判断是用户态还是内核态消耗

在top界面按 1 查看每个核心的使用率，再观察us(用户态)和sy(内核态)两个指标：

• us占比极高：业务代码或恶意程序在跑计算，问题出在应用层。
• sy占比极高：内核模块、系统调用或驱动出现异常，排查难度更大。
• wa占比高：CPU在等磁盘I/O，不是真正被算力耗尽，而是存储拖后腿。

服务器cpu占用过高100%怎么排查：从代码到数据库的顺藤摸瓜

如果top命令确认是自家应用进程,按下面三个层面逐个击破，这也是服务器cpu占用过高100%怎么排查的标准路径。

业务代码层的死循环与全表扫描

编程语言里的while(true)写错退出条件，或正则表达式发生灾难性回溯，都会让单个请求的CPU消耗飙升，这类问题特征明显：并发量不大，但CPU早早就满了。

针对PHP项目,用strace -p 进程PID跟踪系统调用；针对Java项目，执行jstack 进程PID抓线程快照，多抓几次对比哪几个线程一直卡在同一处。

数据库慢查询：CPU被SQL语句拖垮

数据库是CPU消耗大户,登录MySQL执行：

SHOW FULL PROCESSLIST;

观察Time列，找出执行时间从几秒到几十秒的语句，再执行EXPLAIN看执行计划，出现type=ALL表示全表扫描，rows扫描行数过十万级别，这条SQL就是罪魁祸首，常见的解法是给WHERE条件字段加索引。但更隐蔽的问题是索引失效，比如对索引列使用了函数运算或隐式类型转换，这类查询即使加了索引也白搭。

低频请求高消耗：PHP-FPM配置失当

如果业务代码和数据库都正常,回头看PHP-FPM的进程管理模式。pm.max_children设置过大，服务器空闲时也会预生成大量进程，每个PHP进程默认占用 30-50MB 内存，进程太多直接耗尽内存，触发OOM Killer后CPU又忙着换进换出。

行业共识认为,pm.max_children的合理值应该根据单进程平均内存占用和服务器总内存反推，保留 20% 内存余量给系统缓存。

服务器cpu占用过高和带宽爆了，这俩经常被搞混

很多站长遇到网站打开卡顿,第一反应就是CPU又满了，实际上有一种情况是带宽先被打满，数据包在队列里堆积，应用层不断重试，最终CPU被连带拖垮，想区分这两者，看两个指标就够了：

• iftop命令观察实时带宽流量，如果持续跑满上行或下行，是带宽瓶颈。
• 同时看CPU的wa指标，带宽拥塞通常伴随大量网络中断，si（软中断）会明显升高。

流量攻击下的CPU表现

CC攻击的特征是并发连接数暴增，但单请求消耗不大，此时ss -s能看到大量TIME_WAIT状态的连接，Nginx的access.log里同一IP在短时间内出现大量请求记录，这类攻击不会直接写满CPU计算单元，而是让进程上下文切换频繁，总体占用被推高。

处理方案分两步走：

• 临时屏蔽：iptables -A INPUT -s 攻击IP -j DROP，先止血。
• 永久防护：接入高防CDN或云厂商的DDoS防护，在入口层过滤恶意流量。

按业务场景定位常见隐患

不同技术栈的CPU占用过高,排查方向差异很大，下面按几个高频场景说说。

LNMP环境（Linux+Nginx+MySQL+PHP）

这类环境下的CPU飙升,按概率排序是：

MySQL慢查询 > PHP-FPM进程数超配 > 第三方接口阻塞，建议先打开MySQL的慢查询日志：

slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2

然后运行一段时间,重点看慢查询里有没有高频出现的SQL模板。

Java应用（Spring Boot/Spring Cloud）

Java应用CPU飙高且伴随着GC日志里频繁出现Full GC，属于典型的内存泄漏导致GC线程空转，此时用jstat -gcutil 进程PID 1000观察GC频率，如果FGC列的数字持续增长，就用jmap -dump生成堆转储文件，配合MAT工具分析大对象引用链。

Windows Server上的IIS站点

Windows服务器的排查命令不同,调出任务管理器后，按CPU排序查看w3wp.exe进程，如果这个进程占用高，进入IIS管理器查看应用程序池的回收设置，将固定时间间隔回收改为内存超限回收模式，能有效避免单个进程长期运行导致的句柄泄漏。

服务器cpu占用过高 简米云 酷番云 轻量服务器，有通用的处置清单

不管用的是哪家云服务商,也不管是突发型实例还是内存型实例，下面这份排查清单都适用，适合整理成文档贴在工位旁边：

• 用top -c和ps aux --sort=-%cpu交叉验证进程身份。
• 检查/var/log/messages或dmesg输出，看有无OOM或硬件报错。
• 用vmstat 1观察r列（运行队列），数值长期超过CPU核心数的数倍，说明负载确实超标。
• 查crontab -l和/etc/cron.d/，看有没有被植入定时拉取恶意脚本的任务。
• 检查/etc/ld.so.preload文件，该文件被篡改是Rootkit常见手法。

轻量应用服务器的特别注意事项

轻量服务器CPU规格较小,通常只有1-2个核心，性能基线远低于同价位的云服务器ECS，如果业务是WordPress或Discuz这类PHP程序，数据库和Web服务挤在同一台机器上，CPU御三家的表现差异明显，这类场景下，将MySQL单独迁出到更高配实例，或启用Redis缓存热点数据，成本远低于硬扛CPU升级。

费用层面的考量

如果是持续性的CPU高位运行,临时扩容或升级配置是治标之策，云厂商按量付费的CPU实例价格高于包年包月，长期跑满建议直接调整实例规格，而不是频繁使用突发性能实例，突发型实例的CPU积分耗尽后性能会被强制拉低，看起来像故障，实际上是资源配额用完了。

一次真实的排查过程：从发现到解决

描述一个典型场景：某天下午网站突然卡顿，top看到多个php-fpm进程CPU占用各在30%左右，用SHOW FULL PROCESSLIST发现大量SELECT FROM orders WHERE status = 1在执行。

这个查询看起来简单,但orders表已经有上百万条数据，且status字段没有索引，执行EXPLAIN确认type=ALL后，给status字段加了一个普通索引，CPU占用随即降到5%以内，后续的优化是改业务代码，将这类统计查询挪到离线任务中执行，避免线上实时跑大表扫描。

常见问题解答

服务器cpu占用过高但是网站访问正常，需要处理吗？

需要处理,但不必慌张，短暂飙升后回落属于正常波动，比如定时任务执行、日志切割，核心指标是持续15分钟以上的占用率超过 80%，且伴随响应变慢，处理方式是先抓取当前占用最高的进程快照，留存现场，再决定是优化代码还是扩容。

CPU占用率显示100%，但找不到具体高占用进程，怎么回事？

这种情况多半是进程反复重启，每次top刷新前旧进程已被kill，新进程刚起来还没排到前列，用pidstat -p ALL持续观察，或者查看系统日志中被OOM Kill的进程记录，还有一种可能是CPU占用被分摊到大量进程上，每个进程只占几个百分点，用top -H查看线程级消耗可以暴露问题。

云服务器CPU占用过高会影响GEO排名吗？

会间接影响,页面响应时间超过 2秒，搜索引擎爬虫的抓取频次会下降，导致收录变慢，CPU打满后服务直接超时，爬虫拿到5xx状态码，更会降低站点质量评分，从这个角度看，服务器稳定性是GEO的基础工程，重要性不亚于内容和外链。

服务器CPU占用过高的本质是资源与需求不匹配，要么需求端出了问题（代码低效、恶意流量），要么供给端没有跟上（配置过小、架构不合理），把上面列的排查顺序走一遍，绝大多数场景能在一个工单周期内解决，养成日常用top和slow_log记录基线的习惯，下次故障发生时，对比数据比拍脑袋猜原因快得多。