上一篇
服务器cpu百分百是什么原因，cpu占用100%怎么解决
服务器CPU达到100%，最常见的原因是应用程序代码效率低下或存在死循环，其次是流量突增、数据库慢查询、定时任务集中触发，以及生产木码等恶意程序占用。
很多运维同学半夜被CPU告警吵醒,登录服务器一看，top命令输出里%CPU那一列已经顶到100%，这时候先别急着重启，搞清楚CPU是被谁吃了，比盲目处理更重要。
服务器cpu占用率100%怎么排查？先分清是正常还是异常
排查CPU跑满,第一步不是看代码，而是看现象，执行uptime查看负载，执行top -c查看进程，再执行ps aux --sort=-%cpu | head -10列出最耗CPU的进程，如果发现某个进程的CPU使用率长期稳定在100%或接近100%，那基本可以确定它是元凶。
用top和ps命令快速定位进程
具体操作路径如下：
- 登录服务器,执行top -c，按P键按CPU使用率排序，记录下占用最高的PID。
- 执行ps -Lp [PID] -o pid,tid,pcpu,comm，查看该进程内部的线程级CPU消耗。
- 执行lsof -p [PID]，查看这个进程打开了哪些文件，往往能发现异常路径。
- 执行strace -p [PID] -c，等待几十秒后按Ctrl+C，统计系统调用耗时，判断是卡在I/O还是计算。
区分CPU高和负载高的不同含义
行业共识认为,CPU使用率反映的是计算资源的占用程度，而负载（load average）反映的是系统整体排队状况，两者有时并不同步。
| 现象 | 可能原因 | 处理方向 |
|---|---|---|
| CPU高，负载也高 | 密集计算任务，或大量进程争抢CPU | 找到进程，分析代码或任务调度 |
| CPU高，负载不高 | 单线程热点，或等待锁/IO事件 | 看线程栈，查锁竞争和系统调用 |
| CPU不高，负载高 | 大量进程处于不可中断睡眠，等待磁盘IO | 检查磁盘性能，看iostat |
如果top里看CPU高但负载不高，反而要小心，可能是单线程死循环或者锁等待，这类问题用
jstack（Java进程）或gdb（C/C++进程）看线程栈更直接。
服务器cpu跑满会导致什么后果？不只是页面变慢
CPU跑满后,最直接的影响是请求响应变慢，一个原本50毫秒的接口，可能被拖到几秒甚至几十秒，接着连锁反应开始：前端超时重试，重试请求又加剧CPU压力；数据库连接池被占满，新的查询排队；日志堆积，磁盘I/O跟着升高，严重时，云服务商的监控系统会判定实例不健康，直接触发宕机迁移或强制重启。
对于云服务器来说,CPU跑满还会带来额外的成本压力，使用突发性能型实例时，CPU积分会持续消耗，积分耗尽后实例会被限流到基准性能，导致业务雪上加霜。
业务代码死循环和内存泄漏是怎么把CPU吃满的
代码问题是CPU跑满的头号来源,常见场景包括：
- 正则表达式存在灾难性回溯,输入一段特殊字符串后，CPU算到天荒地老。
- 多线程代码里忘了加锁或条件变量,线程陷入空转。
- 大数组遍历时使用了不合理的嵌套循环,时间复杂度从O(n)变成O(n²)。
- 内存泄漏导致GC频繁触发,JVM或Node.js的垃圾回收线程把CPU吃满。
举个例子,一个Java服务在高峰期突然CPU飙升，用jstack导出线程快照，发现大量线程处于RUNNABLE状态，栈顶指向java.util.regex，基本可以断定是正则回溯问题，这类问题没有通用解法，只能改正则或加超时保护。
数据库慢查询和锁等待如何拖垮CPU
数据库也是CPU消耗大户,当一条SQL没有走索引，数据库就要全表扫描，数据量大时CPU和I/O同时飙升，更隐蔽的是锁等待：一个事务持有行锁不释放，其他事务不断重试，CPU在锁管理上疯狂空转。
排查数据库导致的CPU跑满,可以按以下步骤操作：
- 登录数据库,执行show processlist;，查看是否有大量State为Locked或Sending data的连接。
- 开启慢查询日志,找到执行时间超过1秒的SQL语句。
- 对慢SQL执行EXPLAIN，查看type字段是否为ALL（全表扫描）或rows是否过大。
- 为高频查询条件添加合适的索引,并避免在索引列上使用函数或隐式类型转换。
业内专家指出,数据库慢查询导致的CPU飙升，多数情况下可以通过索引优化解决。
服务器cpu100%是被人攻破了吗？恶意程序的识别方法
CPU被打满,确实有可能是攻破，近年来，生产木码是服务器CPU飙升最常见的恶意原因，攻破者利用漏洞植入生产程序，占用CPU计算门罗币等加密货币，导致服务器卡成幻灯片。
生产木码的常见特征
- 进程名伪装成系统服务,比如kworker、sysupdate、systemd-sleep，但路径在/tmp或/var/tmp下。
- CPU使用率接近100%，但该进程对应的业务完全未知。
- 网络连接异常,持续向境外IP发送数据，执行netstat -antlp可以看到大量长连接。
- 定时任务被改动,crontab -l里多了不明脚本。
应急处置步骤
发现可疑进程后,先别急着kill，按下面顺序操作：
- 执行top -c找到可疑进程的完整命令行，记录PID。
- 执行ls -l /proc/[PID]/exe，查看可执行文件的实际路径。
- 执行cat /proc/[PID]/cmdline，用tr ' ' ' '查看启动参数。
- 执行netstat -antlp | grep [PID]，确认网络连接的目标地址。
- 确认是生产木码后,先断网或封禁异常IP，再kill -9杀掉进程，最后清除定时任务和启动脚本。
服务器cpu100%怎么解决？从应急到根治的完整步骤
很多人遇到CPU跑满,第一反应是重启服务器，重启确实能暂时缓解，但如果不找到根本原因，重启后问题会再次出现，正确的做法分三步。
第一步：应急止损
- 如果服务器上跑着核心业务且无法立即停机,先通过云控制台临时升级CPU规格，或者使用systemctl暂停非核心服务。
- 如果是定时任务引发的,直接停掉对应的cron任务，命令是crontab -e注释掉相关行。
- 如果是恶意程序,按上文步骤封禁IP并杀进程。
第二步：定位根因
- 使用perf top
查看内核级热点函数，判断是用户态还是内核态消耗。
- 使用pidstat -p [PID] 1观察进程的CPU波动规律。
- 打开应用日志,检查异常报错和请求频率，尤其是接口响应时间曲线。
- 代码层面：优化循环逻辑，增加缓存，避免重复计算，使用连接池复用资源。
- 数据库层面：定期分析慢查询，建立索引，对大表做分区，把按月归档的数据拆分。
- 架构层面：把定时任务集中到一个独立的任务服务器，避免业务高峰和任务执行重叠，定时任务的执行时间尽量错开，例如用random_delay让任务在10分钟内随机启动。
- 监控层面：配置CPU使用率告警，阈值建议设为80%持续5分钟，而不是100%才报警。
第三步：长期治理
关于服务器cpu100%的常见问题
服务器cpu占用率100%会不会自动恢复？
要看原因,如果是短时流量高峰，比如促销活动或爬虫抓取，流量过去后CPU会自然回落，但如果是代码死循环或生产木码，CPU会持续保持高位，不会自动恢复，建议先观察10分钟，如果使用率没有下降迹象，立即按排查流程处理。
服务器cpu100%时能不能直接重启？
可以重启,但重启只是治标，重启后如果没有禁用恶意脚本或修正代码，问题会在几分钟内复发，而且重启会导致未落盘的数据丢失，可能引发数据库损坏，更稳妥的做法是先用top和ps记录下占用CPU最高的进程信息，再决定是重启还是杀掉单个进程。
服务器cpu性能对比怎么选才能避免高占用？
服务器CPU性能对比不能只看核心数,还要看主频、缓存和是否支持超线程，对高并发业务，选多核心的型号更划算；对计算密集的深度学习任务，选高主频和更大L3缓存的型号更合适，如果预算有限，可以采用纵向扩展与横向扩容结合的方式，用负载均衡把流量分摊到多台低配服务器上，最终目标是让CPU峰值使用率控制在70%以下，为突发流量留出缓冲空间。
无论原因是什么,服务器cpu100%都不是小事，把排查流程固化到运维手册里，提前做好监控告警，比事后熬夜处理要省心得多。
