Linux 性能排查必备命令

       运维工作本质就是保证系统环境、程序进程、磁盘空间等正常运行，工作中难免需时时检查各项服务是否正常，有时遇到问题，很多人的第一反应是使用“重启大法”，但有的正式环境，服务器是不允许重启的，重启也解决不了根本问题，所以还得用一套“标准流程”定位问题。这篇文章，就是教你5分钟定位Linux服务器性能瓶颈——不需要花里胡哨的工具，系统自带的命令就够用。

先说结论（记住这句话）：  🎯 性能排查的核心思路：先看整体，再看局部  ⌨️ 五步走：top看全局 → uptime看负载 → free看内存 → df/iostat看磁盘 → ss看网络  🔄 找到瓶颈 → 定位进程 → 解决问题，这才是正确的排查姿势

01

三个必须懂的CPU指标

    用户态CPU（%usr）= 你的应用程序消耗；系统态CPU（%sys）= 内核消耗。高用户态CPU通常是代码问题，高系统态CPU通常是IO或系统调用问题。

      "正在排队等待CPU的任务数"。注意：Load不是CPU百分比！一个单核CPU，Load=1表示满了；4核CPU，Load=4才满。不要被高Load吓到，先除以CPU核数。

      有多少任务在等待CPU。Linux下可通过 vmstat 1 的 r 列查看，通常每个核心的运行队列不超过4。

02

uptime — 3秒看系统负载

💡 Load Average 三个数字的含义：过去1分钟、5分钟、15分钟的系统平均负载。如果1分钟远高于5分钟和15分钟，说明系统刚刚开始变忙；如果三个数都很高且接近，说明系统持续高负载。

03

top — 实时观察CPU在干什么

💡 top界面关键读数： - %Cpu(s): 45.2 us, 8.3 sy → 用户态45.2%（应用）+ 系统态8.3%（内核） - id: 46.1 → 46.1%的CPU是空闲的，这是好的 - wa: 0.0 → IO等待为0，说明CPU没在等磁盘 - PR/NI → 优先级，PR越小优先级越高，NI是nice值（-20到+19）

#top界面下常用快捷键 

P         → 按CPU使用率排序（默认） 

M         → 按内存使用排序 

N         → 按PID排序 

T         → 按CPU时间排序 

k [PID]   → 杀掉指定进程 

r [PID]   → 重新设置进程优先级(nice值) 

1         → 显示每个CPU核心的使用率 

c         → 显示完整命令路径 

d 2       → 设置刷新间隔为2秒 

q         → 退出

💡 题外话：早期面试时，面试官曾问过相关问题，如何从top命令分析判断cpu负载情况，当时没答上来，后面研究之后才搞明白，所以这也是运维工作基础及必会的。

04

htop — top的增强版，更直观

💡 htop 默认可能没安装，执行 apt install htop 或 yum install htop 即可。

💡 判断内存是否够用，关键看 available 而不是 free。Linux系统会尽可能利用空闲内存做缓存（buff/cache）提升IO性能，这些缓存随时可以回收。所以 free 很低但 available 充足，是完全正常的，不必惊慌。

#正常情况：available > total * 20% 

$ free -h              

            total        used        free      buff/cache   available 

Mem:    31Gi       17Gi       8.4Gi          5.6Gi        13Gi   ← 13/31=42%，完全OK 

# 告警情况：available接近0，swap开始被使用 

$ free -h              

              total        used        free      buff/cache   available 

Mem:    31Gi       30Gi       512Mi           2Gi        300Mi   ← 只剩300MB！ 

Swap:    2.0Gi       1.5Gi       512Mi                    ← swap用了1.5GB！

02

vmstat — 内存和CPU的动态全景

💡 内存告警信号：如果 si 和 so 持续大于0，说明系统在频繁swap，这时候即使加内存也来不及了，必须先定位是哪个进程吃光了内存。

01

df — 查看磁盘空间使用情况

💡 磁盘空间告警阈值： - 使用率 < 70%：安全 - 使用率 70-85%：关注，规划扩容 - 使用率 > 85%：告警，立即清理或扩容 - 使用率 > 95%：危险，可能导致服务异常

02

du — 查看目录大小

#查看当前目录下各子目录大小（人性化显示，深度1层） 

$ du -h --max-depth=1 /var 

156M    /var/log 

2.1G    /var/lib 

512M    /var/cache 

2.8G    /var 

# 排序找出最大的目录

$ du -h --max-depth=1 /var | sort -hr 

2.8G    /var 

2.1G    /var/lib 

512M    /var/cache 

156M    /var/log

#步骤1：先用df找出快满的分区 

$ df -h | grep -E '([8-9][0-9]|100)%' 

/dev/sda1       500G  420G   80G   84% / 

# 步骤2：从根目录开始，逐层找出大目录 

$ du -h --max-depth=1 / | sort -hr | head -10 

8.2G    /usr 

5.6G    /var 

3.2G    /home 

1.1G    /root 

... 

# 步骤3：深入大目录继续排查 

$ du -h --max-depth=1 /var | sort -hr 

2.1G    /var/lib 

512M    /var/cache 

156M    /var/log 

# 步骤4：最终定位到大文件 

$ du -h --max-depth=1 /var/log | sort -hr 

120M    /var/log/nginx 

36M     /var/log/mysql

💡 注意：du -sh /* 这种命令在根目录执行会扫描整个文件系统，可能非常慢！建议逐层排查，先看一级目录，再深入。

03

iostat — 查看磁盘IO性能

$ iostat -x 1 3 

Linux 5.4.0-80-generic (server01)   05/06/2026  _x86_64_    (8 CPU) 

avg-cpu:  %user   %nice %system %iowait  %steal   %idle                                  15.23    0.00    3.45       0.12      0.00     81.20 

Device:     rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util 

sda           0.00     2.50   15.00   30.00     0.60     0.12    32.00     0.02    0.44    0.38    0.47   0.22   0.99 

sdb           0.00     5.00  100.00  200.00     4.00     1.00    34.67     2.50    8.33    6.25   10.00   2.50  75.00

💡 磁盘IO告警信号： - await > 10ms：关注，可能有IO瓶颈 - await > 50ms：告警，IO延迟严重 - %util > 80%：磁盘接近饱和，考虑优化或升级SSD

01

ss — 新一代网络连接查看工具

#查看所有TCP连接状态统计 

$ ss -s 

Total: 15234 (kernel 15240) 

TCP:   18456 (estab 12345, closed 5678, orphaned 234, synrecv 12, timewait 4567/0) 

Transport Total     IP        IPv6 

  *           15240     -         - 

RAW       1           0         1 

UDP       23          12        11 

TCP       18456     9234      9222 

INET      18480     9246      9234 

FRAG      0           0            0 

# 查看监听端口 

$ ss -tlnpState   Recv-Q  Send-Q  Local Address:Port  Peer Address:Port 

LISTEN  0       128     0.0.0.0:22         0.0.0.0:*     users:(("sshd",pid=1234,fd=3)) 

LISTEN  0       128     0.0.0.0:80         0.0.0.0:*     users:(("nginx",pid=5678,fd=6)) 

LISTEN  0       128     0.0.0.0:443        0.0.0.0:*     users:(("nginx",pid=5678,fd=7))

#查看所有TCP连接（包括进程信息） 

$ ss -tnp 

 # 只看ESTAB状态的连接 

$ ss -tn state established 

# 查看某个端口的所有连接 

$ ss -tn 'sport = :80' 

# 统计各状态连接数 

$ ss -tan | awk 'NR>1 {print $1}' | sort | uniq -c  

12345 ESTAB   

4567 TIME-WAIT    

   234 LISTEN     

    12 SYN-RECV

💡 TIME_WAIT 过多怎么办？TIME_WAIT 是TCP连接关闭后的正常状态，通常会在几秒到几分钟内自动清理。如果数量达到几万级别，可能需要调整内核参数 net.ipv4.tcp_tw_reuse 和 net.ipv4.tcp_tw_recycle。

02

netstat — 经典网络统计工具

#查看协议统计信息（替代之前的 netstat -an） 

$ netstat -s | head -30 

Ip:    Forwarding: 1    

         12345678 total packets received     

         0 forwarded    

         0 incoming packets discarded    

         12345678 incoming packets delivered    

         8765432 requests sent out 

Tcp:    

         45678 active connection openings    

         12345 passive connection openings    

         789 failed connection attempts    

         456 connection resets received    

         123 connections established    

         9876543 segments received    

         8765432 segments sent out    

         23456 segments retransmitted    

         78 bad segments received    

         456 resets sent

💡 连接数告警信号： - TIME_WAIT > 10000：关注，可能需要优化连接复用 - CLOSE_WAIT 持续增加：告警，应用可能没有正确关闭连接 - 连接数接近 ulimit 限制：危险，可能导致新连接失败

01

ps — 进程快照

#查看所有进程的CPU、内存使用情况（按内存排序） 

$ ps aux --sort=-%mem | head -10 

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND 

mysql     2345  5.4 12.5 4567890 1234567 ?     Sl   Apr20 234:56 /usr/sbin/mysqld 

java      6789 78.2  7.5 8765432  987654 ?     Sl   Apr25 567:89 java -jar app.jar 

nginx     5678 12.1  0.7  123456   78901 ?      S    Apr28  12:34 nginx: worker process 

# 查看进程树 

$ ps axjf 

PPID   PID  PGID   SID TTY      TPGID STAT   UID   TIME COMMAND    

0     1     1     1 ?           -1 Ss       0   0:05 /sbin/init    

1  1234  1234  1234 ?           -1 Ss       0   0:00 /usr/sbin/sshd 

1234  5678  5678  5678 ?           -1 S        0   0:00  \_ sshd: root@pts/0

#找出CPU占用最高的10个进程 

$ ps aux --sort=-%cpu | head -11 

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND 

java      6789 78.2  7.5 8765432  987654 ?     Sl   Apr25 567:89 java -jar app.jar 

mysql     2345  5.4 12.5 4567890 1234567 ?     Sl   Apr20 234:56 /usr/sbin/mysqld 

nginx     5678 12.1  0.7  123456   78901 ?      S    Apr28  12:34 nginx: worker process 

# 找出内存占用最高的10个进程 

$ ps aux --sort=-%mem | head -11 

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND 

mysql     2345  5.4 12.5 4567890 1234567 ?     Sl   Apr20 234:56 /usr/sbin/mysqld 

java      6789 78.2  7.5 8765432  987654 ?     Sl   Apr25 567:89 java -jar app.jar 

# 查看某个进程的详细信息 

$ ps -p 6789 -o pid,ppid,user,%cpu,%mem,vsz,rss,stat,start,time,command  

PID  PPID USER     %CPU %MEM    VSZ   RSS STAT  STARTED     TIME COMMAND 

 6789     1 root     78.2  7.5 8765432 987654 Sl    Apr25 567:89 java -jar app.jar

💡 ps aux 各字段含义： - USER：进程所有者 - PID：进程ID - %CPU：CPU使用百分比 - %MEM：内存使用百分比 - VSZ：虚拟内存大小（KB） - RSS：物理内存大小（KB） - STAT：进程状态（S=睡眠，R=运行，Z=僵尸）

       学了这么多命令，关键是要会用。下面是一个完整的排查流程，教你如何在10分钟内定位服务器卡顿的真正原因。

#=== 第1步：快速判断系统整体状态（30秒）=== 

$ uptime 

10:23:45 up 127 days, load average: 16.34, 8.21, 4.15 

# 解读：Load=16.34，假设16核CPU，负载率=16.34/16=102%，刚超载 

 $ free -h  

                   total        used        free              buff/cache   available 

Mem:           31Gi       29Gi       512Mi          1.2Gi        600MiSwap:            2.0Gi       1.5Gi       512Mi 

 # 解读：available只剩600MB，swap已用1.5GB，内存严重不足！ 

# === 第2步：确认CPU状态（1分钟）=== 

$ top -c -b -n 1 | head -20 

top - 10:25:30 up 127 days, load average: 16.34, 8.21, 4.15 

Tasks: 218 total,   8 running, 210 sleeping,   0 stopped,   0 zombie 

%Cpu(s): 85.2 us, 12.3 sy,  0.0 ni,  0.0 id,  2.5 wa,  0.0 hi,  0.0 si,  0.0 st 

# 解读：用户态CPU 85.2%，系统态12.3%，空闲0%，wa=2.5%说明有IO等待 

# === 第3步：找出CPU/内存大户（1分钟）=== 

$ ps aux --sort=-%cpu | head -5 

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND 

java      6789 78.2  7.5 8765432  987654 ?     Sl   Apr25 567:89 java -jar app.jar 

# 解读：java进程PID=6789，吃掉78.2%的CPU和7.5%的内存 

# === 第4步：确认磁盘状态（1分钟）=== 

$ df -h | grep -E '([8-9][0-9]|100)%' 

/dev/sda1       500G  450G   50G   90% / 

# 解读：根分区使用率90%，需要清理 

$ iostat -x 1 3 | grep -A1 Device 

Device:     rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  %util 

sda           0.00    15.00   50.00  100.00     2.00     0.50    40.00     3.50   23.33  75.50 

# 解读：%util=75.5%，磁盘接近饱和，await=23ms偏高 

# === 第5步：确认网络状态（1分钟）=== 

$ ss -s 

TCP:   18456 (estab 12345, closed 5678, timewait 4567/0) 

 # 解读：连接数正常，TIME_WAIT=4567正常范围 

# === 第6步：综合判断 === 

# 问题定位： 

# 1. 内存不足：available=600MB，swap用了1.5GB 

# 2. java进程异常：PID=6789，CPU 78.2%，可能是内存泄漏导致频繁GC 

# 3. 磁盘压力大：%util=75.5%，可能是swap写入导致 

# 排查建议： 

# 1. 先用 jstat -gc 6789 看java的GC情况 

# 2. 用 jmap -histo:live 6789 看对象分布 

# 3. 临时扩容swap或重启java进程 

# 4. 长期方案：增加内存或优化java程序

坑1：只看CPU利用率，不看Load Average

坑2：只看 free，不看 available

坑3：磁盘空间够用就不看IO

坑4：看到高CPU就重启服务

坑5：忽略Swap的影响

核心排查流程

第一步：uptime 看负载，判断系统整体忙不忙

第二步：free -h 看内存，关键看 available 和 swap

第三步：df -h 看空间，iostat -x 看IO

第四步：ss -s 看网络，ss -tlnp 看端口

第五步：ps aux --sort 定位问题进程

怦然心动--往期推荐 ♥