故障定位¶

定位疑难杂症靠一套顺手的工具与案例积累，这里只保留实际会用的命令和一次真实案例。

🟢CPU¶

uptime                       # 平均负载
vmstat 1                     # 每秒 CPU/内存/IO
mpstat -P ALL 1              # 每核 CPU 使用率
pidstat -u 1 -p <PID>        # 指定进程 CPU
perf top -p <PID>            # 实时热点函数
perf record -F 99 -p <PID> -g -- sleep 30   # 采样 30s
perf report                  # 查看采样报告

跟踪进程的 write 输出用 strace，见常用命令。

🟢内存¶

free -h                      # 内存与交换区
vmstat 1                     # 关注 si/so（换入换出）
pidstat -r 1 -p <PID>        # 指定进程内存
pmap -x <PID>                # 进程内存映射明细
valgrind --tool=memcheck --leak-check=full ./your_program   # 内存泄漏

🟢磁盘 IO¶

iostat -x 1                  # 每块盘 IO 详情（%util、await）
iotop                        # 按进程看磁盘 IO
pidstat -d 1                 # 各进程读写速率
vmstat 1                     # 关注 wa 与 bi/bo
df -i                        # inode 使用（耗尽会无法建文件）

🟢网络¶

netstat -s                    # 各协议栈统计（丢包、重传、错误）
ss -lntup                     # 监听端口与进程
sar -n TCP,ETCP 1             # TCP 连接与异常统计
tcpdump -i eth0 -nn           # 抓包
mtr -r <host>                 # 定位丢包节点
nstat -az                     # TCP/UDP 计数
ethtool -S eth0               # 网卡硬件统计

🟢系统负载¶

uptime                       # 1/5/15 分钟平均负载
vmstat 1                     # 关注 r（运行队列）与 b（阻塞）
mpstat -P ALL 1              # 是否单核打满

Load 高不一定 CPU 忙，也可能是大量进程在等 IO。

🟢火焰图¶

# on-CPU：全系统采样 30s（-a 全部 CPU，-F 99 = 99Hz）
perf record -F 99 -a -g -- sleep 30
perf script | ./FlameGraph/stackcollapse-perf.pl | ./FlameGraph/flamegraph.pl > cpu.svg

# off-CPU：等 CPU/IO/锁 时用，需 bcc
sudo offcputime -df -p <PID> 30 > out.stacks
./FlameGraph/flamegraph.pl --color=io --title="Off-CPU Time" --countname=us out.stacks > offcpu.svg

# 差分火焰图（红=上升，蓝=下降），适合上线前后对比
./FlameGraph/difffolded.pl old.folded new.folded | ./FlameGraph/flamegraph.pl > diff.svg

看图要点：看顶层哪个函数最宽；出现"平顶"说明该函数可能有性能问题；颜色无特殊含义。

🟢案例：接入层 nginx 集群大量 499/5xx¶

现象：监控发现某时间点 nginx 集群请求出现大量 499、5xx，机器 CPU 升高并持续。

分析

请求流量没有突增，反而下降 → 与流量突增无关。
nginx 响应时间、upstream 响应时间均上升 → 猜测后端拖住 nginx。
top 发现 nginx worker CPU 高；perf top -p <PID> 显示开销集中在 free、malloc、json 解析。
用户态火焰图确认存在频繁的 json 解析，且该 json 库性能不高、占用 CPU 高。

深入：后端 upstream 响应慢最多影响 nginx 处理能力，不该让 nginx 内部模块 CPU 飙高；而 CPU 高的模块只有请求进来才走，说明并非 upstream 拖累触发。

解决：优先处理已知且明确的问题——降级关闭占用 CPU 过高的模块并观察。CPU 降下来后 nginx 流量也恢复正常。upstream 变慢的原因是后端接口可能存在环路，请求再次走回 nginx。