看服务器CPU利用率，最直接的方法是执行top命令看%CPU和load average，但关键是要区分用户态、系统态和I/O等待，否则容易被“空闲”假象误导。
很多刚接触服务器的人,一看到CPU使用率100%就慌，其实在Linux里，CPU“忙着”并不等于“有问题”，得看它到底在忙什么，这篇文章会把查看CPU利用率的常用命令、判断标准、排查逻辑一次讲清楚，全程拿真实可跑的命令说话。
怎么看服务器的cpu的利用率？先分清这五种CPU状态
CPU利用率并不是一个单一数字,在Linux的/proc/stat里，它被拆成好几个时间片，用top命令默认显示的是%Cpu(s)，那一行有多种状态，常见的五种你要能认出来：
- us（user）：用户态CPU使用率，跑应用程序、脚本、数据库查询都算这一块。
- sy（system）：系统态CPU使用率，内核操作、系统调用、驱动处理占的比例。
- wa（iowait）：等待I/O完成的时间，比如磁盘读写慢，CPU在等数据，这时候wa高说明瓶颈在存储。
- id（idle）：空闲率，完全没被占用。
- st（steal）：虚拟机被宿主机抢走的CPU时间，云服务器上如果st长期偏高，说明物理机资源超卖严重。
行业共识认为,判断CPU是否健康，不能只看id是不是很低，而要同时关注us和wa，us高代表计算密集，wa高代表磁盘拖后腿，这两者的处理方向截然不同。
linux查看cpu利用率命令：top、mpstat、sar到底怎么选
用top命令快速查看整体CPU占用
top是Linux自带的老牌命令,输入top后回车，屏幕最上方两行信息最关键。
第一行是系统运行时间和load average，后面跟三个数字，分别是过去1分钟、5分钟、15分钟的系统负载均值，这里有个常见误区：load average高不等于CPU利用率高，它统计的是处于运行状态和不可中断状态的进程总数，如果服务器是8核CPU，load average持续高于8.0，说明任务在排队；低于8.0时，即使某个核利用率100%，整体也能接受。
第二行是进程列表里的%CPU列，默认按CPU占用从高到低排序，要特别注意，top里的%CPU是多核加总后的结果，一个进程如果用了2个核，显示可能是200%，所以看到某个进程CPU数值超过100%时，不用怀疑数据出错，那是它占了多个逻辑核。
用mpstat查看每个CPU核的使用率
服务器负载高时,你需要知道是某个单核被占满，还是所有核平均高负载，mpstat是sysstat包里的工具，执行：
mpstat -P ALL 1 3
这个命令会每隔1秒采样一次,共执行3次，然后输出每个CPU核的us、sy、wa、id等指标，如果只有一个核的us接近100%，其他核空闲，那就是典型的单线程应用瓶颈，比如老的PHP进程或某些数据库逻辑；如果所有核都高，说明负载确实很平均。
mpstat的优势是简洁,不像top那样动态刷新，适合抓取瞬间状态。
用sar记录历史CPU利用率
排查历史性能问题时,临时去跑top已经来不及了，提前开启sysstat服务的服务器，会在/var/log/sysstat/目录下保留历史记录，查看今天某段时间的CPU使用率：
sar -u -f /var/log/sysstat/sa28
其中sa28是某天的数据文件,日期按月份命名，如果你想知道当前实时CPU情况，直接用：
sar -u 1 5
它每秒打印一行CPU状态,连续5次后输出平均值，sar的好处是能给出一个统计汇总，不像top那么杂乱，适合写入运维脚本。
服务器cpu利用率过高怎么排查？按这四步走
当top显示CPU利用率长期高于80%，不要急着kill进程，先按顺序做以下检查。
第一步：确定是用户态高还是系统态高
观察%Cpu(s)那一行的us和sy数值，如果us高，基本可以锁定是业务程序自身的问题死循环、复杂计算、慢SQL、内存泄漏引发频繁垃圾回收等，如果sy高，更可能是系统调用频繁，比如大量的网络包处理、文件锁抢占、进程频繁创建销毁。
这时可以用pidstat定位具体线程：
pidstat -p $(pidof 你的程序) -t 1 5
它会显示进程内每个线程的CPU占用,找到占用最高的线程ID，再用top -Hp 进程ID确认线程栈状态。
第二步：判断是不是I/O等待导致的虚高
看wa字段,如果wa长期在30%以上，而us不高，那CPU利用率数字虽然高，但真正的问题在磁盘或网络，你可以用iostat -x 1看看磁盘的%util参数，再用vmstat 1看bi和bo列每秒钟的块读写量，还有一种典型情况是内存不足导致swap频繁读写，CPU大量时间花在换页上，此时free -h如果有少量swap used，就要考虑加内存或优化缓存。
第三步：查一下是不是云服务器CPU被“偷走”
在云服务器商（简米云、酷番云）控制台里，CPU利用率指标是宿主机视角的，而虚拟机内部的st字段才能反映被抢占的情况，执行：
top -b -n 1 | grep '%Cpu'
看st数值,如果st持续超过10%，说明你的云服务器CPU性能受到影响，可能是同物理机邻居上大负载，这种情况下程序再优化也白搭，直接提工单让云厂商迁移实例，或者在购买云服务器时选择独享型实例，避免CPU积分制的突发型实例在持续高负载下被限速。
第四步：结合日志和监控平台做趋势分析
一次性命令只能看到当下,无法回答“服务器cpu利用率过高”是不是偶发现象，正经的做法是接入Prometheus + node_exporter，或者用Zabbix监控历史曲线，node_exporter采集的node_cpu_seconds_total指标会以累计秒数存储，你可以用rate()函数计算某个时间段内的平均利用率。
长期监控CPU利用率，掌握两个自动化技巧
用vmstat配合脚本采集周期数据
vmstat自带时间戳和平均输出,适合写进cron任务，比如每5分钟采样一次，写入文件：
/5 vmstat -t 2 2 | tail -1 >> /var/log/cpu_usage.log
这样积累一个月后,用awk把us和id列拉出来，就能大致摸清服务器的忙闲规律，比如每天凌晨3点CPU跑满，是不是定时备份太集中，这些数据都是你自己生产的，比任何第三方报告都可靠。
使用Linux自带的perf判断热点函数
当某个进程CPU占用奇高但原因不明时,可以用perf top直接看它正在执行的内核或用户态函数：
perf top -p 进程ID
这是比较底层的排查手段,适合开发或资深运维，普通场景下，先用top和vmstat定位到进程，再用perf确认具体代码位置，不要一上来就开perf，信息量太大反而不好下手。
怎么理解服务器CPU利用率的不同数值区间
很多新手爱问：“CPU利用率达到多少算正常？”这里没有绝对标准，但有一个经验区间可供参考：
| CPU平均利用率 | 状态判断 | 建议动作 |
|---|---|---|
| 0% – 30% | 偏低，资源富余 | 关注是否过度配置，可尝试降低规格节省成本 |
| 30% – 60% | 健康，留有余量 | 正常业务波动范围，不需要干预 |
| 60% – 80% | 偏高，注意监控 | 留意趋势，建议配置告警阈值 |
| 80% – 100% | 危险，需要排查 | 直接进入排查流程，优先确认wa和st |
需要指出的是,这个区间只适用于绝大多数中小型业务，如果服务器是数据库专用，活跃时CPU到90%也未必有问题，因
为数据库经常把缓存池预热在内存里，算力消耗本来就大，关键是看持续时间和响应时间，如果是Windows服务器，任务管理器里的“CPU使用率”和Linux的top计算方式不同，它包含中断处理时间，所以经常看到数值跳动更剧烈。Windows服务器CPU利用率100%时，优先看资源监视器里“平均CPU”最高的进程，再检查Windows事件日志里的错误级进程。
关于服务器CPU利用率，还有哪些常见疑问？
怎么看服务器的cpu的利用率是不是被挖矿程序占用了？
先用top看进程名，挖矿进程通常会伪装成kdevtmpfs、watchdog这类听起来像系统的名字，验证方法是查看进程的可执行文件路径：
ls -l /proc/进程ID/exe
正常系统命令在/usr/bin下，挖矿程序一般在/tmp或/var/tmp下带着奇怪的随机名，再用ss -antp | grep 进程ID检查它有没有建立外部连接，挖矿程序一定会连接矿池的IP和端口。
查看多个服务器的CPU利用率有没有更省事的方法？
单台服务器用top,多台服务器用并行SSH工具，比如pdsh或ansible，一条命令传到所有机器上执行：
ansible all -m shell -a "top -bn 1 | head -n 5"
如果你有简米云或酷番云的服务器,直接控制台的“云监控”页面能列出所有实例的CPU图，还能设置使用率超过80%时发短信告警，对于本地机房设备，用Grafana搭一个多服务器面板，比登录每台机器更直观。
CPU利用率低的服务器，为什么业务依然卡顿？
因为应用卡顿的根因往往在内存、磁盘I/O或网络延迟，CPU空闲说明它没在等自己，而是在等下游资源，你去看vmstat的wa和cs列，如果cs（上下文切换）每秒超过5万次，说明系统在疯狂切换进程，即使CPU利用率只有20%，表现也会像死机一样，这种情况建议减少运行中的线程数，并用strace -c统计进程的系统调用次数。
判断服务器CPU利用率从来不是看一个数字就结束,它只是一个入口，走进这个入口以后，你会遇到负载均值、中断处理、上下文切换、内存换页这些更具体的问题，把上面这些命令用熟，至少能让你在告警短信响起来的时候，知道下一步往哪个方向看。多练几次top和vmstat，你就会形成自己的直觉：先判断规模，再定位进程，最后看趋势，CPU的事，八成出不了这个圈子。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/734926.html
