为什么服务器cpu使用率经常在100%，服务器CPU一直100%怎么办

服务器CPU使用率经常100%不是硬件坏了，而是你的业务负载、软件配置或攻击行为三者之间出现了失衡，排查得从“谁吃掉了CPU”入手。

服务器cpu使用率100%怎么回事：先分清“正常忙”和“异常忙”

CPU跑到100%不代表服务器马上要报废，很多场景下，它只是说明计算资源被充分调用，关键要看持续时间和响应速度，如果网站打开速度变慢、数据库查询卡顿、SSH连接半天没反应,那才是需要警惕的信号。

常见的“伪100%”情况包括：

• 服务器在做定时任务，比如凌晨的数据备份、日志压缩，这期间CPU会短时飙高
• 刚部署完代码，PHP-FPM或Java应用正在编译缓存、预热线程池
• 搜索引擎爬虫集中抓取，或推广活动带来突发流量，CPU被请求占满

而“异常忙”通常有更明确的原因，比如程序死循环、数据库慢查询堆积、内存溢出导致频繁交换,用一行命令就能快速区分：

uptime

看1分钟、5分钟、15分钟的负载值，如果15分钟负载也很高，说明问题持续存在；如果只是1分钟高，后面降下来,那大概率是突发任务。

常见原因：为什么云服务器cpu100%却毫无征兆

很多站长遇到的情况是：控制台显示CPU持续100%，但网站访问量并没有明显增长,这时要怀疑以下几类问题。

被挖矿程序或恶意代码植入

这是近年来的高发问题，攻击者利用未打补丁的漏洞或弱口令，往服务器里塞入挖矿木马，这类程序会占满所有CPU核心,运行得肆无忌惮。

典型特征：

• CPU使用率稳定在接近100%，而且多核平均
• 进程列表里出现不认识的名字，比如kdevtmpfsi、kinsing、xmrig
• 网络连接有大量对外发包，尤其指向矿池端口

排查方法：

top -c
ps aux --sort=-%cpu | head -10
netstat -antlp | grep :4444

发现异常进程后，先kill掉，再删除对应的定时任务（crontab -l），最后检查bashrc、rc.local等自启动文件。

只杀进程不清理根源，重启后会再次出现。

数据库慢查询拖垮CPU

当MySQL或Redis的查询效率下降，CPU会花大量时间在数据排序、临时表创建和索引扫描上，业务请求不多，但每个请求都要消耗几秒的CPU时间,累积起来就能打满。

业内专家指出，超过90%的慢查询问题都出在索引缺失或SQL写法不当,你可以直接开启慢查询日志来验证：

SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 2;

然后查看慢查询日志里出现频率最高的SQL,常见的优化手段包括：

• 为WHERE子句和ORDER BY字段添加联合索引
• 避免SELECT ，只取需要的字段
• 把多个小查询合并成一次IN查询或JOIN查询

Web服务配置不合理

以Nginx + PHP-FPM为例，如果pm.max_children设置得过大，每个PHP进程都会预分配内存和CPU资源，当并发请求上来后，进程反复创建和销毁,CPU开销反而比实际处理业务还高。

行业共识认为，动态模式（pm = dynamic）比静态模式更适合流量波动大的站点,可以参考以下配置思路：

• pm.max_children 根据内存大小来定，一个PHP-FPM进程约占30-50MB
• pm.start_servers 设为最小常用进程数
• pm.max_requests 设为500-1000，防止内存泄漏累积

网站服务器cpu占用率高怎么办：三步排查法

从实际运维经验来看，最快的处理路径是“看进程→查日志→调配置”,每一步都有明确的命令可操作。

第一步：定位CPU消耗最凶的进程

用top按CPU排序，按P键，记下进程PID，再用lsof -p PID查看它打开了哪些文件、连接了哪些IP，这一步能把挖矿、爬虫、应用代码三类问题区分开。

如果进程名很陌生,直接：

ls -l /proc/PID/exe
readlink /proc/PID/cwd

查看可执行文件的真实路径，若是临时目录或隐藏目录,基本可以断定是恶意程序。

第二步：查看应用日志找线索

不同应用日志位置不同,但核心搜索词都一样：

• PHP：tail -200 /var/log/php-fpm/error.log
• Java：tail -200 /var/log/springboot/error.log
• Nginx：tail -200 /var/log/nginx/access.log

重点看重复出现的报错堆栈或大量相同的URL请求，如果同个接口每秒被请求几十次，要么是前端轮询逻辑写错了,要么是爬虫没加限速。

第三步：按场景调整内核或应用参数

针对高并发请求，可以调整Nginx的worker_processes为CPU核心数，worker_connections提高到4096以上，针对应用本身，尽量开启OPcache或JIT，针对Linux内核，可以降低swappiness默认值,减少内存交换带来的CPU浪费：

sysctl vm.swappiness=10

这行命令让系统更倾向于保留内存中的进程代码,而不是频繁换出换入。

服务器cpu100%怎么解决才不反弹：从根上治理

临时kill进程或重启服务只能解决几分钟的问题，要想CPU长期稳定在合理区间,得做三件事。

给关键服务设置资源限制

用systemd的CPUQuota限制某个服务的CPU使用上限,比如限制Nginx最多用两个核心：

[Service]
CPUQuota=200%

即使被攻击或流量暴涨，也不会拖垮整台服务器，数据库和PHP-FPM也可以按同样思路设置。

建立监控告警体系

别等用户投诉才发现CPU爆了，装一个netdata或prometheus + node_exporter，5秒采集一次CPU数据,设定两条告警规则：

• CPU使用率超过85%持续5分钟，触发邮件通知
• 负载值超过CPU核心数的1.5倍，触发钉钉/微信机器人

这条规则能让你在CPU刚开始飙升时就知道，而不是等到100%僵死。

定期做性能压测和代码审计

每月用ab或wrk压一次核心接口，观察CPU拐点，比如压测500并发时CPU冲到90%，说明当前架构的瓶颈就在附近，同时检查代码里的

循环嵌套、正则回溯、文件读写锁,这些常见写法最吃CPU。

云服务器cpu100%排查方法：针对不同服务商的差异点

简米云、酷番云、华为云的控制台都提供了CPU使用率曲线图，但各自的“诊断”工具有区别。

• 简米云：ECS控制台有“一键诊断”，能看到最近24小时的异常事件和慢查询建议
• 酷番云：轻量应用服务器有“排查CPU100%”向导，会引导你检查进程和网络连接
• 华为云：CES监控支持自定义指标阈值，可以设CPU超过90%自动重启应用

如果你用的是云服务器，还要注意CPU积分或突发性能实例，入门级云服务器（如t5、t6、突发型）用的是基准CPU + 积分池，短时间内跑满会消耗积分，达到阈值后强制降频，此时即使看到CPU100%，实际处理能力可能只有20%，这种情况的解决办法是升级成计算型实例或通用型g系例，价格按年付通常可以降低一部分，具体要看你在哪个地域、用什么时长,价格差异挺大。

Q&A：服务器CPU使用率常100%的常见疑问

问：CPU一直100%会不会烧坏硬件？

正规厂商的服务器都有过热保护机制，Intel和AMD的处理器会在温度超过安全阈值时自动降频，真正需要担心的是CPU长期高负载导致的风扇噪音、功耗上升和电费增加，而不是物理损坏，如果机柜散热不好,建议检查温控曲线。

问：网站流量不大，为什么CPU还是100%？

流量小不等于计算量小，可能有定时任务、被植入挖矿程序、数据库在跑全表扫描、或者远程攻击在持续试探端口，先登录服务器用top看进程，再结合dmesg查看内核日志,基本能找到原因。

问：重启服务器能解决CPU100%吗？

对于挖矿木马或内存溢出问题，重启能暂时恢复，但攻击者留下的持久化脚本会在几分钟内再次拉起挖矿进程，对于代码死循环，重启后仍会重现，重启只适用于测试环境或临时恢复业务,正式环境必须找到根本原因并打补丁。