查看Linux服务器CPU使用率，最常用的命令是top和mpstat，但真正专业的做法是结合vmstat、sar、pidstat等工具，从进程、负载、历史趋势三个维度综合判断，单看一个数字容易误判，比如负载高但CPU空闲，其实是I/O等待在作祟。
linux查看cpu使用率的命令有哪些？
很多新手习惯只用top，但top是实时快照，看不了历史，也分不清核间均衡，下面这几个命令覆盖了日常运维和排查场景，建议按需选用。
top：最经典，第一行%Cpu(s)显示整体使用率，按1键可展开每个逻辑核，重点看us（用户态）、sy（内核态）、wa（I/O等待）、id（空闲），按P键按CPU排序，直接锁定最耗CPU的进程。htop：top的增强版，彩色界面，支持鼠标操作和树状进程视图，多数发行版需要单独安装（yum install htop或apt install htop），它把CPU使用率用进度条按核展示，视觉更直观，适合人肉快速定位问题。mpstat -P ALL 1：来自sysstat包，专门看每个CPU核的使用率。-P ALL表示所有核，1是每秒刷新一次，如果某个核飙到100%而其他核空闲，说明是单线程应用或锁冲突。vmstat 1：不只看CPU，还兼顾内存、IO、运行队列。r列表示正在运行的进程数，wa列是I/O等待，这里的us和sy跟top里的含义一致，但输出更简洁，适合脚本采集。sar -u 1 3：历史数据天王。sar同样来自sysstat，能回溯过去几周的CPU使用率，排查“昨晚异常”这类问题，sar几乎是最好的工具。pidstat -u 1：按进程报告CPU使用率，比top更精确，它能输出进程的%CPU、线程ID和命令名，适合写进监控脚本。
行业共识认为,熟练使用top加vmstat，已经能解决80%的CPU排查场景，其余工具按需学习，不必贪多。
怎么从top输出判断CPU使用率是否正常？
top第一行里，us、sy、wa是三个关键信号，新手常犯的错是只看id，觉得空闲高就没事，忽略了wa高其实意味着磁盘拖后腿。
| 指标 | 正常范围参考 | 警醒信号 |
|---|---|---|
| us（用户态） | 30%-70% | 持续>70%，说明有应用在疯狂计算 |
| sy（内核态） | 5%-15% | 持续>30%，可能系统调用频繁或虚拟化开销大 |
| wa（I/O等待） | 0%-5% | 持续>20%，磁盘是瓶颈 |
| id（空闲） | 20%以上 | 长期接近0%，CPU饱和 |
但“正常”是相对的，一个跑着MySQL的服务器，sy高一点很合理；一个纯静态Nginx，us超过50%就反常，更靠谱的判断方法是看趋势：用top -d 1多刷几次，如果us一直往上走，说明负载在堆积；如果忽高忽低，可能是定时任务或流量抖动。
另外一个容易被忽略的点：负载均衡，如果4核CPU跑满，但4个核的利用率分别是100%、5%、5%、5%，这是典型的单线程瓶颈，整体使用率只有28%，但业务实际已经卡顿，这时应该看进程的%CPU是不是接近100%，再决定是优化代码还是换高主频CPU。
linux服务器cpu占用过高怎么排查？
CPU飙高时,别急着kill进程，按下面顺序操作，多数能快速定位。
- 先用
top找元凶：执行top -c，让命令展示完整路径，看%CPU最高的PID，记下来。 - 确认线程：
top -Hp PID，看到具体哪个线程吃CPU，如果进程是多线程的，这一步能缩小范围到线程ID。 - 转到进程栈：
gdb -p PID或pstack PID，抓取线程栈，没有gdb就用cat /proc/PID/task/TID/stack，至少能看到内核调用路径。 - 结合日志看业务：如果是Java应用，用
jstack导出线程栈；如果是Python，用py-spydump；如果是Node.js，用--prof做CPU剖析，这一步才是定位根因的关键，命令只是辅助。 - 查系统层面的异常：
dmesg -T | tail -n 20看有没有Out of Memory或硬件错误；cat /var/log/messages看是否有人在跑全表扫描或爬虫。
业内专家指出,相当一部分“CPU占用过高”其实是内存换页引起的，进程不断访问磁盘上的swap空间，wa不高但sy暴涨，CPU内核态在拼命处理页中断，这种情况加内存比调优代码更直接。
排查时需要留个心眼：top默认显示的是进程最近一次采样的使用率，不是平均值，如果进程时高时低，多按几次空格刷采样，或者用pidstat -u -p PID 5 5看5秒内的平均趋势，避免误判。
linux服务器负载高但cpu使用率低是怎么回事？
这是常见的“伪高CPU”现象，负载（load average）和CPU使用率不是一回事，别被top第一行的load average吓到。
- I/O等待：
vmstat 1里wa值高，r队列长，但us和sy都很低，典型场景是文件服务器在做大量读写，或数据库的日志刷盘太频繁。 - 不可中断进程：进程进入D状态（通常是在等磁盘I/O），CPU只能干等，不会主动切换。
top里D状态的进程数越多，负载越高，CPU却闲着。 - 内存交换：
free -h看到Swap used在涨，说明物理内存不够了，CPU大部分时间在搬数据，而不是跑业务，所以使用率低但响应慢。 - 锁竞争：多个线程抢一把锁，CPU空转，进程也卡住，用
pidstat -d 1看磁盘读写和CPU的对照，结合strace -p PID看系统调用是否阻塞在futex。
判断方法不复杂：负载高时，先看vmstat的r和b列。b列数值高，说明有进程卡在I/O；r列高但us低，多半是锁或内存问题。load average是1分钟、5分钟、15分钟的均值，如果1分钟高而15分钟低，说明是突发流量，别急着动服务。
如何用sar和pidstat做历史回顾和进程级监控？
排查正在发生的问题用top，复盘过去用sar，追责到进程用pidstat，sysstat包里的这两个工具，能救很多次应急。
- 用
sar查看历史CPU：先确认sar在运行（systemctl start sysstat），然后执行sar -u -f /var/log/sa/sa日期，比如看昨天早上9点的数据：sar -u -f /var/log/sa/sa09 | grep '09:'。sar输出平均、最大和最小使用率，还能配合-q查看负载队列。 - 用
sar对比多核：sar -P ALL -f /var/log/sa/昨天，如果发现某个核持续100%，而其他核很闲，基本确定是单线程瓶颈，该考虑改并行架构。 - 用
pidstat做进程追踪：pidstat -u -p 进程PID 2 10，每2秒采样一次，共10次，输出进程的CPU使用率和累计运行时间，想追线程就加-t参数。 - 把
pidstat输出落盘做定期基线：写个cron任务，每天早上8点跑一次pidstat -u -p 主进程 60 5 > /tmp/pidstat.log，连续收集一周，就能看出业务高峰期的CPU消耗规律，再结合sar的周报表，判断是否需要扩容或优化。
这几个命令组合起来,已经能覆盖从实时监控到历史回溯的全链路，很多线上事故，就是因为只盯着top看一分钟，没等抓到异常就恢复了，事后没法复盘，有了sar和pidstat，至少能留下数据依据。
别只盯数字，要盯业务
Linux服务器CPU使用率没有绝对标准,关键是看变化趋势和业务表现，CPU高不一定坏，CPU低也不一定健康，一个高并发的Web服务器，CPU稳定在80%反而是高效率；一个空闲的数据库服务器，CPU只有5%但I/O等待高，照样需处理，把top当入门，把sar和pidstat当习惯，日常巡检时多看一眼vmstat的r和b列，比只问“怎么提高CPU使用率”要扎实得多。
Q&A
linux cpu使用率100%是什么意思？
表示CPU所有核心都在满负荷运转,没有空闲能力，可能原因包括：复杂计算任务、死循环、内存换页、或者恶意挖矿进程，先执行top按CPU排序找出进程，再查进程行为，如果进程名可疑，用ls -l /proc/PID/exe看真实路径。
怎么查看多核CPU每个核的使用率？
用mpstat -P ALL 1，每秒打印每个逻辑核的%usr、%sys、%idle，或者top后按1键，顶部会逐行显示每核数据，如果某个核持续100%而其他核空闲，是典型的单线程瓶颈，需要优化代码或调整进程绑核策略。
如何用命令行监控某个进程的cpu使用率？
先拿到PID,然后pidstat -u -p PID 2，每2秒输出一次该进程的CPU占用和累计运行时间，想连线程一起看，加-t参数，更简单的方式是top -p PID，但pidstat的输出更适合重定向到文件做监控记录。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/771940.html
