服务器突然响应变慢、页面加载超时、SSH连接卡顿，这些场景运维人员都不陌生。面对性能问题，盲目重启服务往往治标不治本，甚至可能掩盖真正的故障原因。
本文整理了一套经过生产环境验证的排查流程，涵盖CPU、内存、磁盘IO、网络等关键维度。掌握这套方法，能够在最短时间内定位性能瓶颈，避免"病急乱投医"式的无效操作。
第一步：确认现象，建立基准线
动手排查前，先明确三个问题：卡顿是突发性的还是持续性的？影响范围是单机还是集群？是否有近期变更（代码上线、配置调整、流量突增）？
同时记录当前系统基础信息，为后续对比提供参照：
# 查看系统版本和内核信息
uname -a
cat /etc/os-release
# 查看当前时间（便于对照日志）
date
这一步看似简单，却能避免很多弯路。比如某次排查中，团队花费两小时分析性能数据，最后发现只是新上线的定时任务在整点触发——如果一开始就确认变更记录，问题本可以更快定位。
第二步：快速概览——top命令定位资源瓶颈
top是性能排查的第一站，它能实时展示系统整体负载和各进程资源占用：
top -c
关注以下核心指标：
- • load average：1分钟、5分钟、15分钟的平均负载。若持续高于CPU核心数，说明存在资源争抢
- • %Cpu(s)：用户态(us)、系统态(sy)、空闲(id)时间占比。系统态过高通常意味着内核操作密集（如IO或中断处理）
- • 进程列表：按CPU或内存排序，快速定位资源大户
注意：top默认3秒刷新一次，对于瞬时尖峰可能捕捉不到。若怀疑有突发负载，可使用top -d 1缩短采样间隔。
第三步：CPU深度分析——区分计算型与IO型瓶颈
当top显示CPU繁忙时，需要进一步判断是计算密集型任务还是IO等待导致：
# 查看详细CPU统计
mpstat -P ALL 1 3
关键观察点：
- • %usr高：用户程序计算密集，需优化算法或扩容
- • %sys高：内核态消耗大，可能是系统调用频繁或驱动问题
- • %iowait高：CPU在等待磁盘IO，需转向磁盘分析
- • %steal高（云服务器）：宿主机资源争抢，需联系云服务商
若确认是用户程序占满CPU，使用pidstat定位具体进程：
pidstat -u 1 5
该命令能展示每个进程的CPU使用率、用户态/系统态时间占比，比top更精确。
第四步：内存压力检测——识别OOM风险
内存不足会触发OOM Killer，导致关键进程被系统强制终止。提前识别内存压力至关重要：
# 查看内存整体使用情况
free -h
# 查看详细内存统计（包含缓存、缓冲区）
cat /proc/meminfo | grep -E "Mem|Swap|Cache|Buffer"
关键指标解读：
- • available：真正可用的内存（包含可回收缓存），比free更准确
- • Swap使用率：若swap使用量持续增加，说明物理内存已吃紧
- • Active(file)：活跃的文件缓存，过大可能挤压应用内存
当内存使用率超过85%时，使用pidstat -r分析各进程内存占用：
pidstat -r 1 3
关注RSS（实际物理内存占用）和**%MEM**（内存使用占比），找出内存大户。
第五步：磁盘IO诊断——找出慢操作根源
磁盘IO往往是性能瓶颈的"隐形杀手"。当top中的%iowait较高，或系统出现 unexplained 的卡顿，需深入分析磁盘层面：
# 查看磁盘实时IO统计
iostat -x 1 5
核心指标：
- • %util：磁盘繁忙度，持续超过80%说明磁盘饱和
- • await：IO请求平均等待时间（含队列等待和服务时间），超过20ms需关注
- • avgqu-sz：平均队列长度，持续大于2说明请求堆积
若发现某块磁盘繁忙，使用iotop或pidstat -d定位具体进程：
# 需要root权限，显示各进程IO速率
iotop -oP
# 或使用pidstat
pidstat -d 1 3
常见场景：数据库日志盘%util飙高，往往是慢查询或批量写入导致；系统盘繁忙，可能是日志文件暴涨或临时文件堆积。
第六步：网络层面排查——识别带宽与连接瓶颈
网络问题表现为连接超时、传输缓慢。排查需分两层：带宽使用和连接状态。
带宽分析：
# 查看网卡实时流量
sar -n DEV 1 5
# 或使用iftop查看连接级流量（需安装）
iftop -i eth0
关注rxkB/s（接收）和txkB/s（发送），确认是否达到网卡或带宽上限。
连接状态分析：
# 查看TCP连接统计
ss -s
# 查看各状态连接数
ss -ant | awk '{print $1}' | sort | uniq -c
TIME_WAIT过高：通常是短连接频繁创建销毁，需调优tcp_tw_reuse等参数；CLOSE_WAIT堆积：说明应用程序未正确关闭连接，存在句柄泄漏风险。
第七步：进程级剖析——perf与火焰图
当定位到某个进程CPU占用高，但需进一步了解其内部热点时，使用perf进行采样分析：
# 对指定进程进行CPU采样（30秒）
perf record -p <PID> -g -- sleep 30
# 生成报告
perf report
对于更直观的可视化分析，可生成火焰图：
# 生成折叠栈数据
perf script | ./stackcollapse-perf.pl | ./flamegraph.pl > perf.svg
火焰图中，横轴代表采样时间占比，纵轴是调用栈深度。宽而平的"火焰"区域即为CPU热点函数，是优化的首要目标。
注意：perf需要内核调试信息支持，某些最小化安装的系统可能需要安装kernel-debuginfo包。
第八步：系统调用追踪——strace定位异常行为
当进程表现异常（如卡顿、无响应、资源占用不合理），使用strace追踪其系统调用：
# 追踪现有进程
strace -p <PID> -c
# 或启动时追踪
strace -o output.log <command>
-c选项提供统计模式，展示各系统调用的次数和耗时，快速识别异常行为。例如：
- • read/write频繁但数据量小：可能存在碎片化IO
- • open/stat调用过多：可能是文件遍历或配置重载过于频繁
生产环境注意：strace对性能有一定影响，高负载进程慎用。建议先在测试环境复现，或采样时间控制在秒级。
第九步：综合监控——vmstat与dstat
当需要同时观察多维度指标的变化趋势，使用vmstat或dstat：
# vmstat：展示进程、内存、swap、IO、CPU综合信息
vmstat 1 10
# dstat（需安装）：更丰富的系统资源视图
dstat -cdngy 1 5
vmstat输出解读（每列含义）：
- • r/b：运行队列和阻塞队列长度，r持续大于CPU核数说明负载高
- • si/so：swap换入换出量，非零值说明内存压力
- • us/sy/id/wa：CPU时间分布，与top一致
dstat的优势在于可扩展，支持显示TCP连接数、进程状态、甚至自定义插件，适合作为持续监控工具。
第十步：日志关联与根因确认
性能数据只能告诉你"发生了什么"，而日志能解释"为什么发生"。排查的最后一步，是将性能异常时间点与系统日志、应用日志进行关联：
# 查看系统日志（时间倒序，最近50条）
journalctl -r -n 50
# 或查看syslog
tail -n 100 /var/log/messages
# 查看OOM killer记录
dmesg | grep -i "killed process"
关联分析要点：
- • 是否有"Out of memory"、"I/O error"等关键字
案例：某次排查中，iostat显示磁盘await飙升，但无明确进程占用。最后通过dmesg发现磁盘控制器报错，确认是硬件故障导致的IO降级。
排查工具速查表
| | |
| top | |
| mpstat | |
| free | |
| iostat -x | |
| sar -n DEV | |
| perf | |
| vmstat | |
