Linux性能排查实战：从CPU到磁盘IO的系统定位思路

Linux 服务器卡顿、接口超时、进程被 kill、负载飙高，这些问题做运维和开发的兄弟大概率都遇到过。尤其是线上环境出问题时，那种紧张感跟救火差不多。但救火也有救火的章法，核心就是先搞清楚机器到底在“忙”什么，是 CPU 不够、内存不足、磁盘 IO 卡住，还是网络链路易堵。这篇内容我不打算堆砌命令大全文，而是把我平时排查性能问题时的真实思路和用到的常用指令整理出来，按照 CPU、内存、磁盘 IO、网络四个维度分开讲，每一步都对应实际场景，加上怎么看输出、怎么定位根因，希望能给正在被 Linux 性能问题折磨的同行一些可以直接参考的东西。

1. 性能排查入门：先判断“病在哪一科”

1.1 排查前的思路准备

很多人拿到一台卡住的服务器，第一反应就是敲 top 看一眼，然后盯着 %CPU 发呆，接着就不知道该干啥了。这种“头痛医头”的排查方式效率很低。我的习惯是，先把系统资源当成医院的分诊台，一台服务器如果出问题，无非是四大类资源排队：CPU、内存、磁盘 IO、网络。排查的第一步不是急着定位某个进程，而是先判断是哪一个资源成了瓶颈。

比如用户反馈“系统很慢”，打开终端一执行命令都觉得卡，这时候你要先判断是整机层面的资源耗尽，还是某个进程把机器拖垮了。如果是整机层面，top 里的 load average 会告诉你系统整体负载如何；如果是单进程问题，你会看到某个进程的 CPU 或内存占用异常。再比如“数据库连接超时”，你要先确认是不是网络问题，再确认是不是数据库所在机器的磁盘 IO 满了。没有这一步分类，很容易被表象带偏，抓着一个可疑进程报警，结果底层的根因是磁盘 IO 占满导致进程全部阻塞。

排查过程我建议按这个顺序走：先看负载和整体资源（top/uptime），再看明细指标（CPU/内存/IO/网络分别对应的命令），最后用日志和实时追踪工具把根因坐实。这样才能做到有据可依，而不是靠猜。

1.2 五类核心资源与对应排查工具一览

我把日常排查用到的高频指令按资源维度整理了一张表，方便出问题时快速找到该用哪把“扳手”。这张表是我实际工作中反复用到的，比背几十条命令有效得多。

另外，dmesg 和 strace 是两类“杀手锏”指令。dmesg 负责看内核日志，比如 OOM 杀进程、磁盘 IO 错误，这些在现网事故里经常能抓到关键证据；strace 则用来追踪进程的系统调用，当常规指标都正常但程序行为诡异时，它能告诉我们程序到底卡在哪个系统调用上。后面我会针对每条命令展开讲怎么看输出、怎么定位问题。

2. CPU 类问题排查指令实战

2.1 第一梯队：top 与 uptime，快速锁定 CPU 压力

但凡排查性能，我的习惯都是先敲 top，再敲 uptime。uptime 输出一行就够，但信息密度很高：

bash复制$ uptime
 14:32:10 up 3 days,  2:10,  1 user,  load average: 4.02, 3.85, 3.20

这里最关键的是 load average 后面的三个数，分别对应 1 分钟、5 分钟、15 分钟的平均负载。怎么判断负载高不高？最简单粗暴的说法是：这个数值如果长期大于 CPU 核心数，说明 CPU 已经过载或者有大量进程在排队。比如 4 核机器，load 到 8 到 10，基本是 CPU 被打满了。如果是云服务器，可以先 nproc 看看核数。

但这里有个坑：load average 高不完全等于 CPU 忙。它统计的是处于可运行状态和不可中断睡眠状态的进程数。不可中断睡眠（D 状态）大多是因为进程在等磁盘 IO，比如 NFS 挂载盘卡了，或者本地磁盘响应缓慢。所以你会发现 load 飙到 20，但 CPU 使用率才 5%，这种畸形组合一般就是 IO 阻塞导致的。也就是说，uptime 负责“报警”，但具体“哪里着火”，还要靠 top 里的细分数据来判断。

再看 top，第一屏的 %Cpu(s) 这行有几个关键字段要会读：

• us（user）：用户态 CPU 占比，常规计算逻辑主要在这里。
• sy（system）：内核态 CPU 占比，如果这个值常年很高，可能是有大量系统调用，或者内核资源竞争。
• wa（iowait）：CPU 等待 IO 完成的时间占比，偏高大概率是磁盘或网络文件系统有问题。
• st（steal）：虚拟机中 CPU 被宿主机抢占的时间占比，云服务器如果 st 持续很高，可能是宿主机资源争用。
• id（idle）：空闲占比。

单独看 us 高就是 CPU 在密集计算；sy 高可以结合 strace 确认是不是系统调用或锁竞争；wa 高则要去查磁盘。我见过很多新人一看 wa 高就以为 CPU 忙，实际上 CPU 在“干等”磁盘，真正要做的是排查磁盘 IO，而不是加 CPU 核数。

top 默认按 CPU 使用率排序，找到最耗 CPU 的进程后，记下 PID，后续用 pidstat 或 strace 继续追。如果这一秒看到的高 CPU 进程下一秒就变了，通常是频繁创建短生命周期进程导致，这时候可以留意是不是脚本在疯狂 fork。

2.2 深挖 CPU：mpstat、pidstat 与 vmstat 的配合使用

top 适合快速看一眼全貌，但要精细定位是哪个 CPU 核忙、哪个进程在消耗，以及消耗是持续的还是脉冲式的，我一般会再上 mpstat 和 pidstat。

mpstat -P ALL 1 可以实时输出每个 CPU 核的使用率，1 秒一条：

bash复制$ mpstat -P ALL 1
Linux 5.4.0-26-generic (hostname)     06/21/2024     _x86_64_    (8 CPU)

10:32:01 AM  CPU    %usr   %nice    %sys   %iowait   %steal   %idle
10:32:02 AM  all    12.46    0.00    2.31      0.00     0.00   85.23
10:32:02 AM    0    22.00    0.00    3.00      0.00     0.00   75.00
10:32:01 AM    1    80.25    0.00    5.12      0.00     0.00   14.63

如果只有某个核的 %usr 飙到 80% 以上，其他核空闲，可能是单线程应用导致“单核瓶颈”。Java 应用里不少 GC 线程、Nginx 的 worker 单进程模型都可能出现这种分布。这时候加机器核数往往没用，必须针对代码做并发优化，或者调整进程的 CPU 亲和性，避免线程在同一核上挤来挤去。

pidstat 则能把 CPU 消耗精确到线程和进程。常用命令是 pidstat -u 1，每秒输出一次各进程的 CPU 使用情况。如果进程里面有大量线程，加 -t 参数可以看线程维度。我在排查 Java 应用时经常这么用：先 pidstat -u 1 -t -p <PID>，找到异常线程，再结合 jstack 把线程栈 dump 出来，定位到具体的业务代码行，效率比盲目看日志高得多。

vmstat 是老牌工具了，我通常用它做快速健康检查。执行 vmstat 1 5 会每秒采样一次，共 5 次。重点关注 r（运行队列）、b（阻塞进程数）、wa、cs（上下文切换）。如果 r 长期超过 CPU 核数，说明 CPU 已经排起长队；cs 每秒几十万甚至上百万，说明进程或者线程切换过于频繁，常见原因包括线程数过多、锁竞争太激烈。

2.3 CPU 排查实战案例与常见误判

分享一个实际案例。有次朋友公司的应用服务器频繁报警，CPU 使用率 400%（8 核机器）。我先 top 看到 java 进程占了 380%，很明确是应用自身的问题。用 pidstat -u 1 -t -p <PID> 很快抓到一个线程的 CPU 超过 100%，随后 jstack 打线程栈，发现业务代码里出现了一个无限循环的 while 操作，频繁做字符串拼接。问题定位后让开发修复，CPU 立刻回落。

这就是 CPU 排查的标准链路：top 锁定进程，pidstat 锁定线程，jstack/strace 锁定代码逻辑。常见的误判有两个：一是把 iowait 当成 CPU 忙去加核，其实加核根本解决不了；二是只看了 top 第一屏就杀掉最耗 CPU 的进程，但如果是系统层面出了异常日志疯狂输出，你杀了一个进程日志还在继续打，根因没解决，问题很快会卷土重来。

注意：top 里的进程 CPU 使用率是相对单个 CPU 核的百分比，200% 表示占了两个核。看到 800% 不要以为机器有 800 个核，先 nproc 确认一下再下结论。

3. 内存问题排查：free、vmstat 与 OOM 处理

3.1 free 的输出怎么看

内存问题说起来简单，但实际排查时有很多误区。很多人只看 free -h 里的 used 那一列，看到一个很大的数字就以为内存不足，其实漏掉了 Linux 内存管理里最重要的一块：缓存（cache）。正确的打开方式是执行 free -h 看 available 列：

bash复制$ free -h
              total        used        free      shared  buff/cache   available
Mem:           31Gi       3.2Gi        25Gi       180Mi       2.6Gi        27Gi
Swap:          2.0Gi          0B       2.0Gi

used 是已经被进程占用的内存；free 是完全没有被使用的内存；buff/cache 是内核用来做文件缓存和缓冲的内存。关键是 available，它才是估算“还能给新程序分配多少内存”的靠谱指标，因为它考虑了当内存紧张时，系统可以回收多少 cache。所以看到 free 数字很小不用慌，只要 available 还够，系统就能正常运转。

如果 available 很低，同时 swap 的使用量在增长，说明内存已经到了比较危险的境地。Linux 会优先使用物理内存，只有物理内存紧张或者配置了 vm.swappiness 较高时才会把冷页换到 swap。一旦 swap 频繁读写，性能会断崖式下跌，因为磁盘比内存慢了几个数量级。排查内存问题，free + vmstat 基本就能摸清情况，如果还不够细，可以用 smem 来统计 PSS（比例集大小），尤其适合排查多个进程共享内存的场景。

3.2 内存缓存的本质——为什么 “available” 才是真实可用

刚上手 Linux 的人常常有一个疑问：“我的程序明明只用了 2GB，为什么 free 显示物理内存已经被吃光了？”原因是 Linux 会“刻薄”地利用空闲内存来做文件缓存。比如你解压一个大文件、频繁读写数据库文件，这些 IO 过的数据都会被放进 cache，下次再访问时直接从内存读，速度快得多。这其实是 Linux 的优点，不是缺点。

所以排查内存问题，先别急着杀缓存。真正要盯的是 available 与换页行为。vmstat 1 里的 si（swap in）和 so（swap out）两个字段如果持续大于 0，说明系统正在大量换页，内存确实吃紧了。在这种情况下，再配合 top 按内存排序（按 M 键，让进程按 %MEM 排序），找到吃内存的大户。如果发现是某个 Java 或 Python 服务的内存持续增长且不回落，要怀疑是内存泄漏。这时候可以用 pidstat -r 1 -p <PID> 观察进程的 RSS 变化：如果 RSS 只增不减，且 GC 或者内存回收机制也没有把内存还回来，大概率就是泄漏了。

注意：不要在内存充足时手动 echo 3 > /proc/sys/vm/drop_caches 去清缓存。这会让后续的磁盘访问性能暂时下降，并不能解决真正的内存不足问题。清缓存只是生产环境上万不得已才使用的临时手段。

3.3 OOM 排查与常见误区

当物理内存和 swap 都不够时，内核会启动 OOM Killer，挑一个“得分最高”的进程把它杀掉。很多时候数据库或关键业务进程被杀就是这个原因。dmesg 会留下铁证：

bash复制$ dmesg -T | grep -i -E "killed process|out of memory"
[Thu Jun 21 10:50:12 2024] Out of memory: Killed process 12345 (mysqld) total-vm:12582912kB, anon-rss:2097152kB, file-rss:0kB, shmem-rss:0kB

看到这类日志，再结合 free 和 vmstat 确认内存确实耗尽，就可以去排查为什么内存会被耗尽。常见原因包括：并发连接过多导致每个连接都吃内存、JVM 堆设置过大导致留给操作系统的内存不足、或者代码本身存在泄漏逐渐吞噬了内存。

这里有一个运维上常见的坑：很多人遇到 OOM 就急着调大内存或者加机器，但不好好看为什么内存会涨上去。我曾经遇到过一台机器 OOM 反复发生，后来一查是 Nginx 的错误日志被连续不断的扫描攻击刷爆，日志文件越滚越大，直接吃满了磁盘和内存。所以排查 OOM 的正确姿势是：先看 dmesg 确认谁被杀了，再结合内存监控曲线看是什么时候开始猛涨的，最后翻对应时间窗口的日志和应用指标，找到根因再动手改配置。

4. 磁盘 IO 排查：iostat、iotop 与文件系统定位

4.1 iostat：定位性能瓶颈是磁盘还是应用

磁盘 IO 问题最典型的表象是：系统 load 很高，但是 CPU 的 us/sy 不高，wa 很高。这时候如果只盯着 CPU 排查，方向就错了。我的习惯是一上来就用 iostat -x 1 看详细指标：

bash复制$ iostat -x 1
Linux 5.4.0-26-generic (hostname)     06/21/2024     _x86_64_    (8 CPU)

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s  wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  %util
vda              0.00 1234.00    0.00 40960.00     0.00    60.00   0.00   4.64    0.00    5.60    6.91     0.00    33.20  78.40

关键看几个字段：%util 表示设备繁忙程度，接近 100% 说明磁盘已经接近饱和；w_await 是写请求平均等待时间，如果非常大，说明 IO 在排队，磁盘响应不过来了；aqu-sz 是平均队列长度，队列越长说明积压越严重。还有 rkB/s 和 wkB/s 可以看吞吐量，用来判断是带宽打满还是 IOPS 打满。

很多时候 %util 到 100% 不代表磁盘“坏了”，也可能是应用层写入放大太严重。比如数据库频繁刷脏页、日志系统把单条日志切得很碎、或者文件系统本身在做后台清理，都会导致 IO 请求数量极大。这时候 iostat 告诉你磁盘很忙，但没告诉你“谁在让它忙”，需要再往前一步定位进程。

4.2 iotop 与 pidstat -d：找到具体的元凶进程

iotop 类似 top 的磁盘版，能实时显示每个进程的磁盘读写速度。执行 iotop -o 只看有 IO 行为的进程，可以快速定位哪些进程在大量读写磁盘。我比较喜欢先 iotop -o，看到可疑进程后，再用 pidstat -d 1 做更精确的统计确认它每秒钟实际写了多少：

bash复制$ pidstat -d 1
Linux 5.4.0-26-generic (hostname)     06/21/2024     _x86_64_    (8 CPU)

10:40:01 AM   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s iodelay  Command
10:40:02 AM     0     35781      0.00  40960.00      0.00      12  java

如果发现是某个 Java 应用在疯狂写盘，可以先看它的日志目录是否在滚动输出，再看有没有临时文件在膨胀，最后结合应用本身的慢日志判断是不是有慢 SQL 或循环写入。磁盘 IO 的根因往往很隐蔽，不能只看表象数字，一定要顺着进程往下追。

我有个亲身的排障经历，机器上跑了一个 Elasticsearch 集群，平时 IO 稳定。某天突然 IO 打满，iotop 看到是 ES 的 data 节点在狂写。后来查下来是前一天晚上某个索引的分片数量配置不合理，导致大量分片同时做段合并和 flush。这种时候你就是替换成更好的 SSD，如果没有发现分片策略的问题，IO 照样会被打爆。

4.3 磁盘满与 inode 耗尽的处理

性能排查里，我还经常遇到一个看起来很“蠢”但非常常见的问题：服务突然异常，结果一查是磁盘满了。df -h 能看分区使用率，但有一个容易忽略的指标是 inode。文件系统里每个文件都要占用一个 inode，如果一个分区里的小文件特别多，比如程序异常时疯狂写临时文件，就会把 inode 耗尽。这时候 df -h 显示还有几个 G 可用，但 df -i 已经 100%，进程想创建新文件就会报 “No space left on device”。

排查路径是这样的：先 df -h 看空间，再 df -i 看 inode，两个都确认没问题，再考虑其他因素。如果发现空间满了，用 du -sh * 从根目录一层层往下找，找出那个占空间最大的目录。如果 inode 满了，用 find / -xdev -type f | wc -l 看文件数量，再用 for dir in /var/log /tmp; do echo $dir; find $dir -xdev -type f | wc -l; done 这类命令循环统计各目录下的文件数，把源头揪出来。

注意：删除被进程占用的日志文件时，磁盘空间不会立刻释放。因为进程还持有文件句柄，数据块仍然被占用。正确做法是用 lsof | grep deleted 找到占用文件的进程，重启进程或让进程重新打开日志文件，空间才会真正释放。

5. 网络问题排查：从 ping 到 ss 再到流量分析

5.1 连通性检查与延迟定位

网络问题的排查链路也有一套自己的节奏。第一步通常是 ping，确认目标主机是否可达，以及延迟大致是多少。但 ping 只能证明 ICMP 通不通，并不能证明业务端口通不通，所以接下来要用 telnet <ip> <port> 或 nc -vz <ip> <port> 测试 TCP 端口。

如果你发现 ping 延迟正常，但业务端口连接超时，怀疑点就很多了：目标主机的防火墙、云安全组、监听进程本身是否正常、或是连接数满了。从本机开始，可以按这个思路逐层排查。先 ss -lntp 看端口是否处于 LISTEN 状态，如果没监听，问题多半在应用没起来或启动失败；如果监听了但连不上，再看防火墙和内核参数里的连接队列是否溢出。

在我实际排查经验中，最容易被忽略的其实是“连接队列溢出”。Linux 内核里有两个队列，一个存放半连接（SYN 队列），一个存放全连接（accept 队列）。如果应用处理连接的速度跟不上新连接到达的速度，accept 队列会满，新连接可能被直接丢弃，现象就是客户端连接超时，而服务器的 CPU 和内存都很正常。这个可以通过 ss -lnt 看到当前监听端口的 Send-Q 是否已经满了：

bash复制$ ss -lnt
State    Recv-Q   Send-Q   Local Address:Port   Peer Address:Port
LISTEN   1024     128      0.0.0.0:8080         0.0.0.0:*

Send-Q 对应 accept 队列的最大长度，Recv-Q 是当前已经积压的连接数。如果 Recv-Q 接近 Send-Q，说明应用接受连接太慢，需要检查应用本身的并发处理能力。

5.2 ss 与 netstat：看连接、看监听、看队列

ss 是 netstat 的现代替代品，输出更快、信息更全，我建议直接养成用 ss 的习惯。最常用的几个场景：

• ss -lntp：看本机监听的 TCP 端口和对应进程。
• ss -antp：看所有 TCP 连接，包括 ESTABLISHED、TIME_WAIT、CLOSE_WAIT 等状态。
• ss -s：看整体连接统计，快速判断有没有连接数异常。

排查网络问题经常要看 TIME_WAIT 和 CLOSE_WAIT 的数量。TIME_WAIT 多，一般是因为短连接请求量非常大，属于正常现象，可以通过调整内核参数 net.ipv4.tcp_tw_reuse 等方式优化，但前提是明确自己场景真的适用；CLOSE_WAIT 多则很危险，大多表示应用程序没有正确关闭连接，或者是服务端代码忘记处理对端断开的情况，导致连接资源被占满。CLOSE_WAIT 过多时，最简单的定位方法是 lsof -i :<port> | wc -l 统计句柄数，再用 jstack 或 strace 看应用在哪些地方保持连接不释放。

5.3 实时流量与连接统计的补充工具

iftop 能实时显示各个连接的流量大小，排查“谁在占用带宽”时非常直观。Linux 上通过 yum install iftop 或 apt install iftop 安装，执行后按流量排序，能看到每个连接的收发速度。当业务正常但带宽被打满时，iftop 通常能迅速找出异常的大流量点，比如某些节点在做大量数据同步，或者被外部的爬虫疯狂抓取。

此外，sar -n DEV 1 可以查看每个网卡的实时吞吐量，sar -n TCP,ETCP 1 可以查看 TCP 连接统计，包括主动连接、被动连接、重传率等。重传率如果很高，通常意味着网络链路质量差或者带宽抢占严重。这些数据在性能问题的历史回看里尤其有用，因为 sar 依赖 sysstat 服务，只要之前开了采集，就能回溯故障发生时的网络状态，不需要下次复现才能查。

6. 综合排查：用好 dmesg、strace 和 sar，还原问题现场

6.1 dmesg 看内核日志，抓住 OOM 和硬件级错误

如果说前面的命令是显微镜，那 dmesg 就是“案发现场的监控录像”。内核打印的很多关键信息都会出现在 dmesg 里，尤其是 OOM、磁盘 IO 错误、TCP 丢包等。排查性能问题一定要养成先看 dmesg -T 的习惯，加 -T 可以把时间戳转换成可读时间，方便和故障时间对上。

bash复制$ dmesg -T | tail -50
[Thu Jun 21 10:21:00 2024] Message from syslogd@hostname at Jun 21 10:21:00 ...
[Thu Jun 21 10:21:00 2024] [21383.123456] INFO: task java:12345 blocked for more than 120 seconds.

如果看到 “task blocked for more than 120 seconds” 这类日志，说明有进程在 D 状态卡了 120 秒，通常和磁盘 IO 或者 NFS 挂载失联有直接关系。这类问题用 top 可能只看到 load 很高，但真正的原因藏在 dmesg 里。我处理过一台机器频繁“假死”，应用日志、CPU、内存都正常，最后靠 dmesg 发现的是一块数据盘因为硬件问题进入了只读状态，所有对它的读写请求都卡住排队，才导致整个系统像是被冻住了一样。

6.2 strace 追踪系统调用，定位“诡异卡顿”

有时候性能问题的现象是：进程 CPU 不高、内存充足、磁盘也不忙，但程序就是响应极慢。这种时候 strace 是最好的工具。strace -p <PID> 可以实时打印进程正在执行的系统调用，如果发现进程卡在某个读操作或者 futex 等待上，就能看到线索。

不过 strace 在生产环境上要慎用，因为大量输出本身就拖慢进程。我的习惯是先用 strace -cp <PID> 统计一段时间内系统调用的耗时分布，如果确认某项调用耗时异常，再用 strace -p <PID> -e trace=network,file,read,write 做针对性的过滤，减少干扰输出。比如有次排查一个服务周期性停顿，top 正常，strace 一挂上去就发现进程每隔一段时间会花好几秒去读一个超大的配置文件，后来优化成启动时加载到内存并监听文件变化更新缓存，问题直接消失。

6.3 sar 历史数据回看，复盘真凶

很多性能问题不是持续发生的，而是随机出现、难以复现。如果之前没有监控系统记录，故障一过就什么都查不到了。sysstat 自带 sar 可以按小时、按天保存历史记录，只要 rsyslog/sysstat 服务在跑，你就能回溯之前的 CPU、内存、磁盘、网络数据。比如用户反映“昨晚 2 点服务卡了一下”，但现在已经恢复正常，就可以用 sar -u -f /var/log/sysstat/sa22 看那天 22 号的 CPU 记录，再配合 sar -r、sar -b、sar -n DEV 全面回看。

sa 后面的数字是日期，命令里传入的日期文件要存在你才能查到。生产环境建议打开 sysstat 的历史采集，数据留存时间长一点，因为性能问题很多时候是延迟暴露的，而不是当场就能抓到。这也是排查问题里非常重要的一条：如果你不知道怎么复盘，就去看看 sar 在那一时刻记录了什么，往往比你在故障现场猜测要靠谱得多。

7. 性能排查常用指令速查表

7.1 快速定位指令速查表

为了方便日常使用，我把上面提到的命令做了一个精简速查表，遇到问题先按图索骥，省得临时翻文档：

7.2 我的一点实操心得

排查 Linux 性能问题，工具只是基础，关键还是思路。我每次遇到线上故障，都提醒自己按“先整体后局部、先指标后日志、先现象后猜测”的顺序来走。很多新人看到 CPU 高直接杀进程、看到内存少直接清缓存，操作一时爽，但过两小时问题又冒头，原因就在于没有把根因揪出来。

另外还有一个很实在的建议：生产环境的 sysstat 监控和内核日志轮转一定要提前配好，尤其是 dmesg 和 sar 的历史数据。没有历史数据，性能问题就像没有录像的交通事故，你再厉害也只能靠猜。把排查链路里的每一条命令练熟了，再遇到问题的时候，你手上的工具就不是一把把孤立的刀，而是一套完整的武器系统。