---
id: devops.linux.troubleshooting
title: 线上排查：CPU、内存、磁盘、网络、日志的定位思路
type: lesson
domain: devops
stack: [linux]
tags: [排查, top, 负载, OOM, 磁盘, TIME_WAIT, pprof]
level: intermediate
prerequisites: [devops.linux.commands]
est_hours: 3
related: [devops.linux.scenario.incident-troubleshooting, devops.linux.interview]
week: [14]
order: 2
---

# 线上排查：CPU、内存、磁盘、网络、日志的定位思路

## 解释说明

**排查的总顺序**：先止血（回滚、扩容、限流、重启），再定位，最后复盘。定位时**从现象到资源再到代码**：

| 资源 | 看什么 | 命令 |
| --- | --- | --- |
| 负载 | load average 和 CPU 核数的比较；高负载可能是 CPU 忙，也可能是 IO 等待 | `uptime`、`top`（看 `us` / `sy` / `wa`） |
| CPU | 哪个进程、哪个线程占用高 | `top -H -p PID`；Go 用 pprof、Python 用 py-spy |
| 内存 | 剩余可用内存（看 `available`）、是否用到 swap、是否有 OOM | `free -h`、`journalctl -k | grep -i oom` |
| 磁盘 | 空间和 inode 是否用满、IO 是否繁忙 | `df -h`、`df -i`、`du -sh`、`iostat -x 1` |
| 网络 | 端口监听、连接状态分布、连接数是否打满 | `ss -lntp`、`ss -ant` 统计状态、`curl -w` 看耗时 |
| 日志 | 错误日志、慢请求、时间点 | `journalctl -u 服务`、`grep`、`awk` |

**几个关键概念**

- **load average**：正在运行和等待运行（包括等待 IO）的进程数的平均值。4 核机器 load 为 4 左右算满载。
- **`wa`（iowait）高**：CPU 在等磁盘，问题在 IO（慢查询扫盘、日志写太多），而不是计算。
- **OOM Killer**：内存耗尽时内核按评分杀掉进程，应用日志里往往什么都没有，只能在内核日志里看到 `Killed process`。
- **TIME_WAIT 很多**：主动关闭连接的一方会进入 TIME_WAIT。大量短连接（每次请求都新建连接）导致，解决办法是复用连接（HTTP keep-alive、连接池）。
- **CLOSE_WAIT 很多**：对方已关闭，本方没有关闭——通常是代码里忘了关闭连接（如 Go 的 `resp.Body.Close()`）。

**语言级工具**：Go 服务开启 `net/http/pprof`（只在内网端口暴露），`go tool pprof http://127.0.0.1:6060/debug/pprof/profile?seconds=30` 采集 CPU 热点，`/debug/pprof/heap` 看内存，`/debug/pprof/goroutine` 看 goroutine 泄漏。Python 用 `py-spy top --pid PID`。

## 案例

- 接口变慢：`top` 看到 `wa` 30%，`iostat` 显示磁盘利用率 100%；进一步发现是同一台机器上的数据库在做全表扫描的报表查询。把报表改到从库。
- 服务每天半夜重启：应用日志没有错误，`journalctl -k` 里有 `Out of memory: Killed process ... (api)`。用 pprof 看 heap，发现一个按天累积的本地缓存没有上限。
- `ss -ant` 统计出几千个 CLOSE_WAIT：代码里调用第三方接口后没有关闭响应体。

## 代码示例

一分钟快照脚本 [examples/log-analysis/diag.sh](examples/log-analysis/diag.sh)（只读命令）的核心部分：

```bash
uptime
ps -eo pid,user,%cpu,%mem,etime,cmd --sort=-%cpu | head -n 10
free -h
df -h -x tmpfs -x devtmpfs
ss -ant | awk 'NR > 1 {count[$1]++} END {for (s in count) print s, count[s]}'
```

Go 服务暴露 pprof（只监听本机端口，不要暴露到公网）：

```go
package main

import (
	"log"
	"net/http"
	_ "net/http/pprof" // 注册 /debug/pprof/* 到 http.DefaultServeMux
)

func main() {
	go func() {
		// 单独的端口，只监听 127.0.0.1；业务服务用自己的 ServeMux，不暴露 pprof
		log.Println(http.ListenAndServe("127.0.0.1:6060", nil))
	}()
	biz := http.NewServeMux()
	biz.HandleFunc("GET /healthz", func(w http.ResponseWriter, r *http.Request) { w.Write([]byte("ok")) })
	log.Fatal(http.ListenAndServe(":8080", biz))
}
```

```bash
# 在服务器上采集 30 秒 CPU 数据，然后看最耗 CPU 的函数
go tool pprof -top http://127.0.0.1:6060/debug/pprof/profile?seconds=30
# goroutine 数量是否持续增长（泄漏）
curl -s http://127.0.0.1:6060/debug/pprof/goroutine?debug=1 | head -n 1
```

## 易错点

- **一上来就重启**：现场没了，问题下次还会出现。重启前至少保存快照（diag.sh 的输出、pprof、日志片段）。
- **只看 CPU 不看 iowait**：负载高不一定是计算问题。
- **`free` 看 `free` 列认为内存不够**：Linux 会把空闲内存用作缓存，要看 `available`。
- **在业务端口暴露 pprof**：泄露内部信息，还能被用来消耗资源。
- **删了大文件磁盘空间没释放**：`lsof +L1` 找到仍持有已删除文件的进程。
- **排查结论没有数据支撑**：每一步都记录命令和输出，便于复盘。

## 面试常问

见 [Linux 面试题](interview.md)：CPU 飙高怎么排查、内存泄漏怎么查、磁盘满了怎么办、TIME_WAIT 和 CLOSE_WAIT。