1. Linux性能排查实战：从“系统慢”到精准定位
遇到服务器卡顿，新手运维常会手忙脚乱地重启服务，而老鸟则像侦探一样抽丝剥茧。我刚入行时曾用3小时重启了8次Nginx，直到 mentor 扔给我一串 top 命令。本文将分享我十年运维生涯总结的 Linux 性能排查方法论，这套黄金法则在电商大促、游戏开服等高压场景中反复验证有效。
性能问题的本质是资源争夺战。CPU、内存、磁盘I/O、网络这四大资源就像高速公路的车道，当某个方向的车辆（进程）过多，就会引发连锁拥堵。我们排查时要先确定堵点在哪条"车道"，再揪出制造拥堵的"车辆"（进程），最后判断是"车辆"太多（资源不足）还是"车辆"故障（程序BUG）。
2. 核心排查框架：三步定位法
2.1 第一步：定方向 - 四大资源快速诊断
执行这组命令能在10秒内锁定问题方向：
bash复制# 综合快照（建议开多个终端并行运行）
top -b -n 1 | head -5 # CPU/memory概况
vmstat 1 3 # 系统整体负载
iostat -x 1 3 # 磁盘I/O压力
sar -n DEV 1 3 # 网络流量
关键指标解读技巧：
- CPU：top输出的%Cpu(s)行中：
- us > 70% 用户态进程吃满CPU
- sy > 30% 内核态消耗异常
- wa > 20% 存在I/O等待瓶颈
- 内存：free -h中的available值：
- 低于总内存10%需警惕
- Swap使用量突然增长是危险信号
- 磁盘：iostat的%util：
- HDD > 60% 即过载
- SSD > 80% 需关注
- 网络：sar的rxkB/s+txkB/s：
- 超过网卡带宽70%可能引发丢包
2.2 第二步：抓进程 - 精准定位元凶
确定问题方向后，用进程级工具深挖：
bash复制# CPU型问题
pidstat -u 1 -p ALL | sort -k8 -nr | head
# 内存型问题
pidstat -r 1 -p ALL | awk '$8>1000{print}' # 筛选RSS>1GB的进程
# I/O型问题
iotop -oP -b -n 3 | grep -v "0.00%"
# 网络型问题
ss -antp | awk '{print $1}' | sort | uniq -c | sort -nr
避坑指南：容器环境下直接运行这些命令可能看不到真实进程，需进入容器命名空间：
bash复制nsenter -t <容器PID> -n -p -- ps aux
2.3 第三步：下结论 - 构建证据链
典型案例推理过程：
- 发现MySQL响应慢
- top显示wa高达45%
- iostat看到sdb的await=120ms
- iotop定位到mysqld进程大量写操作
- 结论：MySQL的binlog写入导致磁盘I/O瓶颈
3. CPU深度排查：不只是看使用率
3.1 多维度CPU分析
bash复制# 查看CPU运行队列（比load average更实时）
sar -q 1 3 | grep runq
# 分析上下文切换情况
pidstat -w 1 | grep -v "0.00"
# 检测软中断分布
watch -n 1 'cat /proc/softirqs'
性能图谱：
- 高us + 正常sy → 应用代码问题
- 高sy + 高cs → 锁竞争或进程频繁切换
- 高si + 高网卡中断 → 网络包处理瓶颈
3.2 火焰图实战
安装perf工具生成火焰图：
bash复制# 记录调用栈
perf record -F 99 -p <PID> -g -- sleep 30
# 生成SVG图
perf script | stackcollapse-perf.pl | flamegraph.pl > flame.svg
分析要点：
- 平顶山状：热点函数集中
- 锯齿状：调用链过长
- 空白间隙：内核态等待
4. 内存排查：破除free的误解
4.1 真实内存计算
bash复制# 计算应用程序真实内存占用
awk '{total = $2-$5-$6-$7} END {print total/1024"MB"}' /proc/meminfo
| 内存类型 | 计算方式 | 危险阈值 |
|---|---|---|
| 应用可用内存 | MemAvailable | < 总内存5% |
| OOM风险指数 | CommitLimit-Committed_AS | < 0时触发OOM |
| 缓存有效性 | (Cached)/(Cached+Free) | < 30%时缓存命中率下降 |
4.2 内存泄漏追踪
bash复制# 监控进程内存增长趋势
watch -n 1 'ps -eo pid,rss,comm | grep <进程名>'
# 生成内存分配报告
valgrind --tool=memcheck --leak-check=full ./program
关键经验：当发现kswapd0进程持续高CPU时，说明系统在进行激进的内存回收，此时性能已严重受损。
5. 磁盘I/O排查：区分IOPS与吞吐量
5.1 性能基准测试
bash复制# 随机读写测试（OLTP场景）
fio --name=randread --ioengine=libaio --rw=randread --bs=4k --numjobs=4 --size=1G --runtime=60 --time_based
# 顺序读写测试（大数据场景）
fio --name=seqwrite --ioengine=libaio --rw=write --bs=1M --numjobs=1 --size=10G --runtime=60
5.2 实时I/O分析
bash复制# 查看块设备详细统计
cat /proc/diskstats | grep sda
# 跟踪系统调用
strace -p <PID> -e trace=read,write,fsync
性能拐点：
- 机械硬盘：IOPS > 200 或吞吐 > 150MB/s
- SATA SSD：IOPS > 50k 或吞吐 > 500MB/s
- NVMe SSD：IOPS > 500k 或吞吐 > 3GB/s
6. 网络排查：超越ping的维度
6.1 全链路分析
bash复制# 连接状态统计
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
# 数据包捕获（需root）
tcpdump -i eth0 -w /tmp/dump.pcap host 10.0.0.1 and port 80
6.2 内核参数调优
bash复制# 缓解TIME_WAIT过多
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
# 调整缓冲区大小
sysctl -w net.core.rmem_max=16777216
网络性能矩阵：
- 延迟敏感型：优化TCP_NODELAY
- 吞吐量型：调大缓冲区
- 连接数型：增加文件描述符限制
7. 高级工具链配置
7.1 性能监控全家桶
bash复制# 安装BPF工具集
yum install -y bcc-tools
# 常用BPF工具：
/usr/share/bcc/tools/execsnoop # 监控新进程
/usr/share/bcc/tools/opensnoop # 监控文件打开
/usr/share/bcc/tools/tcplife # TCP连接生命周期
7.2 可视化分析方案
- 使用Grafana+Prometheus搭建监控平台
- 关键指标仪表盘配置：
- node_exporter的CPU steal指标（针对云主机）
- diskstats的await指标
- 网络TCP重传率
8. 经典案例复盘
8.1 案例一：CPU steal引发的血案
现象：云主机CPU us很低但服务响应慢
排查：
- mpstat -P ALL 发现%steal高达30%
- 联系云厂商确认物理机负载
- 解决方案：迁移到专属宿主机
8.2 案例二：内存泄漏的捉鬼记
现象：服务每隔3天必挂
排查：
- 配置cron定期记录smem -t
- 发现某组件RSS每天增长200MB
- 用gdb attach分析内存分配
- 定位到未释放的缓存数据结构
8.3 案例三：磁盘IO的隐形杀手
现象：SSD磁盘响应忽快忽慢
排查：
- iostat -x 发现%util波动剧烈
- 使用blktrace抓取IO请求
- 发现某日志组件频繁fsync
- 修改为异步写入后性能提升8倍
十年运维让我深刻体会到，性能优化没有银弹。上周刚处理一个案例：某Java应用CPU高，最终发现是JIT编译器线程和业务线程争抢CPU资源。调整-XX:CICompilerCount后问题解决。这提醒我们，真正的专家不是记住所有命令，而是建立系统化的排查思维。