欢迎来到8455线路检测中心技术小课堂，每天分享一个技术小知识。

服务器突然响应变慢、页面加载超时、SSH连接卡顿，这些场景运维人员都不陌生。面对性能问题，盲目重启服务往往治标不治本，甚至可能掩盖真正的故障原因。

本文整理了一套经过生产环境验证的排查流程，涵盖CPU、内存、磁盘IO、网络等关键维度。掌握这套方法，能够在最短时间内定位性能瓶颈，避免"病急乱投医"式的无效操作。

第一步：确认现象，建立基准线

动手排查前，先明确三个问题：卡顿是突发性的还是持续性的？影响范围是单机还是集群？是否有近期变更（代码上线、配置调整、流量突增）？

同时记录当前系统基础信息，为后续对比提供参照：

# 查看系统版本和内核信息
uname -a
cat /etc/os-release

# 查看当前时间（便于对照日志）
date

这一步看似简单，却能避免很多弯路。比如某次排查中，团队花费两小时分析性能数据，最后发现只是新上线的定时任务在整点触发——如果一开始就确认变更记录，问题本可以更快定位。

第二步：快速概览——top命令定位资源瓶颈

top是性能排查的第一站，它能实时展示系统整体负载和各进程资源占用：

top -c

关注以下核心指标：

o • load average：1分钟、5分钟、15分钟的平均负载。若持续高于CPU核心数，说明存在资源争抢

o • %Cpu(s)：用户态(us)、系统态(sy)、空闲(id)时间占比。系统态过高通常意味着内核操作密集（如IO或中断处理）

o • %Mem：物理内存使用率，超过80%需警惕

o • 进程列表：按CPU或内存排序，快速定位资源大户

注意：top默认3秒刷新一次，对于瞬时尖峰可能捕捉不到。若怀疑有突发负载，可使用top -d 1缩短采样间隔。

第三步：CPU深度分析——区分计算型与IO型瓶颈

当top显示CPU繁忙时，需要进一步判断是计算密集型任务还是IO等待导致：

# 查看详细CPU统计
mpstat -P ALL 1 3

关键观察点：

o • %usr高：用户程序计算密集，需优化算法或扩容

o • %sys高：内核态消耗大，可能是系统调用频繁或驱动问题

o • %iowait高：CPU在等待磁盘IO，需转向磁盘分析

o • %steal高（云服务器）：宿主机资源争抢，需联系云服务商

若确认是用户程序占满CPU，使用pidstat定位具体进程：

pidstat -u 1 5

该命令能展示每个进程的CPU使用率、用户态/系统态时间占比，比top更精确。

第四步：内存压力检测——识别OOM风险

内存不足会触发OOM Killer，导致关键进程被系统强制终止。提前识别内存压力至关重要：

# 查看内存整体使用情况
free -h

# 查看详细内存统计（包含缓存、缓冲区）
cat /proc/meminfo | grep -E "Mem|Swap|Cache|Buffer"

关键指标解读：

o • available：真正可用的内存（包含可回收缓存），比free更准确

o • Swap使用率：若swap使用量持续增加，说明物理内存已吃紧

o • Active(file)：活跃的文件缓存，过大可能挤压应用内存

当内存使用率超过85%时，使用pidstat -r分析各进程内存占用：

pidstat -r 1 3

关注RSS（实际物理内存占用）和**%MEM**（内存使用占比），找出内存大户。

第五步：磁盘IO诊断——找出慢操作根源

磁盘IO往往是性能瓶颈的"隐形杀手"。当top中的%iowait较高，或系统出现 unexplained 的卡顿，需深入分析磁盘层面：

# 查看磁盘实时IO统计
iostat -x 1 5

核心指标：

o • %util：磁盘繁忙度，持续超过80%说明磁盘饱和

o • await：IO请求平均等待时间（含队列等待和服务时间），超过20ms需关注

o • svctm：IO服务时间，反映磁盘真实性能

o • 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 -g -- sleep 30

# 生成报告
perf report

对于更直观的可视化分析，可生成火焰图：

# 生成折叠栈数据
perf script | ./stackcollapse-perf.pl | ./flamegraph.pl > perf.svg

火焰图中，横轴代表采样时间占比，纵轴是调用栈深度。宽而平的"火焰"区域即为CPU热点函数，是优化的首要目标。

注意：perf需要内核调试信息支持，某些最小化安装的系统可能需要安装kernel-debuginfo包。

第八步：系统调用追踪——strace定位异常行为

当进程表现异常（如卡顿、无响应、资源占用不合理），使用strace追踪其系统调用：

# 追踪现有进程
strace -p -c

# 或启动时追踪
strace -o output.log <command>

-c选项提供统计模式，展示各系统调用的次数和耗时，快速识别异常行为。例如：

o • read/write频繁但数据量小：可能存在碎片化IO

o • open/stat调用过多：可能是文件遍历或配置重载过于频繁

o • futex/mutex耗时高：可能存在锁竞争

生产环境注意：strace对性能有一定影响，高负载进程慎用。建议先在测试环境复现，或采样时间控制在秒级。

第九步：综合监控——vmstat与dstat

当需要同时观察多维度指标的变化趋势，使用vmstat或dstat：

# vmstat：展示进程、内存、swap、IO、CPU综合信息
vmstat 1 10

# dstat（需安装）：更丰富的系统资源视图
dstat -cdngy 1 5

vmstat输出解读（每列含义）：

o • r/b：运行队列和阻塞队列长度，r持续大于CPU核数说明负载高

o • si/so：swap换入换出量，非零值说明内存压力

o • bi/bo：块设备读写速率，反映IO负载

o • 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"

关联分析要点：

o • 性能下降时间点是否有错误日志爆发

o • 是否有"Out of memory"、"I/O error"等关键字

o • 应用日志中是否有慢查询、超时、异常堆栈

案例：某次排查中，iostat显示磁盘await飙升，但无明确进程占用。最后通过dmesg发现磁盘控制器报错，确认是硬件故障导致的IO降级。

排查工具速查表

8455线路检测中心官网上拥有完善的技术支持库可供参考，大家可自行查阅，更多技术问题，可以直接咨询。同时，8455线路检测中心整理了运维必备的工具包免费分享给大家使用，需要的朋友可以直接咨询。

更多技术知识，8455线路检测中心期待与你一起探索。