一键登录 更安全快捷
获取验证码
密码登录
验证码登录
登录
登录/注册
0
收藏
Linux服务器CPU持续跑满100%是运维高频故障，单纯执行top只能定位进程，无法区分进程内部哪条线程产生消耗。标准排查链路以top、htop、top -H作为核心观测工具，先从整机维度区分用户us、内核sy、软中断si、空闲idle，定位高负载进程；再开启线程视图top -H穿透至线程级别，锁定消耗CPU的目标线程ID；配合pidstat、perf、gstack、jstack等工具追溯代码调用栈，区分业务死循环、内核开销、中断风暴、虚拟机调度争抢等不同根因，形成一套自上而下标准化故障排查闭环。
有VMware全系列产品官方资源和定制版资源需求的可以移步：
1. top头部CPU行指标含义（判断负载大类）%Cpu(s): us — user 用户态CPU（业务应用代码消耗） sy — system 内核态CPU（系统调用、内核逻辑） ni — nice 低优先级进程 id — idle 空闲CPU wa — iowait IO等待（并非CPU繁忙，而是等待磁盘） hi — hardirq 硬中断 si — softirq 软中断 st — steal 窃取时间（虚拟机宿主机资源争抢核心指标）
2. 根据指标快速归类故障方向1）us高、id接近0：业务应用代码占用CPU，重点排查业务进程死循环、大量计算； 2）sy高：频繁系统调用、频繁上下文切换、内核模块异常、大量小IO； 3）si持续走高：软中断风暴（网络收包、定时器、内核工作队列）； 4）wa很高：不是CPU瓶颈，属于存储IO瓶颈，转向iostat排查磁盘； 5）st持续偏高：虚拟机环境，宿主机CPU资源紧张，宿主机其他虚拟机抢占vCPU。
3. top基础交互快捷键P：按CPU使用率排序；M：内存排序； 1：展开所有CPU核心，查看是否单核打满、多核不均衡； k：交互式杀死指定PID； z：开启色彩显示； 默认只展示进程粒度，看不到内部线程，无法深入定位。
1. top -H 核心作用top默认显示进程（PID），一个进程下多条线程共享同一个PID；top -H 参数开启线程模式，展示所有独立线程TID，能够直接找到进程内部消耗CPU的具体线程。 两种使用方式： 方式1：直接全局查看所有线程 top -H 方式2：只观察指定进程内部线程（推荐，减少干扰） top -H -p <PID>
2. 实操标准流程1. top 找到高CPU进程 PID； 2. 执行 top -H -p PID，观察进程内所有线程CPU占用； 3. 记录CPU最高的线程TID（十进制）； 4. 将十进制TID转为十六进制，用于在线程栈中检索对应线程； 转换示例：printf "%x\n" 12345
3. 典型场景举例（Java服务CPU100%经典故障）1. top发现java进程占用CPU接近100%； 2. top -H -p <java-pid> 找到高负载线程TID； 3. printf转16进制； 4. jstack <pid> > thread.log； 5. 在日志中搜索十六进制nid，直接定位到出问题的Java方法死循环。
4. htop 作为top增强替代方案htop属于交互式增强工具，优势： 可视化更强、支持鼠标操作；按H一键切换显示线程；支持树形展示进程父子关系；可直接显示CPU、内存、优先级。 不足：很多最小化系统默认未预装，生产服务器不一定具备；内核精简环境优先使用原生top，无需额外安装软件包。
1. pidstat -u -t 2 （进程+线程级CPU持续采样）持续输出每个进程/线程usr、system占用，适合长时间观测负载变化趋势，区分瞬时峰值还是持续满载。
2. perf top（内核/函数级别采样，无代码也能定位）无需重启服务，实时采样CPU占用最高的函数； 适用场景： C/C++程序、内核开销高、无法抓取线程栈、大量系统调用场景； perf top -g 可开启调用图，查看函数调用链路。
3. ps 组合筛选命令（脚本化批量检索）查看指定进程所有线程：ps -T -p PID
场景1：业务应用用户态CPU跑满 us很高特征：top中us高，进程CPU持续满载； 排查路径：top → top -H -p PID → 获取TID → 导出线程栈（jstack/gstack/pstack），定位死循环、正则回溯、密集计算逻辑。
场景2：内核态sy持续偏高特征：sy指标上涨，业务代码无密集计算； 诱因：频繁创建销毁线程、大量短连接、频繁文件open/close、海量小数据包收发； 工具：perf top查看内核函数开销。
场景3：软中断si高，整机CPU打满特征：单个CPU核心100%，si很高，没有明显高负载业务进程； 常见：网卡大量小包、DDOS、内核网络处理线程耗尽单核； 查看：cat /proc/softirqs。
场景4：虚拟机内部CPU满载，st窃取时间高特征：虚拟机内部CPU持续100%，st不为0； 根因：ESXi/KVM宿主机CPU资源争抢，宿主机负载过高，vCPU调度延迟； 排查：登录宿主机观察整体负载，调整虚拟机CPU调度、资源配额。
场景5：单核CPU打满，多核空闲（最容易被忽略）现象：整机平均负载看着不高，但单个核心100%，业务卡顿； 诱因：应用单线程执行密集任务（单线程GC、单线程任务队列、锁竞争串行处理）； 排查：top按1展开各核心，结合top -H找到这条繁忙线程。
1. top 按1展开所有CPU核心，确认是单核满载还是多核全部跑满； 2. 记录%Cpu(s) us/sy/si/st/wa，区分负载大类； 3. 按P排序，记录占用最高的进程PID； 4. top -H -p PID，进入线程视图，抓取最高占用线程TID； 5. printf "%x" TID，转为十六进制线程ID； 6. 根据语言抓取线程快照：Java用jstack，C/C++用gstack/pstack； 7. 在栈文件搜索十六进制TID，定位业务代码位置； 8. 若无明显业务线程，则执行perf top，排查内核、中断开销； 9. 虚拟机环境额外关注st窃取时间，确认是否宿主机资源瓶颈。
1. 误区：只使用top看进程CPU，不执行top -H，找不到根因纠正：一个进程多条线程，top进程维度只能看到总占用，无法定位哪一段逻辑消耗CPU，这是线上最常见卡壳点。
2. 误区：CPU 100%一定是业务代码问题纠正：wa高是IO瓶颈，si高是软中断，虚拟机st高是宿主机争抢，不属于应用代码问题，盲目重启业务无效。
3. 误区：htop功能更强，所有环境优先htop纠正：最小化CentOS、容器精简镜像默认不带htop；紧急故障优先使用系统自带top、top -H，避免yum安装工具耽误排障。
4. 误区：负载平均值load average等于CPU使用率纠正：load average代表等待运行队列任务数量，CPU空闲也可能load很高（大量D进程不可中断睡眠），必须结合%Cpu指标综合判断。
5. 误区：线程TID十进制直接在线程栈文件搜索纠正：jstack等工具输出线程ID是十六进制nid，不转换格式无法检索，大量运维卡在这一步。
6. 误区：多核CPU看到整机平均70%负载，业务就不会卡顿纠正：应用单线程模型会出现单核打满、其他核心空闲，整机平均负载不高，但业务响应缓慢；必须用top 1观察单核心状态。
Linux CPU使用率100%标准排查工具链路：top宏观整机分析定位进程，top -H进入线程视图定位消耗CPU的线程，htop作为增强交互式备选工具。先通过top区分用户态、内核态、软中断、IO等待、虚拟机steal时间，判定故障大类；再利用top -H穿透至线程粒度，获取高负载线程TID，配合线程栈、perf性能采样工具定位到具体代码或内核函数。需要重点区分：业务代码死循环、内核系统调用开销、软中断风暴、存储IO等待、虚拟机宿主机CPU争抢、单核瓶颈等不同场景，避免笼统重启服务而找不到根本原因。线上紧急故障优先使用系统原生top/top -H，不依赖额外安装组件，保证排障及时性。
