一、总体思路（核心方法论）

可以记住一个统一模型：

👉 “现象 → 定位 → 分析 → 归因 → 处置 → 预防”

对应拆解：

二、CPU告警排查（高CPU 100%）

1️⃣ 快速判断（1分钟内）

uptimetop

重点看：

• load average（负载）
• us（用户态）
• sy（内核态）
• wa（IO等待）

👉 判断方向：

2️⃣ 定位高CPU进程

top -cps -eo pid,ppid,cmd,%cpu --sort=-%cpu | head

👉 找出：

• 哪个进程占用最高
• 是否持续占用

3️⃣ 定位线程级问题（关键）

top -H-p <pid>或：ps -mp <pid> -o THREAD,tid,time

👉 结合：

printf "%x\n" <tid>

用于分析 Java：

jstack <pid>

4️⃣ 深入分析工具

🔹 perf（生产级）

perf topperf record -p <pid>perf report

👉 分析热点函数（CPU耗在哪）

🔹 strace（系统调用）

strace -p <pid>

👉 判断是否：

• 死循环
• IO卡住
• 频繁系统调用

🔹 pidstat（趋势分析）

pidstat -u1

5️⃣ 常见原因总结

6️⃣ 应急处理

kill -15 <pid>kill -9 <pid>   # 最后手段

或：

• 限流（Nginx / 网关）
• 扩容（K8s / VM）
• 降级（关闭非核心功能）

三、内存告警排查（OOM / 内存高）

1️⃣ 快速判断

free -m

重点：

• used
• available
• swap

2️⃣ 内存结构分析

cat /proc/meminfo

关键指标：

👉 注意：

❗ Linux “内存高 ≠ 问题”，缓存可回收

3️⃣ 定位内存占用进程

ps aux --sort=-%mem | head

4️⃣ 深入分析（核心）

🔹 pmap

pmap -x <pid>

🔹 smem（更精准）

smem -rk

🔹 top + RES

关注：

• RES（真实内存）
• VIRT（虚拟内存）

5️⃣ OOM 排查（关键）

dmesg | grep -i oom

或：

journalctl -k | grep -i oom

👉 看：

• 被杀进程
• OOM原因

6️⃣ 内存泄漏判断

👉 特征：

• 内存持续上涨
• 不释放

工具：

valgrind

Java：

jmap -heap <pid>jmap -dump:format=b,file=heap.hprof <pid>

7️⃣ 常见原因总结

8️⃣ 应急处理

echo 1 > /proc/sys/vm/drop_caches

（⚠️慎用）

或：

• 重启服务
• 降低缓存
• 扩容内存

四、CPU + 内存联动问题（重点）

很多事故是组合型问题：

五、SRE级排查流程（面试可直接讲）

👉 标准流程：

1. 告警触发（Prometheus/Zabbix）2. 快速确认（top/free/uptime）3. 定位进程（ps/top）4. 线程分析（top -H）5. 深度分析（perf/strace）6. 判断类型（CPU型/IO型/内存型）7. 应急处理（kill/限流/扩容）8. 根因分析（代码/架构）9. 复盘（监控 + 自动化）

六、生产级最佳实践（重点加分）

✅ 1. 监控体系

• CPU、Load、Memory、Swap
• 进程级监控
• JVM监控（GC）

✅ 2. 限制机制

ulimitcgroup

✅ 3. 自动化防护

• OOM自动重启
• CPU异常自动限流
• 熔断机制

✅ 4. 容量规划

• 预留30%资源
• 峰值压测

七、一句话总结（面试金句）

👉 CPU问题本质是“算不过来”，内存问题本质是“装不下”，而SRE要做的是“提前避免”而不是“事后处理”。