想知道服务器CPU到底忙不忙、忙在哪？直接登录服务器，跑一遍top命令看%Cpu(s)这行，再配合vmstat 1看us和sy两列，最后用pidstat -p ALL 1揪出具体进程，这套组合拳能解决八成以上“CPU使用率异常”的排查需求。
服务器cpu使用率怎么看：先分清三个“率”
很多人一登录服务器就敲top，看到数字超过80%就慌，其实CPU使用率这个词太笼统，得先拆开看。
用户态使用率、系统态使用率和空闲率
top命令第一行有个%Cpu(s)的统计，后面跟一串数字，你只需要盯住前三个：
- us：用户态占用，跑业务程序、PHP、Java、Nginx都算这里，这个值高说明业务真在忙。
- sy：系统态占用，内核在处理系统调用、内存分配、IO中断，这个值长期超过20%，要么是系统调用太频繁，要么是内核参数出了问题。
- id：空闲率，这个值越低，CPU越累。
行业共识认为,us高是正常忙，sy高才是需要警惕的“瞎忙”。
平均负载（load average）和CPU使用率是两回事
top右上角还有三个数字，比如load average: 4.32, 3.18, 2.76，这是1分钟、5分钟、15分钟的平均负载，指的是“正在运行和不可中断进程的数量”。
四核CPU的负载达到4.0，说明CPU刚好跑满，四核负载只有2.0，但CPU使用率显示100%，这说明有进程在疯狂自旋，或者大量短暂进程在排队切换，反过来，CPU使用率只有30%，负载却高达8，那大概率是进程在等IO，比如磁盘卡了或者网络拥堵，所以判断服务器压力，必须把负载和使用率放一起看。
linux查看cpu占用命令：从安装到实战全流程
最基础的命令组合：top + vmstat + pidstat
top适合看实时快照，但它是动态刷新的，不适合抓历史数据，实际排查建议按下面顺序操作：
- 跑
top -bn1抓一次静态快照，看整体占用和排名前十的进程。 - 跑
vmstat 1 5，每隔1秒输出一次，一共5次，重点看r列（运行队列）和cs列（上下文切换）。 - 跑
pidstat -p ALL 1，逐进程显示CPU占用，找到具体是哪个PID在捣乱。
这套流程十几秒就能跑完,比单纯盯着top刷新要快得多，很多云服务器厂商的监控面板上报的“CPU使用率100%”，你通过这三步能在两分钟内定位到具体进程。
htop和atop：更直观的交互式工具
htop是top的增强版，支持鼠标点击排序、树状进程视图、颜色区分CPU核心使用情况，安装命令很简单：
- CentOS发行版：
yum install -y htop - Ubuntu发行版：
apt install htop
atop比htop更硬核，它不仅能看CPU，还能记录历史日志，多数情况下系统工程师喜欢用atop来追查“昨天凌晨CPU为什么飙高”这种历史问题，因为它的日志默认保留7天。
压测和监控场景下的sar命令
服务器上线前要做压测,压测时怎么看CPU？用sar。
sar -u 1 10会每秒取一次CPU使用率样本，共取10次，最后输出平均值，它比top更适合生成报告，因为输出格式是纯文本，可以直接重定向到文件里，如果你不确定服务器装了没装，跑一下sar -V看看版本号即可，没装的话，在CentOS上装sysstat包就能带出来。
windows服务器cpu占用高排查：别只盯着任务管理器
Windows服务器的CPU排查思路和Linux类似,但工具路径完全不同，不少运维新手在Windows上第一反应是打开任务管理器，看“性能”页签这没错，但信息量太少了。
任务管理器看进程和性能
按Ctrl + Shift + Esc打开任务管理器，点“进程”页签，按CPU列降序排列，马上能看到哪个程序在吃CPU，但注意，Windows的任务管理器默认不显示系统进程的详细信息，建议勾选“显示所有用户的进程”。
单核占用100%但多核整体只有25%，说明这个程序写死了单线程，加CPU核数没用，此时要去“性能”页签看“逻辑处理器”那一栏，确认每个核心的使用率分布。
资源监视器和性能监视器组合使用
任务管理器只能看到进程级别,要看线程级别，得用资源监视器，在运行框输入resmon，切到“CPU”页签，展开某个进程就能看到它内部每个线程的CPU占用。
更进一步,性能监视器（perfmon）可以添加计数器，比如
Processor Information(_Total)% Processor Utility，你可以让它记录30秒的采样数据，然后导出成CSV分析，Windows服务器CPU占用高排查，这两款工具比第三方任务管理器更靠谱，因为它们不依赖额外安装的Agent，能直接反映系统真实状态。
服务器cpu使用率高的常见元凶：定位到进程之后怎么办
找到CPU占用高的进程,只完成了前半段，后半段是判断这个进程为什么疯转。
业务代码的常见坑：死循环、锁竞争、GC风暴
Java服务CPU飙高,先抓线程栈，用jstack PID | grep -A 20 "java.lang.Thread.State"看线程状态。RUNNABLE状态的线程大量集中在同一个方法里，多半是死循环或自旋锁。BLOCKED状态多，则是锁竞争激烈。
PHP和Python项目如果CPU飙高,优先检查日志里有没有报错刷屏，多数情况下是某个接口在死循环重试请求，把CPU吃满了。
数据库查询和缓存失效导致的计算风暴
MySQL的CPU突然飙到90%，先查慢查询日志，如果一堆大SQL在同时做全表扫描，数据库CPU肯定扛不住，Redis缓存大面积失效也会引发类似问题所有请求穿透到数据库，数据库CPU被打满，连带应用服务器CPU一起飙高。
系统和中间件层面的不确定性
有时候进程没问题,但CPU就是降不下来，检查两个东西：系统日志里有没有频繁的soft lockup警告；中断号的分布是否集中在单个CPU上，如果跑着Nginx或RabbitMQ，还要看看工作进程数和CPU核数的关系，进程数远超核数会导致频繁切换，CPU时间大量消耗在上下文切换上，这种问题vmstat的cs列会给出明确信号。
会被忽略的排查技巧：从时间线和日志反推
排查服务器CPU使用率问题,不要只看实时状态，学会看时间线和日志反推。
结合监控历史缩小时间范围
云服务器控制台里的监控图往往能看出CPU飙高的起始时间,精确到分钟之后，去服务器上看对应时间的cron任务日志、应用部署日志、备份脚本日志，相当一部分CPU飙高是定时任务集中执行造成的，比如日志压缩脚本在凌晨三点同时跑，把CPU堆满了。
网络流量和磁盘IO是辅助线索
CPU高不一定是计算密集,也可能是在等数据，用iftop看实时网络流量，用
iostat看磁盘IO，如果CPU使用率高同时网络接收流量也大，考虑是不是被爬虫或恶意扫描了，如果磁盘util接近100%，CPU大概率在等待IO完成，这时候给它加核没用，得换更快的磁盘或者优化读写逻辑。
长期监控：别等问题爆了才想起来看
临时登录服务器看CPU,只能解决眼前的问题，如果你管理的服务器数量超过十几台，挨个登录跑top是不现实的。
业内专家指出,部署一套基础的监控告警比学会所有命令更重要，开源的Prometheus加node_exporter就能采集CPU、内存、磁盘、网络指标，配合Grafana画可视化面板，云厂商自带的监控产品也够用，基本都能设置CPU使用率阈值告警，将阈值设在80%持续5分钟作为告警条件比较合理。
有了历史数据和告警,再遇到CPU飙高，你就能直接回溯到具体时段的进程快照，而不是等服务器卡死了才去抢救。
服务器CPU使用率这类问题,归根结底是定位问题，先用top看整体，再用vmstat看行为特征，接着用pidstat锁进程，最后结合日志和监控判断根因，这套方法论覆盖了Linux和Windows平台的大多数场景，熟练以后，一台服务器CPU异常，五分钟内就能给出初步结论。
Q&A：服务器cpu使用率怎么看
问题1：top命令显示的CPU使用率总和为什么常常不等于100%？
top命令的%Cpu(s)行除了us、sy、id之外，还有wa（IO等待）、hi（硬件中断）、si（软件中断）、st（被虚拟机偷走的时间），这些值加起来才是完整的100%，如果你在云服务器上看到st值很高，说明宿主机上其他虚拟机在争抢物理CPU资源，这是云服务商超卖导致的，你自己无法通过优化业务来解决。
问题2：服务器CPU使用率显示100%，但业务响应并不慢，正常吗？
正常,CPU使用率只代表计算资源被消耗的程度，不代表系统在处理有效业务，比如压测工具、日志备份进程、数据迁移任务，都会大幅拉高CPU使用率，你需要关注的是业务延迟指标，如果CPU满载但接口响应时间依然在几十毫秒内，说明系统还有性能余量，或者CPU是在处理收尾性质的工作，反过来CPU使用率只有40%但接口响应很慢，那瓶颈多半在锁、网络或磁盘IO上。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/715373.html
