故障背景与现象
在企业IT运维日常中，服务器性能突降是最高频且紧急的故障之一。近期，某中小型企业生产环境的Linux应用服务器出现响应极度缓慢的情况，业务端反馈页面加载超时，甚至出现服务不可用的状态。通过初步观察，系统负载（Load Average）远超正常阈值，且部分关键进程无响应。此类现象通常指向CPU资源耗尽，但若仅通过重启服务临时缓解，未找到根本原因，故障极易复发。
第一步：全局性能监控与指标确认
接到报警后，首要任务是量化故障程度。登录服务器后，执行 uptime 命令查看系统负载。若平均负载持续高于CPU核心数，则确认为性能瓶颈。
同时，使用 mpstat -P ALL 1 或 dstat 工具观察各CPU核心的利用率。重点关注两个指标：
1. %us (User Space)：用户空间程序占用的CPU百分比。
2. %sy (System Kernel)：内核空间占用的CPU百分比。
若 %sy 异常偏高，可能涉及大量上下文切换、I/O等待或内核锁竞争；若 %us 偏高，则多为应用程序计算密集或逻辑死循环。
第二步：定位高消耗进程
利用 top 命令进入交互式界面，按 'P' 键根据CPU使用率排序。此时通常会发现某个或某几个PID占据绝大部分CPU资源。
注意： 如果发现进程名为 kthreadd 或带有随机字符命名的进程，需警惕是否为挖矿木马。top 可能无法直接显示完整路径，此时需结合 ps 命令获取更多信息：ps aux --sort=-%cpu | head -n 10
获取PID后，通过 ls -l /proc/{PID}/exe 查看进程实际执行文件路径，判断其合法性。
第三步：深入分析进程行为
确定目标进程PID后，单一使用 top 往往不够。建议使用 pidstat 进行细粒度监控。例如：pidstat -p {PID} 1
该命令可展示该进程每秒的系统调用次数、上下文切换次数等细节。若上下文切换（cswch/s）极高，说明进程可能在频繁争夺资源；若阻塞IO（blocked）较高，可能涉及磁盘I/O瓶颈导致的伪CPU高占用（实际上是在等待I/O完成，但被调度器视为活跃）。
此外，使用 strace -p {PID} 跟踪进程系统调用。观察其是否在重复执行相同的错误操作，例如无限重试数据库连接、陷入死循环读取空文件等。这一步对于定位“业务逻辑导致的高CPU”至关重要。
第四步：常见根因与解决方案
1. 应用程序逻辑缺陷（死循环/低效算法）
许多开发人员在代码编写时未考虑边界条件，导致特定请求触发无限循环。例如，Java应用中未正确设置线程池大小，或Python脚本中存在死递归。
解决措施： 联系开发人员审查相关模块日志，启用应用层面的APM（应用性能监控）工具（如SkyWalking或Pinpoint）定位耗时最长的代码行。临时方案为限制该用户的并发连接数或重启应用实例。
2. 恶意挖矿程序感染
若发现可疑进程，且其路径位于 /tmp、/var/tmp 或隐藏目录（以点开头的文件夹），极大概率为已被入侵。
解决措施：
- 立即断开服务器外网连接，防止数据外传或控制指令下发。
- 使用 kill -9 {PID} 强制终止进程。
- 查找并删除对应的恶意脚本或二进制文件。
- 检查 crontab 任务列表 crontab -l 以及 /etc/cron.d/ 目录，移除持久化驻留项。
- 全面扫描SSH密钥，更换所有弱口令，修补已知漏洞（如Log4j2、Struts2等）。
3. 内核态异常（中断风暴或锁竞争）
当 top 显示大部分CPU消耗在内核态，且没有明确的用户进程主导时，可能是网卡中断过多（IRQ Balance问题）或驱动程序Bug。
解决措施： 检查 /proc/interrupts，观察哪个CPU核心处理的中断最多。必要时调整中断亲和性（Affinity）。同时检查 dmesg 日志，看是否有硬件错误或驱动报错。
总结与建议
CPU高占用排查并非简单的“杀进程”，而是一套完整的诊断闭环。建议企业建立标准化的运维响应流程：
1. **监控前置**：配置Zabbix或Prometheus+Grafana，设置CPU、Load、进程数量的分级告警。
2. **日志归档**：确保应用日志和系统日志集中收集，便于事后回溯。
3. **定期巡检**：对生产环境进行定期的基线对比，识别异常的资源使用模式。
通过规范化的排查步骤，不仅能快速恢复业务，更能从根源上提升系统的稳定性和安全性。