Linux服务器卡顿终极排查流程:CPU/内存/IO/网络全覆盖(运维救火必备)

业务突然卡顿、接口超时、页面打不开、服务器ssh延迟极高，日志无明显报错，完全不知道问题出在哪。

服务器卡顿从来不是单一问题，99%的性能瓶颈，只来源于四个维度：CPU、内存、磁盘IO、网络。

很多新手排查卡顿的误区：盲目重启服务、乱敲命令、挨个看日志，浪费大量时间，甚至导致业务二次故障。

今天给大家分享一套标准化、自上而下、零遗漏的Linux服务器卡顿排查完整流程，从全局初筛到精准定位根因，新手也能快速上手，直接收藏备用！

一、核心排查思路（先记心法，少走弯路）

所有服务器卡顿排查，严格遵循这个优先级：

先全局、后局部；先定位瓶颈、再排查进程、最后根治问题

四大资源瓶颈对应故障表象，一眼区分：

• CPU瓶颈：系统负载高、进程执行缓慢、接口响应延迟、无读写阻塞

• 内存瓶颈：系统频繁卡顿、间歇性卡死、Swap大量占用、OOM杀进程

• IO瓶颈：CPU空闲但业务极慢、磁盘读写阻塞、进程处于D状态

• 网络瓶颈：内网/外网延迟高、丢包、连接数打满、接口超时但服务器本地正常

二、第一步：60秒全局初筛，锁定故障大类

收到卡顿反馈后，不要盲目排查细节，先用3条命令快速判定是哪类资源瓶颈，精准缩小排查范围。

1. uptime：查看系统整体负载

uptime

输出示例：10:20:00 up 30 days,  2 users,  load average: 4.20, 3.80, 2.50

核心判断标准：

load average 分别代表 1分钟、5分钟、15分钟系统负载，核心规则：负载值 ≥ CPU核心数，即为过载卡顿。

比如4核CPU，负载超过4就说明CPU饱和，超过8属于严重卡顿。

2. top：全景资源监控（最核心命令）

top

重点看4个核心指标，直接锁定瓶颈：

• %Cpu(s) us/sy：用户态、内核态CPU占用，过高=CPU瓶颈

• %Cpu(s) wa：IO等待占比，持续大于30%=磁盘IO瓶颈

• KiB Mem：内存使用率，结合Swap使用判断内存压力

• 进程状态：D态（不可中断IO阻塞）大量存在=IO问题；R态过多=CPU过载

3. vmstat 1：实时监控系统状态

vmstat 1 5

每秒刷新，输出5组数据，重点关注：

• si/so：Swap换入换出，数值持续不为0=内存不足

• wa：IO等待，高数值=磁盘瓶颈

• us/sy：CPU占用，长期高占用=CPU瓶颈

三、分项深度排查：四大瓶颈精准定位

（一）CPU 卡顿排查：负载高、响应慢

1、故障特征

系统负载飙升、业务响应慢、CPU us/sy 占用极高、无明显IO等待。

2、排查命令\&定位思路

第一步：找出CPU占用最高的进程

# 按CPU排序展示进程ps aux --sort=-%cpu | head -10

第二步：分析进程占用类型

• us用户态过高：业务代码逻辑问题、死循环、大量计算任务、正则雪崩

• sy内核态过高：频繁系统调用、线程竞争、内核BUG、大量小文件读写

• st虚拟机抢占过高：云服务器宿主机资源抢占，底层资源不足

第三步：精细定位线程级CPU占用

# 查看进程内高占用线程top -H -p 进程ID# 导出线程堆栈分析jstack 进程ID | grep 线程16进制ID

3、常见解决方案

• 优化业务代码，修复死循环、低效逻辑

• 关闭无用进程、清理定时任务冗余脚本

• CPU持续打满，临时降级限流，扩容节点分担压力

（二）内存 卡顿排查：间歇性卡死、OOM崩溃

1、故障特征

服务器间歇性卡顿、ssh连接延迟大、日志出现OOM killer、Swap频繁读写、业务随机闪退。

2、排查命令\&定位思路

第一步：查看真实内存使用（重点看可用内存）

free -h

关键知识点：不要只看free空闲内存，看available可用内存，Swap使用率飙升是内存不足的核心信号。

第二步：定位内存占用最高的进程

ps aux --sort=-%mem | head -10

第三步：排查内存泄漏\&OOM日志

# 查看系统OOM查杀记录dmesg | grep -i oom

3、核心故障场景

• 内存泄漏：进程内存占用持续上涨，重启后恢复，一段时间后复现

• 缓存占用过高：buff/cache占用大量内存，可手动释放缓存

• Swap滥用：物理内存不足，系统频繁读写Swap，导致整机卡顿

4、解决方案

• 优化程序内存逻辑，修复内存泄漏问题

• 临时清理缓存：echo 3 > /proc/sys/vm/drop_caches

• 调整swappiness参数，减少Swap使用，必要时扩容物理内存

（三）磁盘IO 卡顿排查：CPU空闲但业务超慢

1、故障特征

CPU使用率很低，但业务卡顿严重、接口超时、磁盘读写延迟高、大量进程处于D阻塞状态、top中wa值极高。

2、排查命令\&定位思路

第一步：查看磁盘IO整体负载

iostat -x 1

核心指标判断：

• %util：接近100% 说明磁盘IO饱和，读写队列拥堵

• await：单次IO等待时间，数值越大，IO阻塞越严重

• svctm：磁盘处理耗时，过高说明磁盘硬件性能瓶颈

第二步：定位哪些进程在疯狂读写磁盘

iotop -oP

第三步：排查大文件、日志刷屏问题

# 查看磁盘占用大目录du -sh /*# 排查是否有日志疯狂写入、文件同步任务占用IO

3、常见IO瓶颈场景

• 日志疯狂打印、程序异常刷屏日志

• 大量小文件读写、定时备份、rsync同步任务

• 机械硬盘性能不足，业务高并发读写场景不匹配

• 磁盘坏道、文件系统异常导致IO阻塞

4、解决方案

• 关闭冗余日志、优化日志级别、切割超大日志文件

• 错开备份、同步等IO密集型任务时间

• 机械硬盘更换SSD，提升磁盘读写性能

• 检查磁盘坏道，修复文件系统异常

（四）网络 卡顿排查：服务器正常，业务不通

1、故障特征

服务器CPU/内存/IO均正常，但业务访问卡顿、接口超时、内网通信延迟高、外网访问丢包。

2、排查命令\&定位思路

第一步：检查网络延迟与丢包

# 持续ping测试丢包延迟ping 网关/业务域名# 追踪路由链路mtr 目标IP

第二步：查看网络连接状态（核心）

# 统计各类连接数ss -s# 查看海量TIME_WAIT/ESTABLISHED连接ss -ant | sort

第三步：排查带宽占用

# 实时监控网卡流量iftop -i 网卡名

3、常见网络瓶颈场景

• 连接数打满：TIME_WAIT过多未释放、ESTABLISHED连接超限

• 带宽跑满：文件传输、爬虫、日志上传占用全部带宽

• 网络丢包：网卡故障、交换机问题、防火墙策略拦截、带宽拥堵

• DNS解析缓慢：域名解析超时导致业务卡顿

4、解决方案

• 优化内核网络参数，快速回收TIME_WAIT连接

• 限流封禁异常流量、清理恶意连接

• 检查防火墙、安全组策略，排查端口拦截问题

• 更换优质DNS，优化网络链路

四、终极排查流程图（一键收藏）

服务器卡顿排查完整链路：

业务卡顿反馈 → uptime/top全局初筛 → 判断瓶颈类型（CPU/内存/IO/网络） → 精准定位异常进程/任务 → 临时恢复业务 → 排查根因优化 → 复盘归档

黄金判断口诀：

• 负载高、wa低 → 查CPU

• Swap动、OOM出 → 查内存

• wa值高、进程堵 → 查IO

• 资源闲、业务慢 → 查网络

五、运维实战总结

1、服务器卡顿90%都是可预判、可排查的已知问题，无莫名卡顿，只是排查思路不对；

2、排查优先恢复业务，再定位根因，救火优先、优化后置；

3、不要盲目重启服务/服务器，大概率掩盖故障现场，增加排查难度；

4、日常做好监控告警（CPU、内存、IO、网络、连接数），提前规避卡顿故障。

这套流程覆盖生产环境99%的Linux卡顿场景，建议大家收藏，遇到故障直接对照排查，告别盲目救火！

往期推荐

✅ Linux高频运维命令大全

✅ 服务器性能监控指标详解

✅ 线上故障排查实战案例