当前位置：首页>Linux>Linux 系统变慢?用这 8 个命令快速定位瓶颈

Linux 系统变慢?用这 8 个命令快速定位瓶颈

2026-07-07 09:50:40

Linux 系统变慢？用这 8 个命令快速定位瓶颈

一、问题背景

"系统变慢了"是运维群里出现频率最高的一句话。来源可能是用户、业务方、监控告警、值班人员。症状也很杂：网页打开慢、SSH 上去操作卡、SQL 查询慢、视频卡顿、定时任务跑不完、K8s Pod 频繁 OOM。

但"慢"本身不是结论，是一个症状。要解决它，必须先知道"慢在哪里"。常见瓶颈分布在四层：

CPU 层
：进程占用过高、上下文切换过载、软中断打满、单线程跑满核；
内存层
：可用内存耗尽、swap 飙升、OOM 杀进程、page cache 抖动；
IO 层
：磁盘 await 飙升、IO 队列堆积、inode 耗尽、fd 耗尽、日志写爆盘；
网络层
：带宽打满、丢包、重传、连接数耗尽、DNS 解析慢、TIME_WAIT 堆积。

每一层的检查工具、关键指标、典型场景都不一样。但大多数运维同学遇到"系统慢"时，第一反应往往就是登录服务器看 top。top 看了半天也没找到问题根源，时间一两个小时过去了，业务受损还在持续。

这篇文章把"系统慢"的标准排查路径沉淀成一套固定的命令组合。8 个核心命令 + 8 个进阶命令 + 完整的排查流程 + 真实场景示例，对照着做，目标是把首次定位时间从 30 分钟压缩到 5 分钟。

写作思路：

不讲大段理论，直接给命令、给指标、给判断逻辑；
每个命令给出：目的、用法、预期输出、异常信号、下一步动作；
把常见 6 类瓶颈场景分别给出排查案例；
强调"先观察再动手"，所有修复操作必须可回滚。

二、适用场景

本文适用：

用户反馈"系统变慢"，但没有给出具体症状，需要快速定位瓶颈；
监控告警：load average 高、CPU 使用率高、内存使用率高、磁盘使用率高、网络流量异常；
应用日志出现超时（read timeout、connection timeout、request timeout）；
业务请求 P99 / P95 突增，怀疑系统层问题；
SSH 登录后操作卡顿（命令返回慢、history 加载慢）；
定时任务跑不完（cron / systemd timer）；
K8s Pod 频繁 OOM Killed、Pending、NotReady；
数据库（MySQL/Redis/PG）慢查询，但怀疑不是数据库本身问题；
Web 服务器（Nginx/Apache）出现 502/504，怀疑系统层问题；
容器宿主机负载异常，怀疑容器或宿主机问题。

不适用：

应用代码 bug（死循环、内存泄漏）——本文聚焦 OS 层；
网络层（L4 防火墙、交换机、运营商）问题——需要走网络排障流程；
机房级故障（断电、空调）——走基础设施应急流程；
硬件故障（磁盘坏道、内存故障）——需要走硬件更换流程。

三、核心知识点

3.1 性能分析的方法论

USE 方法（Brendan Gregg）：

Utilization（利用率）
：资源有多忙；
Saturation（饱和度）
：资源排队的程度；
Errors（错误）
：错误事件的计数。

应用到这个场景：

CPU：利用率、运行队列长度、上下文切换、软中断；
内存：利用率、可用内存、swap、page fault；
磁盘：利用率、队列长度、await、服务时间；
网络：带宽利用率、丢包率、连接数。

RED 方法：

Rate
：每秒请求数；
Errors
：每秒错误数；
Duration
：每个请求的耗时。

应用到这个场景：

应用 QPS、错误率、P99 延迟。

3.2 load average 的含义

load average 是衡量 Linux 系统负载的核心指标，定义是单位时间内处于可运行状态和不可中断睡眠状态的平均进程数。

可运行（R）：正在使用 CPU 或等待 CPU；
不可中断睡眠（D）：正在等待 IO（通常是磁盘 IO）。

uptime 输出示例：

14:30:01 up 100 days, 23:15,  1 user,  load average: 4.50, 5.20, 4.80

三个数字分别是 1 分钟、5 分钟、15 分钟的平均负载。

判断标准：

与 CPU 核数对比：4 核 CPU，load 4 说明满载，load 16 说明严重排队；
经验值：长期 load < 0.7 * CPU 核数算健康，> 1.0 * 核数说明有问题，> 2.0 * 核数说明严重排队；
但要注意：CPU idle 90%、load 20 也是可能的（IO wait 导致）。

3.3 CPU 维度

CPU 状态分类（top / mpstat）：

us
：用户态（用户进程占用）；
sy
：内核态（系统调用、内核线程）；
ni
：nice 值调整后的用户态；
id
：空闲；
wa
：IO wait，等待 IO 完成；
hi
：硬中断；
si
：软中断；
st
：被其他虚拟机偷走（云环境）。

判断逻辑：

us
高 + id 低：业务进程占用 CPU 严重；
sy
高：内核态繁忙，可能系统调用过多（高频 write、mmap、epoll）；
wa
高：IO 瓶颈（磁盘/网络）；
si
高：软中断打满（网卡、磁盘）；
hi
高：硬件中断；
st
高：宿主机/邻居 VM 抢占（云环境）。

3.4 内存维度

free -h 输出：

              total        used        free      shared  buff/cache   availableMem:           15Gi        8.2Gi       1.2Gi       0.0Ki       6.0Gi       6.5GiSwap:         4.0Gi       1.5Gi       2.5Gi

关键指标：

total
：物理内存总大小；
used
：已用（不含 buffer/cache）；
free
：完全空闲；
buff/cache
：buffer + page cache（可回收）；
available
：可用内存（含可回收）；
Swap
：swap 总量 + 已用。

判断逻辑：

available
接近 0：内存紧张；
swap
持续上涨：内存不足，触发 swap；
buff/cache
很大但 free 很小：正常，Linux 会用空闲内存做缓存；
si
/so（swap in/out）持续非 0：swap 抖动，性能下降。

3.5 IO 维度

磁盘 IO 是最容易被忽视的瓶颈。iostat 关键指标：

Device   r/s     w/s   rkB/s    wkB/s  await r_await w_await %utilsda      10      50    500      2000   30    5       35      95

r/s
、w/s：每秒读写次数（IOPS）；
rkB/s
、wkB/s：每秒读写带宽；
await
：平均每次 IO 耗时（毫秒），含队列等待；
r_await
、w_await：读、写分别的 await；
%util
：设备繁忙度，100% 表示饱和。

机械盘 vs SSD：

机械盘：IOPS < 200，await 期望 < 10ms，%util 长期 > 80% 说明饱和；
SSD：IOPS 上万，await 期望 < 1ms，%util 不是判断标准，要看 await。

3.6 网络维度

关键指标：

带宽利用率：sar -n DEV 1、iftop、nethogs；
丢包率：netstat -s 中的 segments retransmitted；
连接数：ss -s、ss -ant | wc -l；
TIME_WAIT：ss -ant state time-wait | wc -l；
CLOSE_WAIT：ss -ant state close-wait | wc -l；
软中断：cat /proc/net/softnet_stat。

判断逻辑：

带宽打满：业务流量超过网卡带宽（10Gbps / 1Gbps）；
丢包：物理链路、网卡驱动、内核参数都可能；
TIME_WAIT 多：短连接多，需要调整内核参数或开启 TIME_WAIT 复用；
CLOSE_WAIT 多：应用没正常关闭 socket，可能有 bug；
softnet_stat
第二列很大：软中断处理不及时，需要增加队列或 RSS。

3.7 文件系统维度

inode 耗尽：df -i；
fd 耗尽：cat /proc/sys/fs/file-nr；
文件系统只读：dmesg 中 Read-only filesystem；
LVM / mount 问题：mount、df -h。

3.8 进程维度

ps、pidstat、top 看进程状态：

R：运行中；
S：可中断睡眠；
D：不可中断睡眠（IO 等待）；
Z：僵尸（父进程没回收）；
T：停止；
I：空闲内核线程。

D 状态进程长时间存在是危险信号（可能是 IO hang 或内核 bug）。

3.9 内核参数

/etc/sysctl.conf 中的关键参数：

vm.swappiness
：swap 倾向，0-100，默认 60，云主机常用 10；
net.core.somaxconn
：listen backlog；
net.ipv4.tcp_max_syn_backlog
：SYN 队列长度；
net.ipv4.tcp_tw_reuse
：TIME_WAIT 复用；
net.ipv4.tcp_fin_timeout
：FIN_WAIT_2 超时；
net.core.rmem_default/wmem_default
：socket 缓冲区默认大小；
fs.file-max
：系统最大 fd；
fs.nr_open
：单进程最大 fd。

3.10 工具生态

经典工具：top, vmstat, iostat, free, df, du, ss, netstat, ps, lsof进阶工具：htop, iotop, iftop, nethogs, pidstat, mpstat, perf, strace, ltrace高级工具：bpftrace, systemtap, ebpf, perf + FlameGraph可视化：netdata, prometheus + grafana, zabbix

四、整体排查或实施思路

"系统慢"的标准排查路径分四层，由外到内、由系统到进程：

第一层：系统全局指标（30 秒）

目的：快速判断瓶颈在 CPU / 内存 / 磁盘 / 网络哪一层。

bash
uptime# load averagetop -bn1 | head -20 # CPU、内存、进程free -h             # 内存df -h               # 磁盘ss -s               # 网络连接总数dmesg -T | tail -30 # 内核报错

第二层：单维度深入（1-3 分钟）

针对第一层发现的瓶颈，进入对应维度深挖：

CPU 高 → mpstat -P ALL 1 5、pidstat -u 1 5、top -c；
内存高 → vmstat 1 5、sar -r 1、cat /proc/meminfo；
IO 高 → iostat -xz 1 5、iotop、pidstat -d 1 5；
网络高 → sar -n DEV 1、iftop、nethogs、ss -antp。

第三层：进程维度定位（3-5 分钟）

找到可疑进程后，深入分析：

pidstat -p PID -u -r -d 1 5
：CPU/内存/IO；
cat /proc/PID/status
：状态；
cat /proc/PID/limits
：资源限制；
ls -l /proc/PID/fd | wc -l
：fd 数量；
pmap -x PID
：内存映射；
perf top -p PID
：CPU 热点；
strace -p PID
：系统调用；
lsof -p PID
：打开的文件和连接。

第四层：修复与验证（5-15 分钟）

应急处置：杀进程、限流、扩容；
配置优化：内核参数、应用参数；
验证：观察指标回归到基线。

排查路径速查表

load 高 → CPU 高？wa 高？  ├── CPU 高 → 哪个进程？→ perf top / strace  ├── wa 高 → IO 高？→ iostat -xz  └── sy 高 → 系统调用？→ strace / perf内存高 → 哪个进程？  ├── 单进程内存大 → pmap / heap dump  ├── 频繁 OOM → dmesg OOM / cgroup 限制  └── swap 高 → vmstat / sar -rIO 高 → 哪个设备？  ├── %util 高 + await 高 → 磁盘饱和  ├── await 高但 %util 低 → 队列深度问题  └── IOPS 高 → 应用 IO 模式问题网络高 → 哪个连接？  ├── 带宽满 → iftop / nethogs  ├── 连接数满 → fd / somaxconn  ├── 丢包 → netstat -s / dmesg  └── DNS 慢 → systemd-resolved / dig进程异常 → D 状态？fd 满？  ├── D 状态多 → IO hang → dmesg / iostat  ├── fd 满 → lsof + 调整 ulimit  └── CPU 100% 单线程 → 应用 bug

五、实战步骤

5.1 步骤一：系统全局快查（30 秒）

目的：用 6 个命令快速判断瓶颈层。

bash
# 1. load average 与运行时长uptime# 输出：14:30:01 up 100 days, 23:15, 1 user, load average: 4.50, 5.20, 4.80# 2. CPU、内存、进程 TOPtop -bn1 | head -20# 3. 内存详情free -h# 4. 磁盘使用df -hdf -i# 5. 网络连接统计ss -s# 6. 内核报错dmesg -T | tail -30

预期输出：

load 接近或超过 CPU 核数：CPU 瓶颈；
free
中 available 接近 0：内存瓶颈；
磁盘使用 > 90%：磁盘满；
dmesg
出现 OOM、IO error、segfault：内核级问题。

异常表现：

load 高但 CPU idle 高 → IO wait 高（磁盘/网络瓶颈）；
内存 available 0 + swap 高 → 内存瓶颈；
df
显示 100% + 业务日志写失败 → 磁盘满；
dmesg
有 TCP: out of memory → 端口/socket 耗尽。

下一步动作：

锁定瓶颈层后，进入对应维度的深入排查。

5.2 步骤二：CPU 维度深入

bash
# 1. 每个 CPU 核心的状态mpstat -P ALL 1 5# 2. 进程级 CPUpidstat -u 1 5# 3. top 找占用高的进程top -c -b -n 1 | head -30# 4. 按 CPU 排序的进程ps -eo pid,ppid,user,pcpu,pmem,etime,args --sort=-pcpu | head -20# 5. 单进程的 CPU 热点top -Hp <PID>perf top -p <PID># 6. 上下文切换与中断vmstat 1 5cat /proc/interrupts | head -20# 7. 软中断cat /proc/softirqsmpstat -I ALL 1 5# 8. 运行队列与负载sar -q 1 5# 9. CPU 频率cat /proc/cpuinfo | grep "cpu MHz"lscpu# 10. 单进程系统调用strace -p <PID> -c -fstrace -p <PID> -e trace=network,write,read

预期输出：

mpstat
显示每个核的 usr/sys/iowait/idle；
pidstat
显示每个进程的 %user、%system、%guest、%wait；
vmstat
输出 procs r b 表示运行中和不可中断进程数。

判断逻辑：

单核 usr > 80%：单进程占满核；
单核 iowait > 30%：IO 等待；
procs r
> CPU 核数：进程排队；
procs b
> 0：不可中断睡眠；
system cs
（context switch） > 100k/s：上下文切换过高；
system in
（interrupt） > 10k/s：中断过高。

异常表现：

usr
95%+：单进程占满 CPU；
sy
30%+：内核态繁忙，可能是高频系统调用；
wa
30%+：IO 等待；
si
30%+：软中断，常见于网卡打爆；
cs
> 100k：上下文切换频繁；
migration
大量：CPU 亲和性问题。

下一步动作：

单进程占满 → 找到该进程，进一步分析；
sy
高 → strace 找热点 syscall；
si
高 → 找软中断来源（网卡/磁盘）；
wa
高 → 进入 IO 维度排查。

5.3 步骤三：内存维度深入

bash
# 1. 内存详情free -hcat /proc/meminfo# 2. 内存历史vmstat 1 5sar -r 1 5# 3. swap 活动vmstat 1 5sar -S 1 5# 4. OOM 历史dmesg -T | grep -i "out of memory"grep -i "oom" /var/log/messagesjournalctl -k | grep -i "oom"# 5. 大内存进程ps -eo pid,ppid,user,pcpu,pmem,rss,vsz,args --sort=-rss | head -20# 6. 单进程内存映射pmap -x <PID> | sort -k3 -n -r | head# 7. 详细内存使用cat /proc/<PID>/smaps_rollup# 8. 内存泄漏检测valgrind --tool=massif --pages-as-heap=yes ./program# 9. slab 缓存slabtopcat /proc/slabinfo# 10. page cache 与 buffercat /proc/meminfo | grep -E "Buffers|Cached|SwapTotal|SwapFree"# 11. cgroup 限制cat /sys/fs/cgroup/memory/memory.limit_in_bytescat /sys/fs/cgroup/memory/memory.usage_in_bytescat /sys/fs/cgroup/memory/memory.failcnt

预期输出：

free -h
：total/used/free/shared/buff/cache/available；
vmstat
：si/so 表示 swap in/out；
pmap
：进程虚拟内存映射；
cgroup
：容器限制。

判断逻辑：

available
< total * 10%：内存紧张；
si/so
> 0：swap 抖动；
OOM
出现：触发 OOM Killer；
cache
占用多：正常，Linux 会用空闲内存做缓存；
slab
占用大：内核对象多（如 dentry、inode）；
cgroup failcnt > 0：触发过 cgroup 限制。

异常表现：

swap 持续上涨：内存不足；
OOM 频繁：内存泄漏或限制过小；
单进程 RSS > total/2：单进程内存占用过大；
dentry
或 inode cache 大：文件系统压力；
nfs_*
cache 大：NFS 缓存占用。

下一步动作：

单进程内存大 → pmap 进一步分析；
swap 高 → 找占用内存最多的进程或调 vm.swappiness；
OOM → 调大内存或调小 cgroup 限制；
内存泄漏 → heap dump + 分析。

5.4 步骤四：磁盘 IO 维度深入

bash
# 1. 系统级 IOvmstat 1 5# 看 bi/bo（block in/out）# 2. 每个磁盘的 IOiostat -xz 1 5iostat -xz -m 1 5# 3. 按进程统计 IOiotop -o -P -d 5# 4. 进程级 IOpidstat -d 1 5# 5. 读写的文件lsof -p <PID> | grep -E "REG|DIR"# 6. 大文件查找find / -size +100M -type f 2>/dev/null | head -20find / -size +1G -type f 2>/dev/null# 7. 目录大小du -sh /var/log/*du -sh /var/lib/*# 8. 排查删除但未释放的文件lsof | grep deleted# 9. 写日志最多的进程lsof | awk '$5 == "REG" && $4 == "w" {print}' | head# 10. 块设备队列cat /sys/block/sda/queue/nr_requestscat /sys/block/sda/queue/scheduler# 11. 块设备统计cat /proc/diskstats# 12. IO 跟踪iotop -p <PID>strace -p <PID> -e trace=read,write,preadv,pwritev -c

预期输出：

iostat
输出每个设备的 r/s、w/s、rkB/s、wkB/s、await、%util；
iotop
按进程 IO 排序；
pidstat -d
显示每个进程的 read/write/swap。

判断逻辑：

%util
接近 100%：设备饱和；
await
远高于设备服务时间：队列堆积；
r/s + w/s
接近设备 IOPS 上限：IOPS 满；
rkB/s + wkB/s
接近设备带宽：带宽满；
iostat
中 svctm（服务时间）较大：设备本身慢。

异常表现：

机械盘 %util 长期 > 80%：磁盘 IO 饱和；
SSD await > 10ms：SSD 性能问题；
单进程 IO 很高：业务 IO 模式问题；
find /
占用大量 IO：定时任务撞 IO；
大量 deleted 文件未释放：日志句柄没关。

下一步动作：

找到 IO 高的进程，分析 IO 模式；
大文件清理；
调整 IO 调度器（deadline、noop、cfq）；
限流（ionice、cgroup blkio）。

5.5 步骤五：网络维度深入

bash
# 1. 网卡流量sar -n DEV 1 5iftop -i eth0# 2. 按进程统计流量nethogs -d 5# 3. TCP/UDP 连接统计ss -sss -ant | awk '{print $1}' | sort | uniq -c# 4. TIME_WAIT / CLOSE_WAITss -ant state time-wait | wc -lss -ant state close-wait | wc -lss -ant state established | wc -l# 5. 按进程统计 ESTABLISHEDss -antp state established | grep -E "users:" | awk '{for(i=1;i<=NF;i++) if($i~/users:/) print $(i+1)}' | sort | uniq -c | sort -rn | head# 6. 网络协议统计netstat -sss -s# 7. 丢包与重传netstat -s | grep -E "retransmit|drop|timeout"cat /proc/net/softnet_stat# 8. 网卡中断cat /proc/interrupts | grep eth0watch -n 1 "cat /proc/interrupts | grep eth0"# 9. 抓包tcpdump -i eth0 -nn -s0 -w capture.pcaptcpdump -i eth0 -nn port 80# 10. DNS 解析时间dig +stats example.com# 11. traceroute / mtrmtr -rwc 30 example.com# 12. 内核网络参数sysctl -a | grep -E "net\.(core|ipv4)"

预期输出：

sar -n DEV
：每秒收发的 KB/s；
iftop
：实时流量；
ss -s
：连接总数 + 各状态分布；
softnet_stat
：每个 CPU 队列的处理情况。

判断逻辑：

带宽满：网卡 rxkB/s + txkB/s 接近网卡最大带宽；
丢包：/proc/net/softnet_stat 第二列很大；
TIME_WAIT 多：短连接多；
CLOSE_WAIT 多：应用 bug；
retransmit
多：网络质量差或 server 端慢；
DNS 慢：resolver 配置或上游 DNS 问题。

异常表现：

10Gbps 网卡跑满：业务流量大；
1Gbps 网卡跑满：业务流量超过设计容量；
CLOSE_WAIT 持续上涨：业务没正常关闭连接；
TIME_WAIT 涨到几十万：短连接服务需要内核参数优化；
软中断单核 100%：网卡 RSS 没配。

下一步动作：

带宽满 → 扩容或限流；
丢包 → 排查网络设备；
TIME_WAIT 多 → 调整内核参数（tcp_tw_reuse、tcp_tw_recycle）；
CLOSE_WAIT 多 → 应用排查；
DNS 慢 → 换 DNS server。

5.6 步骤六：进程维度深挖

bash
# 1. 进程状态ps -eo pid,user,stat,etime,pcpu,pmem,args | head -20# 2. 进程 /proc/<PID>/ 详细信息PID=12345cat /proc/$PID/statuscat /proc/$PID/statcat /proc/$PID/cmdlinels -la /proc/$PID/exels -la /proc/$PID/cwdls -la /proc/$PID/fd | wc -lcat /proc/$PID/limitscat /proc/$PID/smaps_rollup# 3. 进程打开的文件lsof -p $PID | head -30lsof -p $PID | grep -E "REG|DIR|sock"lsof -p $PID | grep -E "REG.*deleted"# 4. 进程的网络连接ss -antp | grep $PID# 5. 进程的环境变量cat /proc/$PID/environ | tr'\0''\n'# 6. 进程的资源占用pidstat -p $PID -u -r -d 1 5# 7. CPU 热点perf top -p $PIDperf record -p $PID -g -- sleep 10perf report# 8. 系统调用热点strace -p $PID -cstrace -p $PID -e trace=network,read,write -c# 9. 进程关联的内核调用cat /proc/$PID/wchancat /proc/$PID/syscall# 10. 子进程ps --ppid $PID# 11. 线程ps -eLf | grep $PID | headcat /proc/$PID/status | grep Threads# 12. 进程优先级chrt -p $PIDcat /proc/$PID/stat | awk '{print "priority="$18,"nice="$19}'

预期输出：

/proc/PID/status
：State、VmRSS、Threads、voluntary_ctxt_switches 等；
lsof
：进程打开的文件、socket；
perf top
：CPU 热点函数；
strace -c
：系统调用统计。

判断逻辑：

进程 State 为 D：IO 等待，需要看 wchan；
Threads
过大：线程数过多；
fd
数量接近 ulimit -n：fd 耗尽风险；
VmRSS
大：内存占用大；
voluntary_ctxt_switches
高：进程主动让出 CPU；
nonvoluntary_ctxt_switches
高：被调度器抢。

异常表现：

进程 D 状态长时间：IO hang；
fd 数 > 10000：可能 fd 泄漏；
单进程 100+ 线程：可能线程泄漏；
perf top 显示某函数占用高：CPU 热点定位；
strace 显示某 syscall 频繁：系统调用热点。

下一步动作：

D 状态：找 IO 根因（磁盘/网络）；
fd 泄漏：调大 ulimit 或修 bug；
线程泄漏：调小或修 bug；
CPU 热点：perf + FlameGraph 分析；
syscall 热点：调小 syscall 频率或换更高效的调用。

5.7 步骤七：常见瓶颈场景排查示例

场景 1：CPU 跑满

bash
# 现象uptime# load average: 24.50, 25.20, 24.80# 4 核 CPUtop -bn1 | head -10# %Cpu(s): 95.0 us,  2.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  3.0 si,  0.0 st# 定位ps -eo pid,pcpu,args --sort=-pcpu | head# PID 12345 mysqld 占 800%# 进一步分析top -Hp 12345# 看到 mysqld 多线程都忙mysqladmin -u root -p processlist# 看慢查询# 修复# 1. 找到慢 SQL，加索引或优化# 2. 调小 innodb_thread_concurrency# 3. 杀慢查询：KILL QUERY <thread_id>

场景 2：内存耗尽 + OOM

bash
# 现象free -h# available 0# swap used 4Gdmesg -T | grep -i oom# Out of memory: Killed process 12345 (java)# 定位ps -eo pid,user,rss,args --sort=-rss | head# PID 12345 java RSS 32G# 进一步分析pmap -x 12345 | sort -k3 -n -r | head# 看大块内存分配# 修复# 1. 调小 JVM heap# 2. 重启进程# 3. 排查内存泄漏

场景 3：磁盘 IO 满

bash
# 现象iostat -xz 1 5# sda await 200ms, %util 100%# 定位iotop -o -P# PID 12345 mysqld 占 100M/s 写# 进一步分析lsof -p 12345 | grep REG# 看写哪些文件# 修复# 1. 调小 innodb_io_capacity# 2. 错峰执行大查询# 3. 换 SSD

场景 4：磁盘写满

bash
# 现象df -h# /var 100%业务报错：No space left on device# 定位du -sh /var/* | sort -h | tail# /var/log/messages 占 200G# 进一步分析ls -la /var/log/messages# 文件 200Glsof | grep "/var/log/messages"# 进程 PID 12345 占着# 修复# 1. 用 truncate 截断（不删文件，进程句柄仍可用）truncate -s 0 /var/log/messages# 2. 或 cat /dev/null > file（不删 inode）# 3. 或 mv 文件后重启 rsyslog# 不要 rm，会释放 inode，但进程还在写，可能出错

场景 5：网络连接耗尽

bash
# 现象业务报错：Cannot assign requested addressss -s# TCP: 60000 (estab 50000, closed 8000, orphaned 0, timewait 1000)# 定位cat /proc/sys/net/ipv4/ip_local_port_range# 32768 60999 = 28232 个端口# 进一步分析ss -antp | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head# 看来源 IP 分布# 修复# 1. 调整端口范围echo"net.ipv4.ip_local_port_range = 1024 65535" >> /etc/sysctl.confsysctl -p# 2. 开启 TIME_WAIT 复用echo"net.ipv4.tcp_tw_reuse = 1" >> /etc/sysctl.confsysctl -p

场景 6：fd 耗尽

bash
# 现象业务报错：Too many open filescat /proc/sys/fs/file-nr# 16384 16384 65536# 定位ls -l /proc/<PID>/fd | wc -l# 接近 ulimit -n# 进一步分析lsof -p <PID> | grep -E "REG|DIR" | awk '{print $NF}' | sort | uniq -c | sort -rn | head# 看打开的文件分布# 修复# 1. 调大 ulimitecho"ulimit -n 65535" >> /etc/security/limits.conf# 2. 排查 fd 泄漏（用 lsof 看哪些 fd 不该开）

5.8 步骤八：应急处置

bash
# 1. 杀进程（先 STOP 留证据，再 TERM，最后 KILL）kill -STOP <PID>       # 暂停进程，便于排查kill -CONT <PID>       # 恢复进程kill -TERM <PID>       # 优雅退出sleep 5kill -9 <PID>          # 强制 kill，慎用# 2. 限流（用 ionice、cgroup）ionice -c2 -n7 -p <PID>          # 调低 IO 优先级renice +10 -p <PID>              # 调低 CPU 优先级# 3. 隔离（用 cgroup）mkdir -p /sys/fs/cgroup/cpu/test.sliceecho <PID> > /sys/fs/cgroup/cpu/test.slice/tasksecho 100000 > /sys/fs/cgroup/cpu/test.slice/cpu.cfs_quota_us# 4. 限速（tc / iptables）iptables -I OUTPUT -p tcp --dport 80 -m limit --limit 100/s -j ACCEPTiptables -I OUTPUT -p tcp --dport 80 -j DROP# 5. 卸载磁盘（紧急）umount /data   # 会影响正在使用该盘的业务# 6. 紧急扩容（云环境）# 走云厂商 API# 7. 切流（CDN/GSLB）# 走运维平台切流# 8. 重启服务systemctl restart <service>

5.9 步骤九：长期治理

bash
# 1. 容量规划（基于历史数据）sar -u -r -d -n DEV -f /var/log/sa/sa$(date +%d -d yesterday)# 2. 监控告警# 部署 Prometheus + node_exporter + Grafana# 3. 压测wrk -t 10 -c 1000 -d 60s http://example.comab -n 100000 -c 1000 http://example.com/# 4. 优化（应用/配置/架构）# 应用：缓存、异步、批量# 配置：内核参数、连接池# 架构：读写分离、分库分表、CDN、缓存层# 5. Runbook# 把排查路径沉淀到 Runbook# 把常见问题写成 FAQ# 把应急流程做成 Ansible role

六、常用命令

6.1 综合快查

bash
uptimetop -bn1 | head -20free -hdf -hdf -iss -sdmesg -T | tail -30

6.2 CPU

bash
tophtopmpstat -P ALL 1 5mpstat -I ALL 1 5pidstat -u 1 5vmstat 1 5sar -u 1 5perf topperf record -g -p <PID> -- sleep 10 && perf reportstrace -p <PID>cat /proc/loadavgcat /proc/cpuinfolscpu

6.3 内存

bash
free -hcat /proc/meminfovmstat 1 5sar -r 1 5sar -S 1 5slabtopdmesg | grep -i oomps -eo pid,user,rss,args --sort=-rss | headpmap -x <PID>cat /proc/<PID>/smaps_rollupcat /proc/<PID>/status

6.4 IO

bash
iostat -xz 1 5iostat -xz -m 1 5iotop -o -Ppidstat -d 1 5vmstat 1 5   # bi/bosar -d 1 5lsof -p <PID> | grep REGfind / -size +1G -type f 2>/dev/nulldu -sh /var/log/* | sort -hlsof | grep deleted

6.5 网络

bash
sar -n DEV 1 5sar -n EDEV 1 5iftop -i eth0nethogs -d 5ss -sss -ant | awk '{print $1}' | sort | uniq -css -antp state establishednetstat -scat /proc/net/softnet_stattcpdump -i eth0 -nn -s0 -w capture.pcapmtr -rwc 30 example.comdig +stats example.com

6.6 进程

bash
ps auxfps -eo pid,ppid,user,pcpu,pmem,args --sort=-pcpu | headtop -Hp <PID>pidstat -p <PID> -u -r -d 1 5cat /proc/<PID>/statuscat /proc/<PID>/cmdlinels -la /proc/<PID>/exels -la /proc/<PID>/fd | wc -llsof -p <PID>pstree -ap <PID>

6.7 内核

bash
sysctl -asysctl -pcat /etc/sysctl.confuname -admesg -Tjournalctl -k

6.8 应急

bash
kill -STOP <PID>kill -CONT <PID>kill -TERM <PID>kill -9 <PID>renice +10 -p <PID>ionice -c2 -n7 -p <PID>systemctl restart <service>iptables -I INPUT -s <ip> -j DROPumount /dataswapoff /dev/sda2

七、配置示例

7.1 sysctl 内核参数调优（`/etc/sysctl.conf`）

conf
# ---------- 内存 ----------vm.swappiness = 10vm.dirty_ratio = 15vm.dirty_background_ratio = 5vm.vfs_cache_pressure = 100# ---------- 网络 ----------net.core.somaxconn = 65535net.core.rmem_default = 262144net.core.wmem_default = 262144net.core.rmem_max = 16777216net.core.wmem_max = 16777216net.core.netdev_max_backlog = 65535net.ipv4.tcp_max_syn_backlog = 65535net.ipv4.tcp_tw_reuse = 1net.ipv4.tcp_tw_recycle = 0   # 注意：4.12+ 已废弃net.ipv4.tcp_fin_timeout = 15net.ipv4.tcp_keepalive_time = 600net.ipv4.tcp_keepalive_intvl = 30net.ipv4.tcp_keepalive_probes = 3net.ipv4.tcp_slow_start_after_idle = 0net.ipv4.ip_local_port_range = 1024 65535# ---------- 文件系统 ----------fs.file-max = 2097152fs.nr_open = 1048576fs.inotify.max_user_watches = 524288fs.inotify.max_user_instances = 8192# ---------- 内核 ----------kernel.pid_max = 4194304kernel.threads-max = 4194304kernel.shmmax = 68719476736kernel.shmall = 4294967296# ---------- 容器/cgroup 相关 ----------net.ipv4.ip_forward = 1net.bridge.bridge-nf-call-iptables = 1net.bridge.bridge-nf-call-ip6tables = 1

加载：

bash
sysctl -p

7.2 limits.conf（`/etc/security/limits.conf`）

conf
# 系统全局* soft nofile 65535* hard nofile 65535* soft nproc 65535* hard nproc 65535# 特定用户mysql soft nofile 65535mysql hard nofile 65535mysql soft nproc 65535mysql hard nproc 65535# rootroot soft nofile 1048576root hard nofile 1048576

7.3 Prometheus node_exporter 告警规则

yaml
groups:-name:node_alertsrules:-alert:HighLoadAverageexpr:node_load5>(countby(instance)(node_cpu_seconds_total{mode="idle"})*1.5)for:5mlabels:severity:warningannotations:summary:"{{ $labels.instance }} 5 分钟 load 高于 CPU 核数 1.5 倍"-alert:HighCPUUsageexpr:(1-avgby(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])))*100>80for:5mlabels:severity:warningannotations:summary:"{{ $labels.instance }} CPU 使用率超过 80%"-alert:HighMemoryUsageexpr:(1-(node_memory_MemAvailable_bytes/node_memory_MemTotal_bytes))*100>85for:5mlabels:severity:warningannotations:summary:"{{ $labels.instance }} 内存使用率超过 85%"-alert:HighDiskUsageexpr:(1-(node_filesystem_avail_bytes{fstype!="tmpfs"}/node_filesystem_size_bytes{fstype!="tmpfs"}))*100>85for:5mlabels:severity:warningannotations:summary:"{{ $labels.instance }}{{ $labels.mountpoint }} 磁盘使用率超过 85%"-alert:HighDiskIOexpr:rate(node_disk_io_time_seconds_total[5m])*100>80for:5mlabels:severity:warningannotations:summary:"{{ $labels.instance }} 磁盘 {{ $labels.device }} IO 使用率超过 80%"-alert:DiskAwaitHighexpr:rate(node_disk_read_time_seconds_total[5m])/rate(node_disk_reads_completed_total[5m])>0.05for:5mlabels:severity:warningannotations:summary:"{{ $labels.instance }} 磁盘 {{ $labels.device }} await 超过 50ms"-alert:HighNetworkTrafficexpr:rate(node_network_receive_bytes_total{device!="lo"}[5m])*8>8000000000for:5mlabels:severity:warningannotations:summary:"{{ $labels.instance }} 网络接收速率超过 8Gbps"-alert:HighConntrackUsageexpr:node_nf_conntrack_entries/node_nf_conntrack_entries_limit*100>80for:5mlabels:severity:warningannotations:summary:"{{ $labels.instance }} conntrack 表使用率超过 80%"-alert:OOMKilledexpr:increase(node_vmstat_oom_kill[5m])>0for:0mlabels:severity:criticalannotations:summary:"{{ $labels.instance }} 发生 OOM"-alert:HighContextSwitchexpr:rate(node_context_switches_total[5m])>100000for:5mlabels:severity:warningannotations:summary:"{{ $labels.instance }} 上下文切换超过 10万/s"

7.4 自动化巡检脚本（`/usr/local/bin/sys_health_check.sh`）

bash
#!/usr/bin/env bash# 系统健康巡检# 输出：/var/log/sys_health/$(hostname)-$(date +%F).logLOG_DIR=/var/log/sys_healthLOG_FILE="$LOG_DIR/$(hostname)-$(date +%F).log"mkdir -p "$LOG_DIR"exec > >(tee -a "$LOG_FILE") 2>&1echo"===== System Health Check ====="echo"Time: $(date '+%F %T')"echo"Hostname: $(hostname)"echo"----- Uptime -----"uptimeecho"----- CPU -----"top -bn1 | head -10echo"----- Memory -----"free -hecho"Swap info:"cat /proc/meminfo | grep -E "SwapTotal|SwapFree"echo"----- Disk -----"df -hdf -iecho"----- Disk IO -----"iostat -xz 1 3 2>/dev/null || echo"iostat not installed"echo"----- Network -----"ss -secho"Established connections:"ss -antp state established | head -20echo"----- Top 10 CPU -----"ps -eo pid,ppid,user,pcpu,pmem,etime,args --sort=-pcpu | head -10echo"----- Top 10 Memory -----"ps -eo pid,ppid,user,pcpu,pmem,rss,args --sort=-rss | head -10echo"----- Top 10 IO -----"pidstat -d 1 2 2>/dev/null | tail -20 || echo"pidstat not installed"echo"----- OOM -----"dmesg -T | grep -i "out of memory" | tail -5echo"----- Load Average -----"cat /proc/loadavgecho"----- Conntrack -----"cat /proc/sys/net/netfilter/nf_conntrack_count 2>/dev/nullcat /proc/sys/net/netfilter/nf_conntrack_max 2>/dev/nullecho"----- File Descriptor -----"cat /proc/sys/fs/file-nrecho"===== End ====="

bash
chmod +x /usr/local/bin/sys_health_check.sh# 每天跑一次cat > /etc/cron.d/sys_health <<'EOF'0 8 * * * root /usr/local/bin/sys_health_check.shEOF

7.5 Grafana 面板 JSON（基础系统面板）

json
{"title":"Linux System Overview","panels":[{"title":"CPU Usage","type":"graph","targets":[{"expr":"1 - avg by(instance)(rate(node_cpu_seconds_total{mode=\"idle\"}[5m]))","legendFormat":"{{instance}}"}]},{"title":"Memory Usage","type":"graph","targets":[{"expr":"(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100","legendFormat":"{{instance}}"}]},{"title":"Load Average","type":"graph","targets":[{"expr":"node_load5","legendFormat":"{{instance}} load5"}]},{"title":"Disk Usage","type":"graph","targets":[{"expr":"(1 - (node_filesystem_avail_bytes{fstype!=\"tmpfs\"} / node_filesystem_size_bytes{fstype!=\"tmpfs\"})) * 100","legendFormat":"{{instance}} {{mountpoint}}"}]},{"title":"Disk IOPS","type":"graph","targets":[{"expr":"rate(node_disk_reads_completed_total[5m]) + rate(node_disk_writes_completed_total[5m])","legendFormat":"{{instance}} {{device}}"}]},{"title":"Network Traffic","type":"graph","targets":[{"expr":"rate(node_network_receive_bytes_total{device!=\"lo\"}[5m]) * 8","legendFormat":"{{instance}} RX"},{"expr":"rate(node_network_transmit_bytes_total{device!=\"lo\"}[5m]) * 8","legendFormat":"{{instance}} TX"}]}]}

八、日志或指标观察方法

8.1 关键指标速查

维度	指标	命令	健康基线（参考）	异常信号
CPU	load5	`uptime`	< 0.7 * 核数	> 1.0 * 核数
CPU	idle%	`top` / `mpstat`	> 20%	< 10%
CPU	iowait%	`top` / `mpstat`	< 10%	> 30%
CPU	上下文切换/s	`vmstat`	< 50k	> 100k
CPU	中断/s	`vmstat`	< 5k	> 10k
内存	available%	`free`	> 20%	< 10%
内存	swap used	`free`	接近 0	持续上涨
内存	OOM	`dmesg`	0	> 0
磁盘	%util	`iostat`	< 70%	> 90%
磁盘	await	`iostat`	< 10ms（SSD < 1ms）	> 30ms
磁盘	空间%	`df`	< 80%	> 90%
磁盘	inode%	`df -i`	< 80%	> 90%
网络	带宽%	`sar -n DEV`	< 70%	> 90%
网络	TIME_WAIT	`ss`	< 10k	> 50k
网络	CLOSE_WAIT	`ss`	< 100	> 1000
网络	丢包率	`netstat -s`	极低	> 1%
进程	fd	`/proc/PID/fd`	< 1000	> 10000
进程	线程数	`ps`	< 100	> 500
进程	D 状态	`ps`	0	> 0

8.2 重点日志

路径	用途
`/var/log/messages`	系统综合日志
`/var/log/syslog` (Debian)	系统综合日志
`/var/log/kern.log`	内核日志
`/var/log/dmesg`	启动日志
`/var/log/cron`	cron 执行日志
journald	systemd 日志
应用日志	在 `/var/log/<app>/` 或 `/data/logs/`

8.3 关键观察方法

vmstat 1 5
：每秒采样 5 次，看趋势；
iostat -xz 1 5
：磁盘每秒采样；
sar -u -r -d -n DEV 1 100
：100 次采样，便于后续分析；
perf record/report
：CPU 热点采样；
strace -p PID -c
：系统调用采样；
tcpdump -w
：网络抓包；
journalctl -k
：内核日志；
ausearch
：auditd 日志。

九、排查路径

9.1 排查路径速查表

现象	第一动作	关键命令	进一步动作
系统整体慢	看 load	`uptime` 、`top`	mpstat / iostat
CPU 100%	找进程	`top -c` 、`ps -eo --sort=-pcpu`	perf / strace
单核满	找进程	`top -Hp PID`	单线程分析
内存满	找进程	`ps -eo --sort=-rss`	pmap / heap dump
OOM	看 dmesg	`dmesg	grep OOM`
磁盘满	找大文件	`du -sh` 、`find -size`	truncate 或 mv
磁盘 IO 满	找进程	`iotop`	调整应用 IO
inode 满	找小文件	`find -size -1k -type f	wc -l`
fd 满	找进程	`lsof -p`	调大 ulimit
网络慢	看带宽	`sar -n DEV` 、`iftop`	限流或扩容
丢包	看统计	`netstat -s`	排查链路
DNS 慢	看解析	`dig +stats`	换 DNS
TIME_WAIT 多	调内核	`sysctl -a	grep tw`
CLOSE_WAIT 多	找进程	`ss -antp`	修应用
SSH 卡顿	看 load	`uptime` 、`top`	排查同主机其他进程

9.2 完整排查流程

收到"系统慢"投诉   ↓[步骤 1] 全局快查（30 秒）   ├── load 高？→ CPU/IO 维度   ├── 内存满？→ 内存维度   ├── 磁盘满？→ 磁盘维度   └── 网络慢？→ 网络维度   ↓[步骤 2] 维度深入（1-3 分钟）   ↓[步骤 3] 进程定位（3-5 分钟）   ↓[步骤 4] 根因分析（5-10 分钟）   ├── 应用 bug？   ├── 配置不当？   ├── 容量不足？   └── 内核/硬件问题？   ↓[步骤 5] 应急处置（10-30 分钟）   ├── 杀进程   ├── 限流   ├── 扩容   └── 切流   ↓[步骤 6] 验证（持续观察）   ├── 指标回归基线   ├── 业务恢复   └── 监控正常   ↓[步骤 7] 长期治理   ├── 容量规划   ├── 监控告警   ├── 自动化运维   └── 架构优化

十、风险提醒

10.1 杀进程风险

不要在没确认进程归属前 kill；
kill -STOP
是安全的（暂停进程，便于排查）；
kill -TERM
是优雅退出，进程会清理资源；
kill -9
跳过清理逻辑，可能导致共享内存泄漏、socket 没关闭；
kill -9
对数据库进程可能导致主从不一致；
kill -9 -1
会杀所有进程，等于 pkill -9 -P 1，慎用。

10.2 修改内核参数风险

sysctl -p
会立即生效，部分参数可能导致连接重置；
vm.swappiness
调到 0：内核只在紧急情况下 swap，可能 OOM；
vm.swappiness
调到 100：积极 swap，可能影响 IO；
tcp_tw_recycle
在 4.12+ 已废弃，开启可能导致 NAT 后面的客户端连不上；
修改 ip_local_port_range 不要太小，会导致端口耗尽；
修改 somaxconn 要配套修改应用 backlog；
修改前必须 sysctl -a > backup.txt 备份。

10.3 修改数据库参数风险

不要在排查系统慢时随意调数据库参数；
数据库参数调整要走变更流程；
调 innodb_buffer_pool_size 等大参数会触发重启；
调 innodb_thread_concurrency 影响并发；
调小 max_connections 会拒绝连接；
调整 innodb_io_capacity 影响 IO 行为。

10.4 清理日志风险

不要用 rm 删除正在写入的日志文件（虽然 inode 释放，但句柄仍占用）；
用 truncate -s 0 截断（保留 inode，进程继续写）；
用 cat /dev/null > file 清空（保留 inode）；
mv
文件后让 rsyslog 重启生成新文件；
关键日志清理前先归档；
不要在 logrotate 配置错误时手动清理，会导致日志断层。

10.5 重启服务风险

重启前必须评估影响范围；
重启前必须通知相关方；
重启前必须有回滚方案；
重启前必须备份配置；
数据库重启要走变更流程；
关键服务要在低峰期重启。

10.6 批量脚本风险

批量执行的脚本必须有 dry-run 模式；
必须支持并发控制（-p 5）；
必须有超时控制；
必须有失败中止逻辑；
必须有日志输出；
必须有异常通知；
不要在生产环境无审阅执行 ansible all -m shell -a 'rm -rf /tmp/*'。

10.7 数据迁移风险

数据迁移前必须有备份；
迁移后必须有验证；
迁移过程中必须有校验；
迁移失败必须能回滚；
迁移期间必须有监控；
跨主机迁移要注意带宽影响。

10.8 误判风险

单核 100% 不一定是瓶颈，可能是单线程程序的正常行为；
load 高不一定是系统问题，可能是业务正常增长；
内存占用高不一定是泄漏，可能是 Linux 的 page cache；
磁盘 IO 高不一定是问题，可能是业务备份；
网络流量高不一定是攻击，可能是业务；
关键是要和业务基线对比，不要单看指标绝对值。

十一、验证方式

11.1 验证 CPU

bash
# 1. 实时看 CPUtophtopmpstat -P ALL 1 5# 2. 看 CPU 热点是否消除perf top -p <PID># 修复后应该没有 dominant 函数# 3. 上下文切换是否下降vmstat 1 5# cs 列# 4. 进程 CPU 占用是否下降top -p <PID># %CPU 应该 < 50%

11.2 验证内存

bash
# 1. 看 availablefree -h# available 应该 > total * 20%# 2. 看 swap 活动vmstat 1 5# si/so 应该接近 0# 3. 看 OOM 是否停止dmesg -T | grep -i oom# 应该没有新 OOM# 4. 看进程 RSSps -eo pid,rss,args --sort=-rss | head# 内存占用应该稳定或下降

11.3 验证磁盘

bash
# 1. 看磁盘使用率df -h# 应该 < 80%# 2. 看磁盘 IOiostat -xz 1 5# %util 应该 < 70%，await 应该正常# 3. 看 inodedf -i# 应该 < 80%# 4. 看是否有 deleted 文件lsof | grep deleted# 应该没有大文件

11.4 验证网络

bash
# 1. 看带宽sar -n DEV 1 5# rxkB/s + txkB/s 应该 < 带宽 * 70%# 2. 看连接数ss -s# 各状态连接数应该稳定# 3. 看 TIME_WAITss -ant state time-wait | wc -l# 应该 < 10k# 4. 看丢包netstat -s | grep retransmit# 应该没有增长# 5. 业务连通性curl -v -m 5 http://example.com/nc -vz example.com 80

11.5 验证业务

bash
# 1. 应用日志tail -f /var/log/app/app.log# 应该没有 timeout、error# 2. 监控告警# 应该没有 critical 告警# 3. 用户反馈# 通过客服、工单、用户群确认恢复# 4. 关键指标# P99 延迟、错误率、QPS 回归基线

11.6 验证内核参数

bash
# 看参数是否生效sysctl net.core.somaxconnsysctl vm.swappiness# 看进程 ulimitcat /proc/<PID>/limits | grep "open files"# 看文件描述符cat /proc/sys/fs/file-nr# 第一列已分配，第二列已使用未释放，第三列最大

十二、回滚方案

12.1 sysctl 回滚

bash
# 从备份恢复cp -a /etc/sysctl.conf.bak /etc/sysctl.confsysctl -p# 验证sysctl net.core.somaxconn

12.2 limits.conf 回滚

bash
# 从备份恢复cp -a /etc/security/limits.conf.bak /etc/security/limits.conf# 当前会话生效需要重新登录# 新进程会立即生效

12.3 杀进程回滚（重启进程）

bash
# 如果杀错了进程，立即重启systemctl restart <service># 或/usr/bin/<service> --config /etc/<service>.conf &# 验证systemctl status <service>ss -tlnp | grep <port>

12.4 配置文件回滚

bash
# sshdcp -a /etc/ssh/sshd_config.bak /etc/ssh/sshd_configsystemctl reload sshd# nginxcp -a /etc/nginx/nginx.conf.bak /etc/nginx/nginx.confnginx -t && nginx -s reload# mysqlcp -a /etc/my.cnf.bak /etc/my.cnfsystemctl restart mysqld

12.5 应用配置回滚

bash
# 1. 从备份恢复代码git checkout HEAD~1# 2. 重启应用systemctl restart myapp# 3. 验证业务curl http://localhost:8080/health

12.6 流量切回

bash
# 如果切流后业务还是慢，切回旧版本# 走 CDN/GSLB 控制台切回# 如果是 K8s，调整流量比例kubectl patch svc myapp -p '{"spec":{"selector":{"version":"v1"}}}'# 如果是负载均衡调整# 走 SLB 控制台

12.7 回滚原则

所有配置修改前必须备份；
所有修复操作必须可回滚；
回滚后必须验证业务；
回滚操作要写入 incident 报告；
回滚和修复要走变更流程。

十三、生产环境注意事项

13.1 变更窗口

紧急修复可立即执行（视为紧急变更）；
大型修复（内核参数调整、数据库参数）必须低峰期；
涉及多主机的批量修复必须分批灰度；
涉及架构变更（迁移、扩容）必须先评估；
变更前通知所有相关方；
变更期间监控告警灵敏度提高；
变更后观察 24h-72h。

13.2 监控告警

必须有 CPU、内存、磁盘、网络的基础监控；
必须有应用层的监控（QPS、延迟、错误率）；
必须有日志监控（关键字告警）；
必须有 JVM/数据库等运行时监控；
告警阈值要结合业务基线；
告警要有分级（warning、critical）；
告警要有抑制规则，避免告警风暴。

13.3 容量规划

基于历史数据预测未来容量；
定期压测验证容量上限；
业务上线前评估容量影响；
定期清理历史数据；
扩容要有预案（横向、纵向）；
缩容要小心，可能影响可用性。

13.4 应急响应

应急流程要写入 Runbook；
应急联系人要轮值；
应急演练要定期进行；
应急工具要提前准备好（脚本、文档）；
应急操作要可回滚；
应急后必须复盘。

13.5 团队协作

排查要避免单兵作战；
关键操作必须双人复核；
排查结果要共享；
复盘要公开；
改进项要跟踪闭环。

13.6 工具与平台

Prometheus + Grafana：监控可视化；
node_exporter：基础指标采集；
process-exporter：进程指标；
nvidia_gpu_exporter：GPU 指标（如果有）；
ELK/EFK：日志聚合；
Alertmanager：告警聚合；
堡垒机：操作审计；
Ansible：批量运维；
蓝绿部署/灰度发布：降低发布风险。

十四、总结

"系统变慢"是运维最常见的问题之一，也是最能体现基本功的问题。把这 8 个命令用熟，能解决 80% 的问题：

uptime
/ top：一眼看负载；
vmstat 1 5
：CPU + 内存 + IO 概览；
iostat -xz 1
：磁盘 IO 详情；
free -h
：内存详情；
df -h
+ du：磁盘空间；
ss -antp
：网络连接；
pidstat
/ strace / perf：进程维度；
dmesg -T
+ journalctl：内核与系统日志。

把这 8 个命令沉淀成肌肉记忆，配合"系统全局 → 维度深入 → 进程定位 → 根因分析 → 应急处置 → 验证"的固定流程，首次定位时间从 30 分钟降到 5 分钟是完全可能的。

最后强调几个易踩的坑：

不要只看 top，不看 iostat —— IO 瓶颈容易被忽视；
不要只看 load，不看 iowait —— IO 满时 CPU 空闲但 load 高；
不要只看 free，不看 available —— buffer/cache 可回收；
不要只看 %util，不看 await —— SSD 上 %util 不可信；
不要只杀进程，不查根因 —— 治标不治本；
不要直接 rm 正在写的日志 —— 用 truncate；
不要在排查时改内核参数 —— 先观察，再优化；
不要单凭一条线索下结论 —— 多维度证据关联。

把"排查路径速查表"打印贴到工位，把"应急 Runbook"沉淀到知识库，把"监控告警"部署到所有节点，把"应急演练"排进月度计划。这四件事做完，团队处理"系统变慢"的能力会上一个台阶。

真正的运维能力不是会多少花哨的工具，而是能在压力下用最短时间找到根因。能找到根因，问题就解决了一半。

文末阅读福利

仅目前来说，无论是运维人转型提升，还是零基础想转行IT，最好的岗位就是云计算运维&SRE岗位。

为了帮助大家早日快速入门云计算运维领域，给大家整理了一套【最新运维资料】高级运维工程师必备技能资料包（文末一键免费领取），内容有多详实丰富看下图！

（是扫码领取，不是在公众号后台回复，别看错了哦）

本文来自网友投稿或网络内容，如有侵犯您的权益请联系我们删除，联系邮箱：wyl860211@qq.com 。

Linux 系统变慢?用这 8 个命令快速定位瓶颈

Linux 系统变慢？用这 8 个命令快速定位瓶颈

一、问题背景

二、适用场景

三、核心知识点

3.1 性能分析的方法论

3.2 load average 的含义

3.3 CPU 维度

3.4 内存维度

3.5 IO 维度

3.6 网络维度

3.7 文件系统维度

3.8 进程维度

3.9 内核参数

3.10 工具生态

四、整体排查或实施思路

第一层：系统全局指标（30 秒）

第二层：单维度深入（1-3 分钟）

第三层：进程维度定位（3-5 分钟）

第四层：修复与验证（5-15 分钟）

排查路径速查表

五、实战步骤

5.1 步骤一：系统全局快查（30 秒）

5.2 步骤二：CPU 维度深入

5.3 步骤三：内存维度深入

5.4 步骤四：磁盘 IO 维度深入

5.5 步骤五：网络维度深入

5.6 步骤六：进程维度深挖

5.7 步骤七：常见瓶颈场景排查示例

场景 1：CPU 跑满

场景 2：内存耗尽 + OOM

场景 3：磁盘 IO 满

场景 4：磁盘写满

场景 5：网络连接耗尽

场景 6：fd 耗尽

5.8 步骤八：应急处置

5.9 步骤九：长期治理

六、常用命令

6.1 综合快查

6.2 CPU

6.3 内存

6.4 IO

6.5 网络

6.6 进程

6.7 内核

6.8 应急

七、配置示例

7.1 sysctl 内核参数调优（/etc/sysctl.conf）

7.2 limits.conf（/etc/security/limits.conf）

7.3 Prometheus node_exporter 告警规则

7.4 自动化巡检脚本（/usr/local/bin/sys_health_check.sh）

7.5 Grafana 面板 JSON（基础系统面板）

八、日志或指标观察方法

8.1 关键指标速查

8.2 重点日志

8.3 关键观察方法

九、排查路径

9.1 排查路径速查表

9.2 完整排查流程

十、风险提醒

10.1 杀进程风险

10.2 修改内核参数风险

10.3 修改数据库参数风险

10.4 清理日志风险

10.5 重启服务风险

10.6 批量脚本风险

10.7 数据迁移风险

10.8 误判风险

十一、验证方式

11.1 验证 CPU

11.2 验证内存

11.3 验证磁盘

11.4 验证网络

11.5 验证业务

11.6 验证内核参数

十二、回滚方案

12.1 sysctl 回滚

12.2 limits.conf 回滚

12.3 杀进程回滚（重启进程）

12.4 配置文件回滚

7.1 sysctl 内核参数调优（`/etc/sysctl.conf`）

7.2 limits.conf（`/etc/security/limits.conf`）

7.4 自动化巡检脚本（`/usr/local/bin/sys_health_check.sh`）