# Linux 性能排查：CPU/内存/磁盘/网络一条龙

作者：星苒鸭（xingranya）
发布日期：2026-02-06
更新时间：2026-02-06
原文：https://blog.xran.uk/linux-performance-troubleshooting/

服务器“变慢”时，最容易犯的错就是：**第一反应重启**。重启确实能“治标”，但你会永远不知道根因是什么——下次还会慢。

这篇我把常见的性能排查流程整理成一条线：从“现象”到“指标”，再到“定位到进程/线程”，最后给出一份可以直接照着走的命令清单。

![监控与指标：先把现象量化](https://images.unsplash.com/photo-1551288049-bebda4e38f71?auto=format&fit=crop&w=1600&q=80&ixlib=rb-4.1.0)

### 一句话原则：先量化，再定位

你要回答的核心问题只有 3 个：

- **慢在哪里**：CPU？IO？网络？锁竞争？还是外部依赖？
- **慢到什么程度**：是否真的异常（对比历史/基线）？
- **是谁在慢**：哪一个进程、哪一类请求、哪条链路？

### 第 0 步：确认“慢”的表现（别凭感觉）

建议先记录三类信息（越快越好）：

- **时间窗**：从什么时候开始慢？是否和发布/定时任务/流量波动有关？
- **范围**：全机慢还是某个服务慢？只慢写入还是读也慢？
- **症状**：接口超时、CPU 飙高、磁盘打满、连接数暴涨、负载飙高……

### 第 1 步：看整体健康（30 秒内必须得到判断）

```bash
# 1) 负载与运行时间
uptime

# 2) CPU/内存/进程整体概览
top

# 3) 磁盘容量与 inode（很多“慢”其实是写不进去）
df -h
df -i
```

**负载（Load Average）怎么理解？**

- Load 不是 CPU 使用率，它更像“排队的人数”（可运行 + 不可中断 IO 等待）。
- 经验判断：`load > CPU 核心数` 并不一定坏，但如果同时 **iowait 高** 或 **响应时间上升**，就要警惕。

### 第 2 步：CPU 排查（算力不够 / 线程打架 / 上下文切换）

```bash
# 以“每秒刷新”观察趋势
top -d 1

# 查看每个 CPU 核的利用率（mpstat 属于 sysstat 套件）
mpstat -P ALL 1

# 看进程/线程级别（pidstat 也在 sysstat 里）
pidstat -u 1
pidstat -t -u -p <PID> 1
```

重点盯这些信号：

- **us 高**：用户态计算重（编码/压缩/加密/序列化/大循环）
- **sy 高**：系统调用重（大量网络/文件操作、频繁创建销毁对象）
- **wa 高**：IO 等待（磁盘/网络存储慢）——这时 CPU 可能并不“忙”，但任务卡在等 IO
- **cs（上下文切换）异常**：线程太多、锁竞争严重

> 小技巧：如果你看到 load 很高，但 CPU us/sy 不高、wa 很高，优先怀疑 IO。

### 第 3 步：内存排查（泄漏 / 缓存挤压 / 频繁换页）

```bash
# 内存概览（重点看 available，而不是 free）
free -h

# 观察 swap/换页/上下文切换等（1 秒刷新）
vmstat 1

# 找出 RSS 最大的进程
ps aux --sort=-rss | head
```

怎么看 `free -h`：

- **available** 才是关键：表示在不明显影响系统的情况下还能“借出来”的内存（含可回收的 page cache）。
- **swap 在增长** 且系统变卡：十有八九是内存压力/泄漏/误配。

怎么看 `vmstat`：

- `si/so`（swap in/out）持续非 0：说明在换页，性能通常会明显下降。
- `r`（run queue）高：说明 CPU 竞争激烈或任务积压。

### 第 4 步：磁盘/IO 排查（最常见的“暗杀者”）

```bash
# iostat 观察磁盘队列与延迟
iostat -xz 1

# 找出谁在疯狂读写（需要 root）
iotop
```

`iostat -xz` 里最值得看：

- **%util**：接近 100% 说明设备接近饱和（不等于一定慢，但通常要警惕）
- **await**：请求平均等待时间（延迟）
- **r/s、w/s、rkB/s、wkB/s**：吞吐与 IOPS 方向

常见坑：

- **磁盘没满，但 inode 满了**：`df -i` 一眼看出
- **日志疯狂写**：尤其是 debug 级别、每请求一条
- **容器 overlayfs**：小文件写入会更吃亏，注意 volume 策略

### 第 5 步：网络排查（连接数、丢包、拥塞、DNS）

```bash
# TCP/UDP 连接概览
ss -s

# 看监听端口与进程
ss -tulpn

# 看连接状态（比如 TIME_WAIT 爆炸）
ss -ant | head
```

如果你怀疑是外部依赖（数据库/缓存/第三方 API）导致：

- 先确认**超时**与**重试**策略是否合理
- 看连接池是否耗尽（大量等待连接）
- 看 DNS 是否抖动（偶发慢就是典型）

### 快速清单：你可以按这个顺序走

- **1 分钟**：`uptime`、`top`、`df -h`、`df -i`
- **3 分钟**：`vmstat 1`、`iostat -xz 1`、`ss -s`
- **5 分钟**：`pidstat -u 1` / `pidstat -t -p PID 1` 定位到进程/线程
- **10 分钟**：结合业务日志/链路追踪，回到“哪类请求慢”

### 总结

性能排查不是玄学，核心是：**把“慢”拆到 CPU/内存/IO/网络四象限里，再下钻到进程/线程**。你越早建立“基线”（正常时的指标范围），排障越快。

> 封面与配图来自 Unsplash（免费使用授权）。