服务器CPU占用率过高，核心思路是先定位再处理，不要盲目重启，按“找进程→查状态→定策略”三步走，绝大多数情况能在10分钟内解决。
服务器cpu一直100%是怎么回事，先分清表象和病根
CPU飙高本身不是病,而是症状，就像人发烧，体温计只是告诉你身体有炎症，但病因可能是感冒、阑尾炎，也可能是免疫系统问题，服务器CPU占用率过高，同样要先分清是哪种“烧法”。
是持续拉满还是脉冲式飙高
打开任务管理器或top命令看一眼曲线,这个问题就清楚了。
- 持续100%：某个进程或内核线程死循环，或者负载确实超出了硬件承受能力，这种情况最典型，也最容易通过进程排查定位。
- 脉冲式飙高：每隔几分钟或几小时，CPU瞬间冲到90%以上，然后回落，常见于定时任务（crontab）、日志压缩、数据库定时备份，也可能是被入侵后挖矿程序在“上班”。
是用户态占用高还是内核态占用高
Linux下用top命令,看us（用户态）和sy（内核态）两个指标，us高说明是应用程序在忙，比如PHP-FPM、Java进程、MySQL；sy高说明是系统调用频繁，比如磁盘I/O等待、网络中断风暴、内核模块异常，这两者的排查方向完全不同。
行业共识认为,us持续超过70% 通常是业务代码或配置问题，sy持续超过30% 则要优先怀疑系统层和硬件驱动。
服务器cpu占用率过高怎么办：Linux和Windows各自的排查路径
不同操作系统的排查工具和思路差异很大,分开讲更清晰。
Linux服务器CPU占用率高，用这三条命令锁定元凶
登录服务器后,按顺序执行以下操作：
第一步，top命令看全局
top按大写P键按CPU使用率排序,第一屏就能看到最耗CPU的进程PID，记下这个数字。
第二步，ps命令看进程细节
ps -fp PID
ps -o pid,ppid,%cpu,%mem,cmd -p PID这里能确认进程的启动命令、父进程、运行时长，如果看到命令是xmrig、kdevtmpfsi、kinsing这类陌生名字，基本可以断定是挖矿木马。
第三步，strace或perf看系统调用
如果进程是我们自己的业务进程,但CPU就是降不下来，需要用perf采样看看热点在哪：
perf top -p PID如果显示热点集中在__dentry_kill或flush_tlb_page这类内核函数，大概率是文件句柄泄漏或内存回收异常，这时候不要纠结业务代码，先检查系统参数：
cat /proc/sys/fs/file-max
sysctl vm.max_map_countWindows服务器CPU占用高，任务管理器不够用
Windows Server上，任务管理器可以快速看到CPU占用率最高的进程，但有个坑：很多系统进程（比如svchost.exe）是共享的，你看到svchost.exe占100%，但不知道具体是哪个服务，这时候用系统自带的资源监视器：
- 打开“运行”，输入
perfmon /res，回车 - 切换到“CPU”选项卡
- 展开“关联的句柄”，搜索占CPU高的进程名
- 看最下面“模块”列表，里面会显示具体是哪个DLL或exe在消耗CPU
用这个办法,八成能定位到具体是IIS的w3wp.exe工作进程，还是SQL Server的sqlservr.exe。
定位到具体进程之后：不同场景的降载策略
找到元凶不是终点,怎么处理才是关键，这里按最常见的几种场景给出实操方案。
业务进程正常但负载过高，该扩容还是优化
如果确认是业务高峰期导致CPU跑满,比如电商大促、游戏开服，这时候查代码来不及，先做两件事：
- 临时扩容：云服务器直接控制台升级配置，一般5-10分钟生效，按小时计费，活动结束后再降配
- 加缓存：如果Redis没用上，先用起来，把数据库查询热点缓存住，CPU能降20%-30%
这里说一下服务器cpu降配的事，很多团队大促结束后忘了降配，多花了冤枉钱，简米云、酷番云的控制台都支持升降配，降配操作实时生效，但注意有些机型降配会强制重启，提前做好割接窗口。
明显是挖矿病毒，杀毒不是重点，防再次入侵才是
挖矿木马的特点是：CPU占用率稳定在100%左右，进程名伪装成系统服务，网络连接指向陌生IP，处理步骤：
- kill掉进程：
kill -9 PID - 删除恶意文件：
find / -name "xmrig" -type f -delete - 排查入侵路径：
last -f /var/log/wtmp查看登录记录，重点看有没有异常IP的SSH登录 - 修补漏洞：如果是Redis未授权访问导致的入侵，立即给Redis加密码并禁用危险命令；如果是SSH弱口令，换成密钥登录
杀毒只是治标,改密码、关端口、上防火墙这三件事不做，第二天病毒还会回来。
数据库导致CPU飙升，慢查询是首要嫌疑
MySQL实例CPU跑满,大部分情况是SQL没走索引，登录数据库执行：
SHOW FULL PROCESSLIST;看State列是不是Sending data，再看Info列，把耗时长的SQL复制出来，用EXPLAIN分析执行计划，常见问题：
- where条件字段没建索引
- 用了
SELECT导致回表次数暴增 - 大表order by排序字段没索引，触发了filesort
优化方案优先级：加索引 > 改SQL > 分表 > 上缓存，据统计，相当一部分数据库CPU飙升问题，通过加一个联合索引就能解决，不用动架构。
系统进程占用高，检查驱动和更新
Windows服务器上,如果看到System进程长期占用CPU超过30%，先更新网卡驱动和主板芯片组驱动，近几年硬件厂商的驱动优化参差不齐，部分网卡在高速传输时会发生中断风暴，直接拖垮CPU，更新驱动后问题依旧，可以试试在设备管理器里把网卡的“大量发送卸载”和“接收段合并”禁用掉，症状会明显缓解。
从根源上降低服务器cpu占用的主动措施
排查和救火紧急,但更值钱的是预防，下面这几个措施，成本低、效果好，建议在服务器上线时就配好。
监控告警：比人肉盯服务器可靠得多
不要等用户投诉网站卡了才发现CPU爆了,用云厂商自带的监控（如简米云CloudMonitor）或开源的Prometheus+Grafana，设置CPU告警阈值：
- 连续5分钟CPU超过85%，触发警告
- 连续15分钟CPU超过90%，触发紧急告警
- 告警通道优先接钉钉或企业微信机器人,响应速度比短信快
日志和慢查询：定期体检
- Linux下用
journalctl --disk-usage看系统日志占用空间，超过1GB就配置SystemMaxUse=500M清理 - MySQL开启慢查询日志：
set global slow_query_log=ON;，把long_query_time设为2，每周末分析一次慢查询日志
定期清理是很多运维容易忽略的事，日志文件、临时文件、session文件积累到一定程度，磁盘I/O会显著拖慢CPU处理速度。
成本预算有限时的取舍
很多中小公司采购服务器时纠结配置,预算有限又想性能好，这里有个不成文的经验：CPU主频比核数重要，同样预算下，选高频4核可能比低频8核更实用，因为大多数应用是单线程瓶颈，核心之间通信的开销也不小。
如果你现在用的是2核4G的小内存服务器,CPU经常跑到80%以上，先别急着升配置，检查一下是不是PHP-FPM的pm.max_children设置过大，内存没炸但CPU先炸了，把pm.max_children从默认值调小到合理区间，同时开OPcache，CPU占用率能降一半左右。
服务器cpu占用率过高怎么解决：3个高频问题答疑
服务器CPU一直100%但找不到高占用进程，是为什么
这种情况大多是CPU被内核态消耗了,而不是用户态进程，用top看sy列的数值，如果sy超过30%，执行vmstat 1看cs（上下文切换）和in（中断）列，这两个数值如果持续在几万以上，说明系统在疯狂切换上下文，常见原因是网卡多队列没开启、虚拟化环境CPU steal过高，云服务器的话，检查一下同物理机上的邻居是否在“吵闹”，如果是独享型实例，重点查驱动。
Windows服务器CPU占用高可以用任务管理器直接结束进程吗
可以,但要分情况，如果是自己部署的应用进程，直接结束可能导致数据丢失或服务不可用，建议先尝试通过应用自带的管理页面或命令行优雅停止，如果是陌生进程或明显异常的svchost.exe，任务管理器结束不了（提示拒绝访问）就用管理员身份配合PowerShell执行Stop-Process -Id PID -Force，结束之后立即排查启动项和服务，防止开机自启复活。
数据库和Web应用部署在同一台服务器上，CPU经常来不及处理怎么办
尽量拆分,至少把数据库迁到独立实例，两者共存时，Web应用的突发流量会抢占数据库的CPU资源，导致查询延迟飙升，用户感知就是网页加载速度从1秒变成10秒，预算不足的话，可以先用云数据库的基础版（价格通常只有自建的一半），按量计费控制成本，拆分之后记得把应用的数据库连接池上限调低，避免连接数打满新实例。
处理CPU占用率过高的问题,本质上是一个“定位准确性”的游戏，先看清楚是真的负载大，还是代码有问题，还是被入侵，再动手调整，掌握上面这些排查命令和思路，绝大多数情况下你都能在半小时内恢复服务，而不是干瞪眼等重启。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/%e6%9c%8d%e5%8a%a1%e5%99%a8cpu%e5%8d%a0%e6%9c%89%e7%8e%87%e8%bf%87%e9%ab%98%e6%80%8e%e4%b9%88%e5%8a%9e%ef%bc%8c%e6%98%af%e4%bb%80%e4%b9%88%e5%8e%9f%e5%9b%a0%e5%af%bc%e8%87%b4%e7%9a%84%ef%bc%9f/
