常用排障¶

先记录故障开始时间、影响范围和最近变更。不要一开始就重启服务；先保留现场、采集指标和日志。

先看整体状态¶

uptime
free -h
df -h
top

CPU 使用率高¶

# CPU 核数与负载
nproc
uptime

# CPU 使用最高的进程、线程
ps -eo pid,ppid,user,%cpu,%mem,stat,etime,cmd --sort=-%cpu | head -20
top -H -p <PID>

# 每秒观察 CPU、上下文切换和运行队列
vmstat 1 10

load average 反映的是等待或运行队列，不等同于 CPU 使用率；需结合 CPU 核数和进程状态判断。

wa（iowait）高：通常是磁盘或存储延迟，不是纯 CPU 瓶颈。
sy（system）高、上下文切换频繁：检查大量短连接、中断或异常线程。
load 持续高于 CPU 核数且 r 队列很高：进程争抢 CPU，考虑限流、扩容或优化任务。

内存使用率高¶

Linux 会将可用内存用于 page cache，因此优先看 available，不要只看 used。

# 内存、缓存与 swap 总览
free -h

# 内存占用最高的进程
ps -eo pid,ppid,user,%mem,rss,vsz,etime,cmd --sort=-rss | head -20

# 每秒观察内存与 swap in/out
vmstat 1 10

# 单进程内存映射摘要
sudo pmap -x <PID> | tail -n 1

available 持续很低，且 swap 的 si/so 不为 0：系统正在换页，性能会下降。
某进程 RSS 持续增长：对比历史指标、请求量与应用堆内存，排查内存泄漏。
容器环境还要检查 cgroup 限制；宿主机有空闲内存不代表容器没有触发内存上限。

连接数异常¶

先区分监听端口、已建立连接和大量短连接/半连接。

# 所有监听端口及进程
sudo ss -lntp

# TCP 连接状态统计
ss -ant | awk 'NR>1 {count[$1]++} END {for (state in count) print state, count[state]}' | sort

# 指定端口的已建立连接数
sudo ss -ant state established '( sport = :80 or dport = :80 )' | wc -l

# 某进程打开的文件描述符数量
sudo ls /proc/<PID>/fd | wc -l

若 TIME-WAIT、CLOSE-WAIT 或 SYN-RECV 异常增多，结合负载均衡、客户端重试、应用连接池和网络日志判断。CLOSE-WAIT 长期累积通常意味着应用没有正确关闭连接。

内存溢出（OOM）¶

OOM 时内核可能终止一个进程以保护系统。先确认是否发生过 OOM 以及被终止的对象。

# 当前启动周期和内核日志中搜索 OOM
journalctl -k -b | grep -i -E 'oom|out of memory|killed process'
dmesg -T | grep -i -E 'oom|out of memory|killed process'

# Docker 容器是否因 OOM 退出
docker inspect <container> --format '{{.State.OOMKilled}}'

处理顺序：确认被终止的进程或容器；检查请求突增、批处理、缓存增长、运行时堆设置和最近变更；修复泄漏、限制并发或扩容后，再复测峰值负载。

磁盘与日志¶

# 找出当前目录下占用最大的文件或目录
du -xh --max-depth=1 . | sort -h

# 查看最近系统错误
journalctl -p err -b

# 持续追踪服务日志
journalctl -u <service-name> -f