排查欧拉系统CPU占用，先学会这几条命令
在欧拉系统（openEuler）中查看各服务器CPU运行占比，最高效的方式是使用“top + 按P排序”组合命令，它能实时列出所有进程按CPU使用率降序排列，配合“htop”和“mpstat”可覆盖绝大多数排查场景。如果你管理的服务器不止一台，还可以通过“pdsh”或“ansible”批量执行命令,一次性拿到所有节点的CPU负载概况。
用top命令快速定位CPU占用来源
top是所有Linux运维人员最先接触的工具，在欧拉系统里它的使用方式和CentOS基本一致，登录任意一台欧拉服务器，输入top回车，屏幕上半部分会滚动显示整体负载信息,下半部分是进程列表。
核心操作步骤：
- 输入
top进入实时监控界面 - 按下大写
P键，进程列表会立即按CPU使用率从高到低排序 - 按下
1键，展开或折叠每个CPU核心的使用率曲线 - 按下
c键，显示进程的完整命令行路径 - 按下
q键退出
在这个过程中，你要重点看两处数据，第一处是%Cpu(s)这一行，它展示了用户态（us）、系统态（sy）、空闲（id）等占比，如果us长期高于70%，说明有用户进程在大量消耗CPU；如果sy偏高，则要关注系统调用是否过于频繁，第二处是进程列表中的%CPU列，这一列数字超过100%表示该进程使用了多核并行能力，比如一个数值显示为300%,意味着它占用了3个完整的CPU核心。
top的缺点是无法记录历史数据，如果你想对比某个进程在某一时段的CPU变化趋势,就要用到下一节的方法。
欧拉系统cpu占用过高怎么排查：从进程到线程逐层下钻
当你发现某台服务器响应变慢，第一步不是直接重启,而是按以下顺序逐层定位：
- 先用
top找到占用最高的进程PID - 然后用
top -H -p PID查看该进程内部所有线程的CPU占用 - 再用
printf "%xn" 线程ID把线程ID转成十六进制 - 最后用
gdb attach PID或jstack（Java应用）导出线程栈，查看具体执行到哪段代码
这套方法在处理Java应用CPU飚高时尤其有效，行业共识认为，多数CPU异常问题并非硬件故障，而是代码死循环、频繁GC或线程空转导致。
假设你发现一个PID为2873的进程CPU常年维持在150%上下，执行top -H -p 2873后看到线程ID为2901的子线程占用特别高，将2901转成十六进制得到b55，再用gstack 2873 | grep -A 30 "b55"就能看到该线程当前执行到哪个函数,整个过程耗时不超过两分钟。
欧拉系统top命令用法延伸：htop和mpstat的互补价值
虽然top功能强大，但它的交互式界面在远程终端里有时显示错乱，这时不妨试试htop，它需要额外安装（yum install htop -y）,但呈现方式更直观。
| 对比项 | top | htop |
|---|---|---|
| 彩色显示 | 默认无 | 默认有 |
| 鼠标操作 | 不支持 | 支持 |
| 树状进程图 | 需按V键 | F5一键切换 |
| 快捷键提示 | 需记忆 | 屏幕底部常驻 |
| 资源消耗 | 极低 | 略高 |
如果你只想看CPU的汇总统计而不关心具体进程，mpstat -P ALL 1是更好的选择，这个命令每秒刷新一次，列出每个CPU核心的使用率，在多核服务器上，它能帮你判断负载是否均匀分布在各个核心之间，若某个核心长期跑满而其他核心闲置,说明存在严重的资源不均衡。
多台欧拉服务器cpu监控方法：一条命令批量采集
管理大规模服务器集群时，逐台登录太浪费时间,推荐用pdsh或ansible做批量采集。
pdsh方式（适合临时查看）：
pdsh -w node01,node02,node03 "top -bn1 | head -20" | dshbak -c
这条命令会同时在多台节点执行top,并以汇总格式输出。
ansible方式（适合周期性采集）：
ansible all_servers -m shell -a "uptime && mpstat -P ALL 1 1 | tail -5"
配合cron定时任务将输出重定向到文件,还能形成简单的性能审计记录。
需要注意的是，批量命令对网络延迟敏感，如果节点超过50台，建议分批执行,避免造成管理网络拥塞。
常见服务（Nginx、MySQL）的CPU占用特征辨识
不同应用消耗CPU的方式有明显差异,熟悉这些特征能让你更快判断问题是否异常。
Nginx进程通常表现为多worker进程，每个worker的CPU占比相对均衡，如果某个worker CPU飙到100%，且长时间不回落，大概率是后端服务响应过慢导致worker阻塞，可以配合nginx -s reload平滑重启,再观察是否恢复。
MySQL数据库的CPU占用集中在mysqld进程内，若整体CPU占用偏高，进入MySQL执行SHOW FULL PROCESSLIST;，查看是否有大量慢查询堆积，常见情况是一条没走索引的SQL把CPU跑满，此时KILL 线程ID可以临时救急,根治还得靠优化SQL或补索引。
Java应用的CPU特征比较难判断，因为JVM内部线程很多，可以先看GC日志，如果Full GC频繁触发，CPU必然飙升，统计显示，相当一部分Java服务CPU异常都源自堆内存设置过小,导致JVM不断进行垃圾回收。
欧拉系统基于内核的特性：如何判断CPU占比是否异常
在欧拉系统上判断异常与否，不能只看当前数字,还要结合历史基线和负载均值。
uptime命令输出的load average包含1分钟、5分钟、15分钟三个数值，行业共识认为，load average长期高于CPU核心数，说明系统处于过载状态，比如一台4核服务器，load average在4.0左右算是刚好满载，超过6.0就意味着积压任务增多。
如果你想进一步排查内核层面的问题，可以查看/proc/stat文件，这个虚拟文件记录了CPU从开机以来的累计时间，连续采样两次cat /proc/stat | grep cpu，计算两次的差值，能准确算出真实的CPU使用百分比，这种方法比top更精确,适合写脚本做定时统计。
对于欧拉系统特有的openEuler内核，新版内核加入了更细粒度的调度统计，可以尝试使用cat /sys/kernel/debug/sched/debug（需要root权限）查看每个runqueue的负载情况,但日常运维一般用不到这么底层的信息。
高效排查建议：从现象到根因的思考路径
当你面对一台CPU占用异常的欧拉服务器，建议按照“确认范围 → 定位进程 → 分析代码 → 解决记录”四步走。
- 确认是单机问题还是集群共性问题，用pdsh批量查一遍所有服务器
- 用top锁定进程，用线程级分析找到具体执行逻辑
- 如果是自研代码，检查是否有循环遗漏break或大对象频繁分配
- 如果是开源组件，先查官方issue库，确认是否为已知bug
- 解决后务必在文档里记录当时的CPU基线、异常阈值、处理命令
这套路径能避免你每次都从头摸索，很多运维人员习惯一看到CPU高就重启服务，这只能暂时掩盖问题，通过欧拉系统自带的性能工具链perf top可以采样内核热点函数，帮你直接看到CPU时间花费在内核的哪个模块，比如网络收包软中断（NET_RX）占用过高，就该考虑调整网卡队列或开启RPS（Receive Packet Steering）。
最后补充一点，欧拉系统的CPU占比查看命令在国产化替代项目中已成为验收必测项，熟练掌握这些基本操作,对信创环境迁移和日常运维都有实际价值。
常见问题快速解答
问：欧拉系统查看cpu使用率命令与CentOS有区别吗？
答：基本没有区别，top、ps、mpstat这些核心命令在两款系统中用法一致，区别主要体现在包管理器上，欧拉使用dnf/yum，CentOS 7默认yum，CentOS 8改用dnf,但安装软件时的命令格式相同。
问：一台服务器CPU使用率100%但top里看不到高占用进程怎么办？
答：这种情况多为内核线程或不可中断进程（D状态）导致，执行ps -eo pid,ppid,stat,comm | grep D查看D状态进程，再用cat /proc/内核线程ID/stack查看其内核栈，若与I/O相关，用iostat -x 1确认磁盘等待时间。
问：欧拉系统top命令用法中按P排序后CPU数字不会刷新怎么办？
答：这是终端显示问题，执行top后先按t两次关闭或开启汇总行，再按P强制排序，若仍不刷新，执行top -d 1将刷新间隔设为1秒,适合高刷场景观察瞬时波动。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/617810.html
