问题背景与适用场景

服务器变慢是最常见的运维问题之一。业务人员报告"系统卡顿"，工程师登录服务器后看到的是一堆需要排查的线索：CPU 使用率飙高、内存占用异常、磁盘 IO 等待、进程僵死、网络连接异常——每个指标都可能是根因，也可能是表象。运维工程师的价值就在于能从这堆交织的线索中快速定位真正的瓶颈。

本文面向 Linux 运维工程师和 DevOps 工程师，目标是在服务器变慢时，有一套可遵循的排查思路和具体操作步骤。不是凭感觉猜，而是通过命令和指标来"看见"问题所在。

全文以一个典型场景为例：服务器 CPU 使用率突然飙高，业务响应变慢。按这个线索走下去，依次排查 CPU、内存、磁盘 IO、进程状态、网络连接，最终定位根因并修复。过程中的每一步都有判断逻辑和下一步动作，不是堆命令，而是形成完整的排查闭环。

排查前的准备：了解基线和环境

在服务器变慢之前，如果能了解正常状态下的各项指标，排查效率会大幅提升。基线数据是判断异常的前提——没有基线，就不知道 CPU 80% 是正常还是异常。

记录基线数据

生产服务器应该在稳定运行期间记录基线数据，作为后续对比的参考。可以用 cron 定期采集：

# 每小时记录一次系统关键指标到 /var/log/os baseline.log
# 追加模式，保留最近 30 天的数据
0 * * * * /bin/bash /opt/scripts/record_baseline.sh >> /var/log/os_baseline.log 2>&1

基线数据应包含：

• CPU 使用率分布（user/system/idle/irq/softirq）
• 内存使用量（used/free/available/cached/buffers）
• 磁盘 IOPS 和吞吐量
• 网络流量（bytes per second）
• 关键进程的 CPU 和内存占用
• 磁盘空间使用率

排查前的系统环境确认

发现服务器变慢后，第一步不是直接跑排查命令，而是先确认几个基本环境信息，这些信息会影响后续的命令输出和判断逻辑：

# 确认操作系统版本
cat /etc/redhat-release
# CentOS 7: CentOS Linux release 7.9.2009 (Core)
# CentOS 8 / AlmaLinux 8: AlmaLinux release 8.x

# 确认内核版本
uname -r
# 3.10.0-1160.el7.x86_64

# 确认硬件配置（用于判断资源是否真的不足）
cat /proc/cpuinfo | grep "processor" | wc -l   # CPU 核心数
free -h                                              # 内存总量
df -h                                                # 磁盘总量
cat /proc/meminfo | grep MemTotal                  # 精确内存

# 确认当前负载（这三条命令是排查入口）
uptime
# 15:30:01 up 45 days,  3:22,  2 users,  load average: 5.23, 3.10, 2.15
# load average 三个数字分别是 1分钟/5分钟/15分钟的平均负载
# 如果核心数是 8，load > 8 说明已经有进程在等待 CPU

# 确认系统架构（影响 perf、strace 等工具的使用）
arch
# x86_64

为什么 load average 重要？load average 是等待 CPU 资源或不可中断资源（磁盘 IO 等）的平均进程数量。如果 CPU 核心数是 4，但 load 是 8，说明有 8 个进程在排队等待资源。load 高不一定只是 CPU 问题，磁盘 IO 阻塞、网络 IO 阻塞都会推高 load。

第一步：快速定位是哪个资源导致的问题

在开始深入排查之前，先用几条命令快速判断是 CPU、内存、IO 还是网络出了问题：

# top 命令是排查入口，直接看默认视图
top

# 按 M 按键按内存排序，看谁吃内存最多
# 按 P 按键按 CPU 排序，看谁吃 CPU 最多
# 按 T 按键按运行时间排序，看哪个进程累计 CPU 时间最长
# 按 1 展开每个 CPU 核心的使用率（多路 CPU 服务器必看）

top 默认视图的关键指标：

%Cpu(s):  12.5 us,  3.2 sy,  0.0 ni, 82.1 id,  1.2 wa,  0.0 hi,  0.3 si,  0.0 st

• us（user）：用户态 CPU 使用率，正常业务代码在这个区域消耗
• sy（system）：内核态 CPU 使用率，系统调用、调度、IO 等待内核处理等
• id（idle）：空闲 CPU 比率，id 接近 0 说明 CPU 是瓶颈
• wa（wait IO）：等待 IO 的 CPU 比率，wa 高说明瓶颈在磁盘或网络 IO
• hi/si：硬中断/软中断 CPU 使用率，si 高可能是网络流量大或绑定到过多软中断

快速判断法则：

• us 高 + id 低 → 用户代码 CPU 占用高，查哪个进程吃 CPU
• wa 高 + id 低 → 磁盘 IO 瓶颈，查 IO 读写和进程 IO 等待
• si 高 + id 低 → 软中断频繁，可能网络流量异常
• us 和 sy 都高 + load 很高 → 可能 CPU 调度压力或大量进程竞争

使用 vmstat 可以持续观察资源变化趋势，比 top 更适合定位瞬时抖动：

# 每 1 秒输出一次，共输出 10 次
vmstat 1 10

# procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
#  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
#  4  0      0 2.1G   180M   8.5G    0    0     0     2   50  120  5  2 93  0  0

关键字段含义：

• r：正在运行和等待 CPU 的进程数，r 长期大于 CPU 核心数说明 CPU 不足
• b：处于不可中断睡眠状态的进程数，通常是等待 IO，b 长期大于 0 说明有 IO 阻塞
• swpd：使用的虚拟内存总量，swpd 持续增长说明物理内存不足
• si/so：swap 换入/换出速率，如果 so 持续不为 0，说明内存真的不够用了

排查方向一：CPU 问题

CPU 是最常见的性能瓶颈来源。当 us 占比高且 load 高时，说明用户代码在争抢 CPU 资源。

找出吃 CPU 最多的进程

# 按 CPU 占用排序，前 10 个进程
ps aux --sort=-%cpu | head -n 11

# 或者用 top 的批处理模式，更清晰
top -b -n 1 -o %CPU | head -n 20

输出示例（字段含义：USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND）：

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
postgres   1234  95.2  8.2  2.1G 1.8G ?        S    Jan15 4567:12 postgres
root     23456   2.1  0.5  1.2G 200M ?        S    Jan15  123:45 java

发现 postgres 进程 CPU 占用 95.2%，几乎吃满了 1 个 CPU 核心。

查看进程的详细 CPU 使用情况

# 查看指定进程的 CPU 使用详情
top -p 1234

# 查看进程的线程信息（Java、Go 等多线程服务的 CPU 问题需要看线程）
ps -T -p 1234
# THREAD 列显示线程 ID，CPU 列显示各线程的 CPU 占用

# 查看进程的完整命令行和当前工作目录
cat /proc/1234/cmdline | tr '\0'' '
cat /proc/1234/cwd

/proc/[pid]/stat 包含了进程的详细 CPU 时间信息，可以用 pidstat 工具来查看某个进程的 CPU 使用分解：

# 安装 sysstat 包（包含 pidstat）
yum install -y sysstat    # CentOS/RHEL
apt-get install -y sysstat  # Debian/Ubuntu

# 每 1 秒输出一次进程 1234 的 CPU 使用分解
pidstat -p 1234 1 5

# 输出示例：
# 15:30:01      UID       PID %usr %system %guest   %wait   %CPU CPU
# 15:30:02      54321     1234  94.5    1.2    0.0    0.3  95.7   0
# 15:30:03      54321     1234  93.8    1.5    0.0    0.5  95.3   0
# %usr：用户态运行时间
# %system：内核态运行时间
# %wait：等待资源的时间（这个值高说明进程大部分时间在等资源而不是计算）
# %CPU：总 CPU 占用百分比

确认 CPU 耗在哪个代码路径

如果 Java 进程 CPU 100%，下一步需要确认是哪个线程、哪个代码路径在消耗 CPU：

# 找到 Java 进程中最消耗 CPU 的线程 ID（需要 16 进制）
jstack 1234 | grep "nid=0x" | head -20

# 或者用 ps 命令直接看线程级 CPU 占用
ps -T -p 1234 -o pid,tid,psr,%cpu,time,comm | sort -k4 -rn | head -20
# psr 列是线程绑定的 CPU 核心号

# 找到 CPU 占用最高的线程 ID 后，转换为 16 进制
printf"%x\n" 23456
# 5ba0

# 在 jstack 输出中搜索该线程的堆栈
jstack 1234 | grep -A 30 "nid=0x5ba0"

jstack 输出的线程状态中，RUNNABLE 状态的线程是真正在执行代码的线程，BLOCKED 状态的线程在等待锁。如果 CPU 100% 但所有线程都是 BLOCKED，说明问题可能是全局锁竞争，而不是代码计算本身。

如果是短时进程吃 CPU：使用 execsnoop

有些 CPU 峰值是由大量短时进程造成的，比如 cron 调度的脚本、监控系统 agent 的定时任务。这些进程存在时间很短，用 top 很难捕捉到：

# execsnoop 监控新进程的创建（尤其是短时进程）
# 安装 bpftrace 或 bcc-tools
yum install -y bcc-tools
# 或使用 bpftrace
yum install -y bpftrace

# 监控最近 30 秒内新创建的所有进程
execsnoop -a 30

# 输出示例：
# PCOMM            PID    PPID   RET ARGS
# script.sh        5678   5677     0 /opt/scripts/script.sh
# python           5679   5678     0 /usr/bin/python app.py

execsnoop 是动态追踪工具，不需要被观测进程做任何配合。如果发现大量短时进程在同时运行，就能快速定位是谁在制造负载。

排查方向二：内存问题

内存不足时，Linux 会用 swap 扩展可用内存，但 swap 读写速度远慢于物理内存，一旦开始频繁 swap，系统会急剧变慢。内存问题排查的核心是：物理内存是否真的不足，swap 是否被触发了。

查看内存使用情况

# 人类可读的内存使用情况
free -h

# 输出示例：
#               total        used        free      shared  buff/cache   available
# Mem:           31Gi       28Gi       1.2Gi       200Mi       2.5Gi       2.8Gi
# Swap:         8.0Gi       500Mi       7.5Gi

# 重点关注 available 而不是 free
# Linux 会把空闲内存用于 buff/cache 以提升 IO 性能
# available = free + buff/cache 中可回收的部分
# 业务真正能使用的内存是 available，不是 free

# 精确查看内存分布（单位 KB）
cat /proc/meminfo

# MemTotal:       32880324 kB   总物理内存
# MemFree:         1254784 kB   未使用内存
# MemAvailable:    2897344 kB    可用内存（包含可回收的 cache）
# Buffers:          198732 kB    块设备缓存
# Cached:          2156784 kB    文件系统缓存
# SwapCached:         1234 kB    已在 swap 中但又在物理内存中的页
# SwapTotal:       8388604 kB    swap 总大小
# SwapFree:        7886040 kB    swap 剩余
# DirectMap4k:      102400 kB   映射 4K 页的内存
# DirectMap2M:     20480000 kB   映射 2M 页的内存

确认 swap 是否被使用

# 查看 swap 使用情况
swapon -s

# 或
cat /proc/swaps

# 输出示例：
# Filename                Type        Size    Used    Priority
# /dev/dm-1               partition   8388604 512000  -1
# Used = 512000 KB，约 500MB 的 swap 被使用

# 如果 Used 持续增长，说明物理内存不足，正在往 swap 写数据
# 这是内存不足的明确信号

# 查看哪些进程正在使用 swap
for file in /proc/*/status; do
    awk '/VmSwap/{s=$2}/Name/{n=$2} END{if(s+0>0) print n, s}'"$file"
done | sort -k2 -rn | head -10

# 输出示例（按 swap 使用量排序）：
# java  512000 kB
# postgres  124000 kB
# redis  34000 kB

VmSwap 不为 0 的进程就是正在占用 swap 的进程。如果一个进程占用大量 swap，说明它需要的内存超出了物理内存。注意：某些情况下进程占用 swap 是正常的（比如进程申请了大块内存后释放了一部分，Linux 不会立即归还物理内存）。

内存泄漏排查

如果内存持续增长，swap 使用量不断上升，但找不到吃内存的大进程，可能是内存泄漏：

# 持续观察内存变化趋势（每秒采样，共 60 秒）
# 保存当前内存快照
cat /proc/meminfo > /tmp/mem_before.txt
sleep 60
cat /proc/meminfo > /tmp/mem_after.txt
diff /tmp/mem_before.txt /tmp/mem_after.txt

# 如果 MemAvailable 持续下降，或者 Cached 持续不回收，说明可能有内存泄漏

# 查看每个进程的内存占用变化（使用 ps_mem.py 脚本更清晰）
# 下载地址：https://github.com/pixelb/ps_mem
python3 ps_mem.py

# 输出示例（按内存占用排序）：
#  Private  +   Public = RAM used  Program
#  256.0 MiB +  54.0 MiB = 310.0 MiB  java
#  123.0 MiB +  12.0 MiB = 135.0 MiB  postgres
#   45.0 MiB +   5.0 MiB =  50.0 MiB  redis-server

排查方向三：磁盘 IO 问题

当 wa（wait IO）高或 load 很高但 CPU idle 也高时，说明瓶颈不在 CPU，而在磁盘 IO。有些情况下，CPU 的 sys 部分高（sy）也是 IO 问题的间接表现——系统花大量时间在 IO 等待和内核调度上。

快速判断磁盘 IO 是否是瓶颈

# iostat 是查看磁盘 IO 的标准工具
yum install -y sysstat
apt-get install -y sysstat

# 每 1 秒输出一次，共 5 次
iostat -xz 1 5

# 输出示例：
# Device  rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s  avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
# sda       0.00     1.23    2.10    8.45   120.00   540.00    62.78     0.45    4.23   1.20   5.10   2.10   8.50
# dm-0      0.00     0.00    2.00    9.00   118.00   542.00   65.00     0.50    4.50   1.10   5.20   2.20   9.00

关键字段解读：

• r/s 和 w/s：每秒读写次数（IOPS）
• rkB/s 和 wkB/s：每秒读写吞吐量（KB/s）
• avgqu-sz：平均队列深度，磁盘请求的等待队列长度，avgqu-sz 持续大于 1 说明磁盘开始拥塞
• await：平均 IO 等待时间（毫秒），包含排队时间和实际 IO 时间，await > 100ms 说明 IO 已经很慢
• util：磁盘利用率，接近 100% 说明磁盘已经是瓶颈，接近饱和

判断 IO 瓶颈的规则：

• util > 80% + await > 50ms → 磁盘 IO 饱和
• avgqu-sz > 2 → 大量请求在等待
• 如果是 SSD，await > 10ms 才算异常；如果是机械硬盘，await > 20ms 才算异常

找出是哪个进程在制造 IO

# iotop 是 top 命令的 IO 版本，按 IO 占用排序
iotop

# 只显示正在做 IO 的进程（过滤掉空闲进程）
iotop -a

# 非交互模式，采样 10 次
iotop -b -n 10

# 只看某个进程的 IO
iotop -p 1234

# 输出示例：
# Total DISK READ:       0.00 B/s | Total DISK WRITE:     523.45 MB/s
# Actual DISK READ:       0.00 B/s | Actual DISK WRITE:     510.23 MB/s
#   TID  PRIO  USER     DISK READ  DISK WRITE  >PID
#   4567 BE/4  postgres    0.00 B/s  512.34 MB/s  1234

iotop 按 IO 总量排序，可以快速发现是哪个进程在疯狂读写磁盘。上例中 postgres 进程每秒写盘 512MB，这个量级明显异常。

使用 pidstat 查看进程级 IO

# 查看特定进程的 IO 统计
pidstat -d -p 1234 1 5

# 输出示例：
# 15:30:01      UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s iodelay  command
# 15:30:02      54321     1234      0.00  524288.00      0.00       0  postgres
# kB_rd/s：每秒读取 KB 数
# kB_wr/s：每秒写入 KB 数
# kB_ccwr/s：每秒取消写入的 KB 数（可能是被其他操作取消）
# iodelay：IO 等待的时钟周期数（包含调度延迟和 IO 等待）

找出具体在读写哪些文件

# 使用 lsof 找出某个进程打开的文件
lsof -p 1234

# 查找当前打开文件数最多的进程
lsof +c 0 | awk '{print $1}' | sort | uniq -c | sort -rn | head -10

# 如果某个文件被大量进程同时打开（文件锁问题）
lsof /var/lib/mysql/myfile.ibd

# 使用 inotify 监控文件变化（适合排查是谁在频繁写某个日志）
inotifywait -m -r /var/log/

排查方向四：进程状态问题

有些服务器变慢不是因为资源耗尽，而是因为进程处于异常状态：僵死（Zombie）、不可中断睡眠（D）、暂停（STOP）等。

查看进程状态

# 查看所有进程状态，R=运行 S=可中断睡眠 D=不可中断睡眠 Z=僵死 T=暂停
ps aux | awk '{print $8}' | sort | uniq -c | sort -rn

# 输出示例：
#   234 S
#     1 R
#     5 D
#     0 Z
#     2 T

# 如果 D 状态进程数量大于 0，需要特别关注
# D 状态是"不可中断睡眠"，通常是在等待 IO（磁盘、网络）或等待内核响应
# D 状态进程不能被 kill -9 杀死，需要等 IO 恢复或解决内核问题

# 找出 D 状态进程的详细信息
ps aux | awk '$8 ~ /D/ {print}'

# 查看 D 状态进程的等待事件
cat /proc/$(ps aux | awk '$8 ~ /D/ {print $2}' | head -1)/wchan

# 输出可能是：
# nfs_wait_on_request        # 等待 NFS 请求
# ext4_vfa                   # 等待 ext4 文件系统操作
# scsi_dispatch_cmd          # 等待 SCSI 指令

D 状态进程是排查 IO 问题的关键线索。如果服务器 load 很高但 CPU idle 也很高，基本可以确定是 D 状态进程在消耗 load——它们在等待 IO，不消耗 CPU，所以 load 反映了等待资源的进程数，但 CPU 空转。

找出僵死进程

# 查找僵死进程（Z 状态）
ps aux | awk '$8 == "Z" {print}'

# 输出示例：
# USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   COMMAND
# root       789   0.0  0.0      0     0 ?        Z    Jan15  [defunct]
# 僵死进程的 PPID 是 1（init）或某个已经退出的父进程

# 查看僵死进程的父进程
ps -ef | grep <父进程PID>

# 僵死进程的清理方式：必须先杀掉父进程
kill -9 <父进程PID>

僵死进程是已经退出但没有被父进程回收的子进程。父进程可能是在等待某个条件，或者本身已经僵死。清理僵死进程的唯一方式是通过其父进程，如果父进程也是僵死状态，则需要重启服务器或找到并解决其父进程的等待条件。

查看进程的端口和连接

对于网络服务进程，连接数异常也会导致性能问题：

# 查看进程监听的端口
netstat -tlnp | grep <进程名>
# 或
ss -tlnp | grep <进程名>

# 查看进程建立的所有连接
netstat -anp | grep <PID>
# 或
ss -anp | grep <PID>

# 查看连接状态分布
ss -s
# 输出示例：
# Total: 128 (kernel 130)
# TCP:   1024 (estab 1000, closed 10, orphan 5, timewait 10)
# 1000 个已建立连接，如果应用是短连接，可能存在连接频繁建立和关闭的问题

# 查看 TIME_WAIT 连接数量（过多可能说明连接没有正确关闭）
netstat -an | awk '/^tcp/ {print $6}' | sort | uniq -c

排查方向五：网络问题

网络问题导致的服务器变慢通常有两种：一是网络延迟增大导致服务响应慢；二是网络带宽耗尽导致数据传输受阻。

查看网络流量

# 查看各网卡的网络流量（字节和包数）
cat /proc/net/dev

# 更友好的输出格式
watch -n 1 'cat /proc/net/dev'

# 使用 ifstat 查看流量趋势
ifstat -a 1 5

# 输出示例：
# Interface        RXKbytes   TXKbytes  %ifutil
# eth0            125678.5     89234.2      12.5
# eth1               23.4         12.1       0.0
# lo              23456.1     23456.1       0.0

如果某个网卡的 RX（接收）或 TX（发送）流量接近带宽上限（比如千兆网卡约 125MB/s），说明带宽可能成为瓶颈。

查看网络连接状态

# 查看各状态的连接数
netstat -an | awk '/^tcp/ {print $6}' | sort | uniq -c
# 或
ss -s

# 统计连接数最多的前 10 个 IP
netstat -an | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -10

# 如果发现某个陌生 IP 有大量连接，可能是被攻击或扫描
# 如果发现大量来自内网其他机器的连接，可能是批量操作或异常调用

# 查看是否有端口被等待accept的连接队列溢出
netstat -s | grep -i "overflow" -A 2 -B 2
# listen queue 溢出说明并发连接数超过了服务的 accept 能力

网络延迟诊断

# 测试到目标服务器的延迟（ICMP）
ping -c 10 目标IP

# 输出示例：
# 64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=0.312 ms
# 64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=0.289 ms
# 64 bytes from 10.0.0.5: icmp_seq=3 ttl=64 time=0.301 ms
# --- 10.0.0.5 ping statistics ---
# 10 packets transmitted, 10 received, 0% packet loss, time 9012ms
# rtt min/avg/max/mdev = 0.289/0.301/0.312/0.008 ms
# 延迟稳定在 0.3ms，说明网络正常

# 如果延迟波动很大（mdev 很大）或大量丢包，说明网络不稳定

# 测试 TCP 端口连通性（适合排查端口不通是网络问题还是服务问题）
nc -zv 目标IP 端口
# 或
telnet 目标IP 端口

# 跟踪路由（排查网络路径中的延迟来源）
traceroute 目标IP
# 或（现代替代工具）
tracepath 目标IP

综合排查案例：定位 Java 服务 CPU 100%

前面讲了各个资源维度的排查方法，现在用一个完整案例把它们串起来。

故障现象：业务人员报告网站响应缓慢，工程师登录服务器后看到 load average 很高。

第一步：确认症状

uptime
# 15:30:01 up 45 days,  3:22,  2 users,  load average: 12.34, 8.45, 6.12

top -b -n 1
# 发现 java 进程 CPU 占用 890%（假设是 8 核机器，占用超过 100%）

load 是 12.34，但服务器只有 8 核，说明至少有 4 个进程在等 CPU。

第二步：判断 CPU 瓶颈位置

vmstat 1 5
# procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
#  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
#  8  0      0 2.1G   180M   8.5G    0    0     0     2   50  120  85  5  0  0  0
# CPU: us=85%, sy=5%, id=0%, wa=0%
# us 高、id 为 0 说明 CPU 确实是瓶颈，不是 IO 问题
# r=8 确认有 8 个进程在等待 CPU

第三步：确认是哪个进程

ps aux --sort=-%cpu | head -n 11
# USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
# java      12345  890  45.2  12G    11G ?        S    Jan15  4567:12 java

确认是 java 进程吃掉了大部分 CPU。

第四步：查看 Java 进程内部线程

# 看看哪个线程在消耗 CPU
ps -T -p 12345 -o pid,tid,psr,%cpu,time,comm | sort -k4 -rn | head -20

# 输出示例：
#     28  28228     -  125.0 00:32:15 java
#     35  28335     -  118.0 00:28:12 java
#     12  28112     -  110.0 00:15:34 java
#     7  28207     -   98.0 00:12:01 java
#     4  28204     -   85.0 00:10:23 java

# 有多个线程 CPU 占用都接近 100%，说明是并行计算或 GC 问题

# 查看 Java 进程的 GC 情况（如果进程还在运行）
jstat -gcutil 12345 1000 5
# S0 S1   E    O    M     YGC   YGCT    FGC FGCT   CGC   CGCT     GCT
# 0.00 0.00 100.00 98.00 99.00 12345 678.90  12 234.56   0    0.00  913.46
# E=100%（Eden 区满了），O=98%（Old 区快满了），YGC 次数极高
# 说明 Java 进程在疯狂做 Young GC，内存不够用

第五步：分析根因

Eden 区和 Old 区都接近 100%，且 Young GC 频率极高（YGC 12345 次），说明 Java 进程在频繁进行垃圾回收，每次回收又回收不了多少空间。这是典型的内存分配速度超过垃圾回收速度的问题，即：内存不足导致频繁 GC，GC 导致 CPU 飙高。

继续确认：

# 查看 JVM 堆内存使用情况
jstat -gccapacity 12345

# 查看 JVM 启动参数（确认最大堆内存）
cat /proc/12345/cmdline | tr '\0'' '
# 或
jcmd 12345 VM.flags

# 查看当前堆使用量
jmap -heap 12345

假设发现最大堆内存只有 2GB，而 Java 进程实际占用的物理内存是 11GB（JVM 堆 + Native 内存 + 直接内存）。如果 Java 应用使用了大量直接内存（DirectByteBuffer）或 JNI 堆外内存，就会出现物理内存远大于堆内存的情况。

第六步：修复与验证

如果判断是内存不足导致的频繁 GC：

# 1. 如果可以重启服务，扩大堆内存（建议物理内存的 50%~70%）
# -Xms4g -Xmx4g -XX:+UseG1GC -XX:MaxGCPauseMillis=200

# 2. 如果不能立即重启，尝试触发一次 Full GC（慎用）
jcmd 12345 GC.run

# 3. 如果是 DirectByteBuffer 泄漏，需要定位代码（使用 jcmd 查看堆外内存）
jcmd 12345 VM.native_memory summary

# 4. 验证：监控 GC 日志
# 开启 GC 日志：-Xlog:gc*:file=/var/log/java_gc.log:time,uptime:filecount=5,filesize=10M
# 用 gceasy.io 分析 GC 日志，得出暂停时间和频率的量化报告

如果判断是代码问题（比如死循环、计算密集）：

# 抓取线程堆栈
jstack 12345 > /tmp/jstack_$(date +%Y%m%d%H%M%S).log

# 查看"RUNNABLE"状态的线程（在执行代码的线程）
grep -A 5 "RUNNABLE" /tmp/jstack_xxx.log | head -100

# 如果是死循环，通常会看到某个方法在重复调用
# 如果是多线程争抢，会看到多个线程在同一个 synchronized 块里

常用排查命令速查表

将前面用到的命令整理成速查表，便于在紧急情况下快速使用：

CPU 排查

top -b -n 1 -o %CPU          # 按 CPU 排序查看进程
vmstat 1 5                   # 查看 CPU 和进程状态
pidstat -p <PID> 1 5         # 查看特定进程的 CPU 占用
jstack <PID>                 # 抓取 Java 线程堆栈
ps -T -p <PID>               # 查看进程的线程级 CPU 占用

内存排查

free -h                        # 查看内存使用概况
cat /proc/meminfo              # 查看详细内存信息
vmstat 1 5                     # 关注 si/so（swap 换入换出）
for f in /proc/*/status; do awk '/VmSwap/{s=$2}/Name/{n=$2}END{if(s~/[0-9]+/)print n,s}'$f; done | sort -k2 -rn | head  # 查看进程的 swap 占用

IO 排查

iostat -xz 1 5                # 查看磁盘 IO 详情
iotop -b -n 10                # 按 IO 占用排序查看进程
pidstat -d -p <PID> 1 5      # 查看特定进程的 IO 占用

进程状态排查

ps aux | awk '$8 ~ /D/ {print}'# 查找不可中断睡眠进程
ps aux | awk '$8 == "Z" {print}'# 查找僵死进程
lsof -p <PID>                     # 查看进程打开的文件

网络排查

ss -tuln                       # 查看监听端口
ss -anp | grep <PID>          # 查看进程的网络连接
netstat -an | awk '/^tcp/ {print $6}' | sort | uniq -c  # 统计连接状态

系统层面的性能调优

排查清楚根因后，根据问题类型进行调优。以下是常见场景的调优方向。

CPU 调优

如果问题是单个进程吃满多核 CPU（Java、Python 等）：

# 确认进程是否配置了合理的线程数
# Java: -XX:ParallelGCThreads=N  -XX:ConcGCThreads=N
# Nginx: worker_processes auto; worker_connections N;

# 如果是计算密集型任务，考虑绑定 CPU 核心（减少线程调度开销）
taskset -c 0-7 <PID>   # 将进程绑定到 0~7 核

# 如果是多实例运行，可以让不同实例绑定不同 CPU 核心，避免竞争

内存调优

# 调整 swappiness（swap 积极程度）
# 默认 60，值越高越积极使用 swap
# 对于内存充足的服务，建议调低到 10~30
echo 30 > /proc/sys/vm/swappiness
# 永久生效：/etc/sysctl.conf 中添加 vm.swappiness=30

# 调整脏页回写策略（减少频繁写盘）
# 触发回写之前，脏页占可用内存的最大比例
echo 80 > /proc/sys/vm/dirty_ratio
# 触发异步回写之前，脏页占可用内存的比例
echo 20 > /proc/sys/vm/dirty_background_ratio

# 调整文件描述符限制（高并发服务的常见瓶颈）
# 查看当前限制
ulimit -n
# 临时修改
ulimit -n 655350
# 永久修改：/etc/security/limits.conf
# * soft nofile 655350
# * hard nofile 655350

IO 调优

# 调度器选择：
# deadline：适合数据库等顺序读写为主的场景
# cfq：适合桌面系统和通用 Linux 发行版
# noop：适合 SSD 或做虚拟化 IO 加速
# 查看当前调度器
cat /sys/block/sda/queue/scheduler
# noop [deadline] cfq   # 当前是 deadline

# 临时修改（将 sda 换成你的磁盘设备名）
echo deadline > /sys/block/sda/queue/scheduler

# 永久修改：/etc/default/grub 中 GRUB_CMDLINE_LINUX 添加 elevator=deadline
# 然后执行 grub2-mkconfig -o /boot/grub2/grub.cfg

# 开启 IO 优先级（让重要进程的 IO 优先处理）
ionice -c 2 -n 0 -p <PID>   # 实时 IO 级别，最高优先级
# ionice -c 3 -p <PID>       # 空闲 IO 级别，闲时再做

高并发场景的系统参数调优

如果服务器承担高并发请求，以下参数需要关注：

# /etc/sysctl.conf 中添加

# 允许更大的连接队列
net.core.somaxconn = 655350
net.core.netdev_max_backlog = 655350

# TCP 连接优化
net.ipv4.tcp_max_syn_backlog = 655350
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_keepalive_intvl = 15

# 本地端口范围（高并发短连接需要）
net.ipv4.ip_local_port_range = 1024 65535

# TIME_WAIT 复用
net.ipv4.tcp_tw_reuse = 1

# 生效配置
sysctl -p

监控体系建设：让问题提前暴露

排查是救火，监控是防火。一套完善的监控体系应该在服务器变慢之前就能发现问题趋势，而不是等问题发生了再去排查。

基础监控指标

生产服务器至少应该监控以下指标：

# CPU: 使用率 > 80% 持续 5 分钟告警
# 内存: available < 20% 告警，swap 使用量 > 0 持续告警
# 磁盘: 使用率 > 85% 告警，inode 使用率 > 85% 告警
# 磁盘 IO: await > 50ms 持续告警
# load: load > CPU 核心数 * 0.7 持续 5 分钟告警
# 网络: 带宽使用率 > 70% 告警，连接数异常增长告警

用 Prometheus + node_exporter 采集系统指标

# 安装 node_exporter（Prometheus 的系统指标采集器）
wget https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz
tar -xzf node_exporter-1.7.0.linux-amd64.tar.gz
cd node_exporter-1.7.0.linux-amd64
./node_exporter &

# 默认端口 9100，暴露 /metrics 端点
# Prometheus 配置中添加：
#   - job_name: 'node'
#     static_configs:
#       - targets: ['localhost:9100']

关键 node_exporter 指标（PromQL 查询表达式）：

# CPU 使用率（1 - idle）
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# 内存使用率
(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100

# 磁盘使用率
100 - (node_filesystem_avail_bytes / node_filesystem_size_bytes * 100)

# 磁盘 IO await
rate(node_disk_io_time_seconds_total[5m]) * 100  # 利用率百分比
rate(node_disk_read_time_seconds_total[5m]) / rate(node_disk_reads_completed_total[5m]) * 1000  # 读延迟 ms

用 Grafana 展示系统状态

Grafana 配合 node_exporter 可以快速搭建可视化监控面板。关键面板设计：

• CPU 面板：显示 user/system/idle/irq/softirq 的时间序列图
• Load Average 面板：叠加显示 1/5/15 分钟 load 和 CPU 核心数参考线
• Memory 面板：显示 used/available/cached/swap 的堆叠图
• Disk IO 面板：显示 IOPS 和吞吐量，以及 await 和 util 延迟指标
• Network 面板：显示进/出流量和连接状态分布

告警规则示例（Grafana 的 Alerting 规则）：

# 当 CPU 使用率超过 90% 持续 5 分钟
-alert:HighCPU
expr:100-(avgby(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m]))*100)>90
for:5m
labels:
severity:warning
annotations:
summary:"CPU 使用率过高"
description:"{{ $labels.instance }} CPU 使用率 {{ $value }}%"

# 当可用内存低于 20%
-alert:LowMemory
expr:(node_memory_MemAvailable_bytes/node_memory_MemTotal_bytes)<0.2
for:5m
labels:
severity:critical

排查后的复盘与文档化

每次故障排查完成后，应该做一次复盘，记录排查过程中的判断思路、使用的命令、发现的问题和最终的修复方案。这个文档的价值在于：

1. 团队知识积累：下次遇到类似问题时，其他人不需要从零开始
2. 排查路径优化：review 排查路径，判断是否有更短的路径
3. 基线数据补充：通过复盘确认当前的基线数据是否需要更新
4. 自动化改进：发现可自动化的排查步骤，加入监控或自动化脚本

复盘文档建议包含以下内容：

• 故障现象：具体表现（不是"服务器慢了"这种模糊描述，而是"CPU 100%，load 12，网站响应时间从 50ms 上升到 5000ms"）
• 排查过程：每一步用了什么命令，看到了什么指标，排除了什么假设
• 根因定位：最终确定的根因，以及判断依据（证据链）
• 修复方案：做了什么操作，以及回滚方案
• 验证结果：修复后的指标对比
• 经验总结：下次遇到类似问题，最快的排查路径是什么

总结

服务器变慢的排查没有固定公式，但有可以遵循的思路：

先整体后局部：先用 top、vmstat、iostat 快速判断是哪个资源维度的问题（CPU/内存/IO/网络），避免在错误的方向上浪费精力。

先排除后确认：用排除法快速排除不可能的选项。比如看到 load 高但 CPU idle 也高，就基本可以排除 CPU 计算瓶颈，把注意力放到 IO 等待上。

用证据下结论：每个判断都要有命令输出的证据支撑，不能凭感觉。wait IO 高 + D 状态进程 + iostat util 100% 才能下"磁盘是瓶颈"的结论，单独一个指标不够。

监控比排查更重要：完善的监控体系可以让问题在变成故障之前就被发现。CPU 飙到 100% 才去排查是被动挨打，每小时采集一次基线、配置合理的告警阈值才是主动防御。

文档是最好的复利：每一次排查完后的复盘文档，都会在未来某个时刻帮团队节省几小时的排查时间。