服务器 CPU 突然飙到 100%，这样排查处理不背锅！

民工哥

发布于 2026-03-24 15:31:30

890

— 特色专栏 —

MySQL/PostgreSQL/MongoDB

ElasticSearch/Hadoop/Redis

Kubernetes/Docker/DevOps

Kafka/RabbitMQ/Zookeeper

监控平台/应用与服务/集群管理

Nginx/Git/Tools/OpenStack

大家好，我是民工哥！

服务器 CPU 突然飙到100%！莫慌，这样排查处理不背锅。

某个周末的下午，你正在悠闲的喝着咖啡，享受着假日的惬意之时。突然，手机收到一条紧急信息，公司业务服务器监控报警，显示CPU突然飚升至100%，已经持续近几分钟，还没来的及查看完整信息，老大的夺命Call 就已经打进来了，公司业务已经受到很大影响，如果不及时处理好，怕不是要在公司过周末了，还有可能当一回背锅侠。

类似这样的场景，我想多数人都会遇到过。

今天，我们就一起探讨一下，遇到类似问题，如何紧急排查，快速处理好不背锅。

当服务器CPU飙升至100%时，快速定位根因是恢复系统稳定性的关键。

教你三招，保证招招见效。

第一招：快速定位高负载进程

可以使用 top/htop 命令！

操作步骤

执行命令：

top -c  # 显示进程列表及完整命令路径

# 或使用更友好的htop（需安装）htop

观察关键指标：

按Shift + P按CPU使用率排序，快速找到占用最高的进程。
记录进程PID、用户、命令及CPU占比（如java进程占95%）。

初步判断：

系统进程（如kthreadd、rcu_sched）：可能是内核问题或硬件故障。
应用进程（如nginx、mysql）：可能是代码逻辑错误或配置问题。
未知进程：可能是恶意软件或未授权服务。

示例输出：

PID   USER      COMMAND                  %CPU
1234  mysql     /usr/sbin/mysqld        95.2
5678  root      /usr/bin/python3 script.py 88.7

相关命令更多参数与实例学习可以参考以下文章：每天学一个 Linux 命令（48）：top

第二招：perf/strace深入分析进程行为

场景1：CPU占用高但无明显进程（如内核态问题）

操作步骤：

使用perf抓取系统调用：

perf top -s comm,dso  # 实时显示函数调用耗时

观察overhead高的函数（如__schedule、ext4_file_write），定位内核或文件系统问题。

检查中断和软中断：

cat /proc/interrupts  # 查看中断分布
mpstat -P ALL 1       # 查看各CPU核心的中断/软中断占比

若某核心si（软中断）或hi（硬中断）占比过高，可能是网络或磁盘I/O问题。

场景2：应用进程CPU高（如Java/Python）

操作步骤：

使用strace跟踪系统调用

strace -p <PID> -c  # 统计系统调用耗时

若read/write频繁且耗时长，可能是I/O瓶颈；若poll/select多，可能是阻塞操作。

针对Java应用使用jstack：

jstack <PID> > thread_dump.log  # 生成线程堆栈

搜索BLOCKED或RUNNING状态线程，定位死锁或循环计算。

针对Python应用使用py-spy：

py-spy top --pid <PID>  # 实时显示Python函数调用

观察耗时最长的函数（如numpy计算或数据库查询）。

第三招：vmstat/iostat 排查资源竞争

场景1：CPU高且I/O等待严重

操作步骤：

使用vmstat检查上下文切换

vmstat 1  # 每秒刷新一次

观察cs（上下文切换次数）和in（中断次数）：

若cs > 10000/秒，可能是多线程竞争或频繁创建线程。
若in高且%usr低，可能是硬件中断（如网卡）占用CPU。

使用iostat检查磁盘I/O**：

iostat -x 1  # 显示设备I/O统计

观察%util（设备利用率）和await（I/O等待时间）：
若%util接近100%且await高，可能是磁盘性能瓶颈。

场景2：CPU高且内存不足

操作步骤：

使用free -h检查内存：

free -h  # 显示内存使用情况

若buff/cache占用高但available低，可能是内存泄漏或缓存未释放。

使用sar检查交换分区：

sar -r 1  # 每秒显示内存和交换分区使用

若kbswpd（交换分区使用量）持续增加，可能是物理内存不足导致频繁交换。

综合案例：Java应用CPU 100%定位

top发现java进程占95% CPU。

jstack生成线程堆栈，发现多个线程卡在MySQL查询。

vmstat显示cs高达20000/秒，推测线程池配置不合理导致频繁创建线程。

优化线程池大小并优化SQL查询，CPU降至10%。

每天学一个 Linux 命令（112）：vmstat

每天学一个 Linux 命令（109）：iostat

总结

3分钟定位流程图！

1.top/htop → 找到高CPU进程
   ├─ 系统进程 → perf/mpstat → 内核/中断问题
   └─ 应用进程 → 
      ├─ Java → jstack → 线程阻塞/死锁
      ├─ Python → py-spy → 函数耗时
      └─ 其他 → strace → 系统调用分析
2.vmstat/iostat → 排查I/O/内存竞争
3.结合日志/监控 → 验证根因并修复

通过以上三招，可快速区分问题类型（计算密集型、I/O密集型、资源竞争），并精准定位到代码层、系统层或硬件层，大幅缩短故障恢复时间。

其实，我们日常工作还是要以预防为主，处理为辅的管理方针。

监控与预防CPU高占用问题需要构建多层次、主动式、自动化的防御体系，涵盖实时监控、预警机制、容量规划、代码规范和安全防护等方面。

实时监控：全链路数据采集

进程级监控

工具：top、htop、pidstat、Prometheus + Node Exporter

关键指标：

每个进程的CPU使用率（%CPU）
进程的线程数/子进程数（防止线程爆炸）
进程的内存占用（RSS/VMS，避免内存泄漏引发交换）

示例：

pidstat -t -p <PID> 1  # 监控指定进程的线程级CPU占用

系统级监控

工具：vmstat、mpstat、iostat、sar（Sysstat工具包）

关键指标：

CPU整体使用率（%usr、%sys、%idle）
上下文切换率（cs，>10,000/秒可能有问题）
运行队列长度（r，>CPU核心数×2需警惕）
中断处理（%hi硬中断、%si软中断）

示例：

mpstat -P ALL 1  # 查看各CPU核心的使用率
vmstat 1 5      # 每秒1次，共5次，观察上下文切换

资源竞争监控

工具：perf、bcc-tools（eBPF工具集）

关键指标：

锁竞争次数（perf stat -e cache-misses,context-switches）
调度延迟（bcc-tools中的runqlat）
内存分配延迟（perf stat -e mem_load_retired.l1_miss）

示例：

perf stat -e cache-misses,context-switches sleep 10  
# 统计10秒内的缓存未命中与上下文切换

硬件与内核监控

工具：dmesg、sensors、smartctl（磁盘健康）

关键指标：

CPU温度（sensors显示Core 0温度>85℃需预警）
内存错误（dmesg | grep -i "memory error"）
磁盘坏道（smartctl -a /dev/sda | grep "Reallocated_Sector_Ct"）

示例：

watch -n 1 "sensors | grep 'Core 0'"  # 实时监控CPU温度

预警机制

建立阈值与动态基线！

静态阈值预警

规则：

单进程CPU占用>80%持续5分钟 → 触发告警
系统%usr+%sys>90%持续3分钟 → 触发告警
上下文切换率>15,000/秒 → 触发告警

工具：

Prometheus + Alertmanager（配置告警规则）
Zabbix（设置触发器）

示例（Prometheus规则）：

groups:
-name:cpu-alerts
rules:
-alert:HighProcessCPU
    expr:max(rate(process_cpu_seconds_total[1m]))by(instance,name)>0.8
    for:5m
    labels:
      severity:critical
    annotations:
      summary:"Process {{ $labels.name }} on {{ $labels.instance }} has high CPU usage"

动态基线预警

方法：

使用机器学习（如Prophet）预测CPU使用率趋势。
对比历史同期数据（如工作日/周末模式）。

工具：

Elastic Stack（ML模块）
Grafana（动态阈值面板）

示例：Grafana中设置“异常检测”算法，自动识别偏离基线的CPU spike。

关联分析预警

规则：

CPU高占用 + 磁盘%util>90% → 可能是I/O等待导致假高。
CPU高占用 + 网络retransmits>100/秒 → 可能是网络阻塞。

工具：

ELK Stack（日志+指标关联分析）
Splunk（事务搜索）

示例：

index=metrics cpu.usage>90 AND index=network retransmits>100 | stats count

容量规划：预防性资源扩容

历史数据回溯

方法：

分析过去3个月的CPU使用率峰值（sar -q）。
识别周期性高峰（如每月1号的报表任务）。

工具：

Grafana（时间序列分析）
Python + Pandas（自定义脚本）

示例：

import pandas as pd
df = pd.read_csv('cpu_usage.csv', parse_dates=['timestamp'])
df.set_index('timestamp').resample('D').max().plot()  # 按天绘制峰值

弹性扩容策略

云环境：

AWS Auto Scaling：根据CPU使用率自动增减实例。
Kubernetes HPA（Horizontal Pod Autoscaler）：基于CPU指标扩容Pod。

物理机：

预留20%的CPU余量（如8核服务器最多跑6核负载）。

示例（Kubernetes HPA）：

apiVersion: autoscaling/v2
kind:HorizontalPodAutoscaler
metadata:
name:nginx-hpa
spec:
scaleTargetRef:
    apiVersion:apps/v1
    kind:Deployment
    name:nginx
minReplicas:2
maxReplicas:10
metrics:
-type:Resource
    resource:
      name:cpu
      target:
        type:Utilization
        averageUtilization:70# CPU使用率>70%时扩容

负载测试

方法：

使用locust或jmeter模拟高并发场景。
观察CPU使用率、响应时间、错误率。

工具：

k6（轻量级负载测试）
Gatling（HTTP负载测试）

示例（k6脚本）：

import http from 'k6/http';
export let options = { vus: 100, duration: '1m' };
export default function() {
  http.get('https://example.com/api');
}

代码与配置优化：从源头减少负载

代码优化

规则：

避免在循环中创建对象（如Java的String拼接）。
使用异步I/O（如Node.js的fs.promises）。
限制线程池大小（如Java的ThreadPoolExecutor）。

工具：

JProfiler（Java性能分析）
Py-Spy（Python性能分析）

示例（Java线程池优化）：

ExecutorService executor = new ThreadPoolExecutor(
    4,  // 核心线程数=CPU核心数
    8,  // 最大线程数
    60, TimeUnit.SECONDS,
    new LinkedBlockingQueue<>(100)  // 队列容量限制
);

数据库优化

规则：

为查询字段添加索引（如MySQL的ALTER TABLE users ADD INDEX (name)）。
避免SELECT *，只查询必要字段。
使用连接池（如HikariCP）。

工具：

pt-query-digest（MySQL慢查询分析）
pgBadger（PostgreSQL日志分析）

示例（MySQL索引优化）：

EXPLAIN SELECT * FROM orders WHERE user_id = 100;  -- 检查是否使用索引

系统配置优化

规则：

调整内核参数（如/etc/sysctl.conf中的net.core.somaxconn）。
限制进程资源（如cgroups或ulimit）。
禁用不必要的服务（如systemctl disable unused-service）。

工具：

tuned（Red Hat的性能调优工具）
sysbench（基准测试）

示例（限制进程内存）：

echo "java -Xmx512m -Xms512m -jar app.jar" > /etc/systemd/system/app.service
systemctl daemon-reload

五、安全防护：防止恶意占用

入侵检测

工具：

Fail2ban（阻止暴力破解）
OSSEC（主机入侵检测）

规则：

监控/tmp目录下的可执行文件。
禁止root远程登录（PermitRootLogin no）。

示例（Fail2ban配置）：

[sshd]
enabled = true
port = ssh
filter = sshd
action = iptables-multiport[name=SSH, port="ssh", protocol=tcp]
maxretry = 3

挖矿程序防护

规则：

监控异常进程名（如xmrig、kworkerds）。
限制外联流量（如仅允许必要端口出站）。

工具：

ClamAV（病毒扫描）
Snort（网络入侵检测）

示例（阻止挖矿域名）：

echo "0.0.0.0 pool.miningpool.com" >> /etc/hosts

DDoS防护

工具：

Cloudflare（CDN防护）
AWS Shield（云上DDoS防护）

规则：

限制单个IP的请求速率（如Nginx的limit_req_zone）。
启用TCP SYN保护（net.ipv4.tcp_syncookies=1）。

示例（Nginx限流）：

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
server {
    location / {
        limit_req zone=one burst=5;
    }
}

自动化与持续改进

自动化巡检

工具：

Ansible（批量执行检查脚本）
Jenkins（定时运行监控任务）

示例（Ansible）：

- name:CheckCPUusage
hosts:all
tasks:
    -command:top-bn1|head-10
      register:cpu_output
    -debug:var=cpu_output.stdout

日志集中分析

工具：

ELK Stack（日志+指标关联）
Loki + Promtail（轻量级日志聚合）

示例（Loki查询）：

{job="nginx"} |= "error" | rate([5m]) > 0.1  # 错误率>10%/5分钟

性能回归测试

方法：

每次代码部署前运行基准测试。
对比部署前后的CPU使用率。

工具：

GitLab CI（集成性能测试）
Jenkins Pipeline（自动化测试）

示例（GitLab CI任务）：

performance_test:
  stage:test
script:
    -locust-fload_test.py--users=100--spawn-rate=10--run-time=1m
    -pythonanalyze_results.py# 分析CPU使用率是否超阈值

总结

维度	关键措施
实时监控	进程级/系统级指标采集，使用Prometheus、eBPF等工具。
预警机制	静态阈值+动态基线+关联分析，结合Alertmanager、Grafana。
容量规划	历史数据回溯、弹性扩容、负载测试，使用Kubernetes HPA、AWS Auto Scaling。
代码优化	算法优化、异步I/O、线程池限制，使用JProfiler、Py-Spy。
安全防护	入侵检测、挖矿程序防护、DDoS防护，使用Fail2ban、Cloudflare。
自动化	巡检自动化、日志分析、性能回归测试，使用Ansible、ELK Stack。