服务器CPU受限，多数情况下不是硬件坏了，而是配额打满、单核瓶颈或性能被邻居挤占，先诊断再动手，别急着加钱换机器。
服务器cpu跑满怎么解决
服务器cpu跑满的时候，第一反应别是登录面板疯狂重启，先把现象看清楚，是整体100%还是单核拉满,这决定了完全不同的处理方向。
先分清是真的满载，还是被人为限制
很多用户遇到的情况是：买的时候写着4核，结果top一看，四个核全红，load average飙到8以上，这时候先用top命令按CPU降序排列，找到最吃CPU的进程，如果是一个叫kworker或者systemd的进程异常占用，先去查是不是被入侵挖矿了，如果是个PHP-FPM或者MySQL进程,那就是业务自身的问题。
区分方法很简单：
top里看us和sy占比，us高是用户态程序消耗，sy高是内核消耗- 用
mpstat -P ALL 1查看每个逻辑核的独立负载，判断是单核打满还是均匀分布 - 用
pidstat -u 1追踪具体进程的CPU占用历史
单核跑满但整体不高，先查这类问题
这是最常见也最容易被忽略的坑，云服务器虽然给多核，但某些负载是单线程模型的，比如老旧的PHP程序、部分Python爬虫、Redis单实例操作,都只能吃一个核。
业内的共识是：要看单核利用率，而不是整体平均负载，如果8核机器只有1个核跑满，整体看起来只有12.5%，但业务就是卡,这时候排查这几个方向：
- 是否开启了Gzip压缩，CPU密集的压缩操作会占满单核
- 数据库查询是否走了全表扫描，慢查询日志里一大把
Rows_examined: 几百万的记录 - 是否有正则表达式在循环里做匹配，这种CPU饥饿型操作会让单核瞬间打满
确认是单核瓶颈后，要么改多进程/多线程架构，要么把这类任务迁移到更适合的机器上，如果项目实在改不动，就考虑昇配到更高主频的CPU型号,主频提升对单核性能是立竿见影的。
服务器CPU限制怎么解除
很多租用VPS或者云服务器的用户会遇到一个情况：刚买来性能猛如虎，跑几天后CPU被死死摁在某个阈值上，这不是错觉，也不是服务器坏了,而是触碰了服务商的性能墙。
CPU steal值是个关键信号
用top命令查看，如果wa那一列的下一行出现了st，数值还高于5%，说明虚拟化宿主机上你的邻居在抢CPU，这是CPU steal,意为宿主机分配给别的虚拟机的时间片挤占了你的份额。
处理路径：
- 确认持续的时长，偶尔一次没关系，持续超过30分钟就要处理
- 查一下服务商有没有同代际的物理机租用，业务要求高稳定性的话，物理机是更稳妥的选择
- 如果预算卡得紧，选CPU主频高于3.0GHz的独立IP服务器，对性能敏感型业务有明显改善
这里要提一个行业共识：同价位下，VPS的CPU性能浮动空间远大于物理服务器，常在限CPU边缘试探的用户，尤其做抢购脚本、爬虫采集这类业务的，物理机是根治性能墙的解法。
被服务商限速怎么办
这类情况多发生在低价套餐上，服务商为了保证超售比例下的整体稳定，设置了CPU配额上限，你跑满配额后,会被强制降频或者限制使用率。
解除思路有三个层次：
- 看服务商后台有没有“解除CPU限制”的开关，有些面板提供突发性能（Burst）选项，付费后可以解锁
- 如果是月付低价机，把业务迁到按量计费的云主机上，这类机型一般不做硬性限制
- 做负载均衡，把单台机器的CPU抢占型任务拆分到多个实例上，变相绕开单机配额
把CPU占用的源头找出来
别光盯着CPU数值看，得找到背后真正吃资源的服务，多数情况下，CPU跑满只是表象，源头往往藏在数据库慢查询、日志写入风暴或者定时任务撞车上。
数据库慢查询是头号嫌疑犯
用宝塔面板的，直接看/www/server/panel/vhost/nginx/目录下的nginx访问日志，统计哪些API接口响应时间超过2秒，数据库方面,MySQL开启慢查询日志：
SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1;
然后用mysqldumpslow命令分析慢查询文件,找出执行次数最多和耗时最长的SQL。
mysqldumpslow -s c -t 10 /var/lib/mysql/mysql-slow.log
这个命令按执行次数排序，把排名前10的慢查询列出来，最常见的坑是没有索引的LIKE '%关键词%'查询,这种模糊匹配在数据量上去后CPU消耗是灾难级的。
日志写入也能写满CPU
如果用的是标准云服务器，系统盘IO和CPU是联动的，应用如果开启了debug级别的日志输出，每秒上万条日志写入,rsyslog进程会吃掉大量CPU资源。
排查方法：
lsof | grep deleted查看是否有被删除但仍被占用的日志文件du -sh /var/log/检查日志目录大小，超过2GB就该做轮转策略了- 检查
logrotate配置，确认日志切割周期是否合理
定时任务扎堆是隐藏杀手
多数服务器会同时跑备份、监控、数据同步等定时任务，如果crontab里好几个任务都设在凌晨3点整，CPU会瞬间飙升，短则几分钟，长则半小时,这期间网站响应速度会明显下降。
解决方式：
- 给不同任务错开执行时间，间隔至少15分钟
- 给脚本开头加
flock锁，防止前一个任务没跑完，后一个又重新拉起 - 重量级任务（比如数据库全量备份）挪到业务低峰期，比如凌晨4点到5点之间
服务器CPU不够用怎么办老化的业务代码也是隐形元凶
如果上面这些都查过了，CPU还是经常跑满，那问题很可能出在业务代码本身，这类问题隐藏深,但危害极大。
常见的代码级CPU杀手
- 循环里反复查询数据库，没有做缓存处理，导致每次请求产生几十条SQL
- 递归函数没有终止条件，或者递归深度太大，栈溢出前先把CPU耗光
- 每个请求都重新建立数据库连接，连接池没配置好，大量握手开销拖垮CPU
- 同步等待外部接口响应，接口超时设置过长，导致进程挂起拖拽CPU
低成本诊断命令
先在服务器上装一个htop，按F5切到树状视图，能直观看到进程的父子关系，然后配合strace -p 进程ID查看系统调用，如果发现大量poll和select操作，说明在等IO或者网络响应,这时候CPU的等待开销远大于实际计算。
另一个简便方法：perf top可以实时显示CPU周期被哪些函数吃掉了，如果显示的是php-fpm相关的符号，就是业务代码问题；如果是内核模块的函数,可能就是驱动或者资源竞争的问题。
升级配置还是换服务商给个理性的对比
前面排查都做完了，确认是业务需求确实超过现有配置，这时候才轮到升级这一步，但怎么升,有讲究。
| 对比维度 | 升级CPU核数 | 换高频CPU | 换物理机 | 上集群 |
|---|---|---|---|---|
| 适合场景 | 多线程负载均衡型 | 单核性能敏感型 | 高负载长期运行 | 业务增长期弹性伸缩 |
| 成本 | 中 | 中高 | 高 | 最高 |
| 生效时间 | 分钟级 | 分钟级 | 需迁移 | 需架构改造 |
| 维护成本 | 低 | 低 | 低 | 高 |
选型建议：4核及以下且经常跑满的，优先升核数；4核以上单核打满的，优先换高主频；7×24小时持续高负载的，考虑物理机。
彻底解决需要做容量规划
短期的解围用上面的招数够了，但要长期稳定，得做容量规划，不求精确,但得有个参照。
- 先看监控数据，把CPU使用率的峰值、平均值、周期性的尖刺都拉出来，判断峰值是常态还是偶发
- 业务增长按季度预估，比如当前3个月的新增用户量，再按30%的余量规划未来的CPU配置
- 页面静态化、CDN加速、Redis缓存这类手段能用尽量用，能便宜不少抗压成本
如果租用的是国内机房服务器，工单提“CPU受限”的需求，多数服务商会查看宿主机的负载情况，如果只是你一人超售，会帮你迁移到空闲宿主机上，这种操作通常在2小时内完成。
服务器CPU受限不是绝症，关键看是否找对了病灶，单核瓶颈、性能墙、慢查询、代码质量，挨个排查下来，多半能找出问题所在，真到最后需要升级的时候，也算花得明白,不踩冤枉钱。
服务器cpu跑满怎么解决常见问题速查
问：服务器CPU每隔几小时就飙到100%，重启后恢复，过一段时间又复发，是什么引起的？
答：这种周期性飙升大概率是定时任务（crontab）配置不合理导致的，常见于数据库备份、日志切割、数据同步脚本同时执行造成资源争抢，建议用crontab -l查看所有定时任务，将重量级任务错开执行时间，并给脚本加flock锁防止重叠执行。
问：使用云服务器运行多个网站，其中一个站点流量大导致整个服务器CPU被占满，其他网站全部卡顿，怎么限制单个网站的CPU用量？
答：可以在Web服务器层面做资源隔离，nginx使用limit_req_zone和limit_conn_zone模块限制单个IP的请求频率和并发连接数；Apache则可以通过mod_evasive模块实现类似效果，更彻底的做法是迁移到容器环境，用docker配合--cpus="1.5"参数精确限制每个容器可用的CPU核数,这样单个站点即便流量异常也不会拖垮整台服务器。
问：服务器性能正常，业务代码没有改动，CPU使用率突然从10%变成100%，排查步骤是什么？
答：先执行top查看CPU消耗最高的进程和对应的PID，再执行lsof -p PID查看该进程打开的文件和网络连接，若是陌生进程占满CPU，用ls -l /proc/PID/exe定位可执行文件路径，并结合curl检查是否有异常外联IP，多数情况下，这是恶意挖矿脚本或反弹shell木马入侵的表现，需要立即切断网络并清除相关文件,方可通过服务器cpu跑满怎么解决这条路径根治。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/794545.html
