故障现象描述
近期，多家中小企业反馈其托管在云服务器或物理机上的Linux业务系统出现访问缓慢、请求超时甚至服务崩溃的现象。监控平台显示，服务器CPU利用率长期维持在90%以上，尽管内存和磁盘I/O看似正常，但高CPU负载直接导致了系统响应延迟增加。此类问题通常由异常进程、应用程序瓶颈或配置不当引起，需要系统性的排查思路。
第一步：确认负载真实情况
在深入排查前，必须区分是单核满载还是整体高负载，以及是用户态程序占用还是内核态系统调用占用。登录服务器后，首先执行以下命令：
- uptime：查看平均负载（Load Average）。如果1分钟负载远高于CPU核心数，说明存在严重排队。
- top -c：进入交互式界面，按
P键按CPU使用率排序，按M键按内存排序。注意观察%us（用户空间）和%sy（内核空间）的比例。
关键点：若%sy过高，通常意味着大量上下文切换、锁竞争或频繁的磁盘I/O等待；若%us过高，则通常是应用程序本身逻辑复杂或存在死循环。
第二步：精准定位消耗资源的进程
找到高CPU占用的PID（进程ID）后，需进一步分析该进程的具体线程或系统调用行为。
2.1 查看进程详情
使用ps aux | grep [PID]获取进程的启动命令、用户及资源占用历史数据，判断是否为预期内的业务进程。如果是未知的陌生进程，需警惕恶意挖矿病毒或木马。
2.2 查看线程级CPU占用
许多现代应用（如Java、Node.js）是多线程的，进程总CPU高可能由单个低效线程引起。执行：
top -H -p [PID]
这将列出该进程下的所有线程。记录占用CPU最高的线程ID（TID）。
2.3 转换线程ID为十六进制
为了便于后续调用栈追踪，需要将十进制TID转换为十六进制：
printf "%x\n" [TID]
第三步：深度分析根因
根据进程类型不同，采用不同的分析工具。
3.1 Java应用：使用Arthas或jstack
对于Java服务，线程往往阻塞在垃圾回收（GC）或同步锁上。
1. 使用jstack [PID]导出当前线程快照。
2. 搜索之前记录的十六进制TID，找到对应的栈信息。
3. 分析堆栈轨迹：如果是频繁Full GC，需检查内存泄漏或堆大小设置；如果是BLOCKED状态，需定位代码中的同步锁竞争点。
3.2 通用系统调用分析：使用perf或strace
如果不是Java应用，或无法直接获取源码，可使用perf工具进行采样分析：
perf top -p [PID]
该命令实时显示进程中消耗CPU最多的函数。如果大部分时间花在sys_write或sys_read，可能是日志输出过于频繁；如果花在tcp_sendmsg，则是网络发送瓶颈。
3.3 异常进程处理
若发现PID对应的是可疑脚本（如/tmp/.x.sh或随机命名的二进制文件），立即切断网络连接并杀掉进程，同时检查cron定时任务和系统计划任务，清除残留恶意文件。
第四步：优化与解决方案
定位根因后，采取相应措施：
- 代码级优化：修复死循环、减少不必要的日志打印、优化数据库查询SQL，避免全表扫描导致的CPU飙升。
- 配置级调整：对于Web服务器（如Nginx/Apache），调整worker_processes数量等于CPU核心数，避免上下文切换开销过大。限制并发连接数，防止瞬时流量洪峰打满CPU。
- 资源隔离：使用Cgroups或容器技术将关键业务与其他非关键任务（如备份、监控采集）隔离，确保核心服务不受干扰。
- 内核参数调优：适当调整
vm.swappiness减少Swap交换带来的性能抖动；优化net.core.somaxconn提升TCP连接处理能力。
总结
CPU满载故障排查遵循“确认负载->定位进程->分析线程/调用->实施优化”的标准流程。通过结合top、perf、jstack等工具，运维人员可以快速从表象深入到内核级或应用级的根本原因，从而制定有效的恢复策略，保障业务系统的稳定运行。