60s性能排查

2021, Jan 08    

当你登录到一台出现性能问题的Linux服务器时，在第一分钟内应该检查什么？

在Netflix，我们拥有庞大的EC2 Linux云环境，以及众多性能分析工具来监控和调查其性能。这些工具包括用于云范围监控的Atlas，以及用于按需实例分析的Vector。虽然这些工具帮助我们解决了大部分问题，但有时我们需要登录到实例并运行一些标准的Linux性能工具。

前60秒：总结

在这篇文章中，Netflix性能工程团队将向你展示在命令行进行优化性能调查的前60秒，使用你应该可用的标准Linux工具。在60秒内，你可以通过运行以下十个命令来获得系统资源使用情况和运行进程的高级概览。寻找错误和饱和度指标，因为它们都易于解释，然后是资源利用率。饱和度是指资源负载超过其处理能力的情况，可以通过请求队列的长度或等待时间来暴露。

uptime
dmesg | tail
vmstat 1
mpstat -P ALL 1
pidstat 1
iostat -xz 1
free -m
sar -n DEV 1
sar -n TCP,ETCP 1
top

其中一些命令需要安装sysstat包。这些命令暴露的指标将帮助你完成USE方法的一部分：一种定位性能瓶颈的方法论。这涉及检查所有资源（CPU、内存、磁盘等）的利用率、饱和度和错误指标。还要注意当你检查并排除了某个资源时，通过排除法可以缩小研究目标，并指导后续调查。

以下部分总结了这些命令，并提供了生产系统的示例。有关这些工具的更多信息，请参阅其man页面。

工具安装

在开始之前，确保系统已安装必要的工具：

# CentOS/RHEL
sudo yum install sysstat

# Ubuntu/Debian
sudo apt-get install sysstat

# 验证安装
which vmstat mpstat pidstat iostat sar

1. uptime

$ uptime 
23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02

这是查看负载平均值的快速方法，它表示想要运行的任务（进程）数量。在Linux系统上，这些数字包括想要在CPU上运行的进程，以及被阻塞在不可中断I/O（通常是磁盘I/O）中的进程。这提供了资源负载（或需求）的高级概念，但如果没有其他工具，无法正确理解。仅值得快速查看。

这三个数字是具有1分钟、5分钟和15分钟常数的指数阻尼移动总和平均值。这三个数字让我们了解负载如何随时间变化。例如，如果你被要求检查有问题的服务器，而1分钟值远低于15分钟值，那么你可能登录太晚，错过了问题。

在上面的示例中，负载平均值显示最近有所增加，1分钟值达到30，而15分钟值为19。数字如此之大意味着很多东西：可能是CPU需求；vmstat或mpstat将确认这一点，它们是此序列中的命令3和4。

负载平均值解读指南

  • 负载 < CPU核心数：系统负载正常
  • 负载 ≈ CPU核心数：系统接近满载，需要关注
  • 负载 > CPU核心数：系统过载，性能可能下降
  • 1分钟值 > 15分钟值：负载正在上升，可能是突发问题
  • 1分钟值 < 15分钟值：负载正在下降，问题可能已缓解

2. dmesg | tail

$ dmesg | tail
[1880957.563150] perl invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=0
[...]
[1880957.563400] Out of memory: Kill process 18694 (perl) score 246 or sacrifice child
[1880957.563408] Killed process 18694 (perl) total-vm:1972392kB, anon-rss:1953348kB, file-rss:0kB
[2320864.954447] TCP: Possible SYN flooding on port 7001. Dropping request.  Check SNMP counters.

这查看最后10条系统消息（如果有的话）。查找可能导致性能问题的错误。上面的示例包括oom-killer和TCP丢弃请求。

不要错过这一步！dmesg总是值得检查的。

常见错误信息

  • OOM Killer：内存不足，系统杀死进程
  • TCP: Possible SYN flooding：可能的SYN洪水攻击或连接数过多
  • I/O error：磁盘I/O错误
  • segfault：段错误，应用程序崩溃
  • kernel panic：内核严重错误

扩展检查

# 查看所有错误
dmesg | grep -i error

# 查看最近的OOM事件
dmesg | grep -i "out of memory"

# 查看硬件错误
dmesg | grep -i "hardware error"

3. vmstat 1

$ vmstat 1
procs ---------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
34  0    0 200889792  73708 591828    0    0     0     5    6   10 96  1  3  0  0
32  0    0 200889920  73708 591860    0    0     0   592 13284 4282 98  1  1  0  0
32  0    0 200890112  73708 591860    0    0     0     0 9501 2154 99  1  0  0  0
32  0    0 200889568  73712 591856    0    0     0    48 11900 2459 99  0  0  0  0
32  0    0 200890208  73712 591860    0    0     0     0 15898 4840 98  1  1  0  0
^C

vmstat是virtual memory stat的缩写，是一个常用的工具（几十年前首次为BSD创建）。它在每一行打印关键服务器统计信息的摘要。

vmstat使用参数1运行，以打印每秒摘要。输出的第一行（在此版本的vmstat中）有一些列显示自启动以来的平均值，而不是前一秒的值。现在，跳过第一行，除非你想学习并记住哪一列是什么。

需要检查的列：

  • r：在CPU上运行并等待轮次的进程数。这比负载平均值提供了更好的信号来确定CPU饱和度，因为它不包括I/O。解释：大于CPU数量的”r”值表示饱和。
  • free：以千字节为单位的空闲内存。如果数字太多无法计数，你就有足够的空闲内存。包含为命令7的”free -m”命令更好地解释了空闲内存的状态。
  • si, so：换入和换出。如果这些不为零，说明内存不足。
  • us, sy, id, wa, st：这些是CPU时间的分解，在所有CPU上的平均值。它们是用户时间、系统时间（内核）、空闲、等待I/O和被窃取的时间（被其他客户，或使用Xen时，客户自己的隔离驱动程序域）。

CPU时间分解将通过添加用户+系统时间来确认CPU是否繁忙。持续的等待I/O程度指向磁盘瓶颈；这是CPU空闲的地方，因为任务被阻塞等待挂起的磁盘I/O。你可以将等待I/O视为CPU空闲的另一种形式，它提供了为什么它们空闲的线索。

系统时间对于I/O处理是必要的。高系统时间平均值（超过20%）可能值得进一步探索：也许内核处理I/O的效率不高。

在上面的示例中，CPU时间几乎完全在用户级别，指向应用程序级别的使用。CPU的平均利用率也远超过90%。这不一定是问题；使用”r”列检查饱和度程度。

vmstat关键指标解读

指标 正常范围 警告范围 危险范围 说明
r < CPU核心数 = CPU核心数 > CPU核心数 运行队列长度
b 0 1-2 > 2 阻塞进程数
swpd 0 > 0 持续增长 交换空间使用
si/so 0 > 0 持续 > 0 交换活动
us < 70% 70-90% > 90% 用户CPU时间
sy < 20% 20-30% > 30% 系统CPU时间
wa < 5% 5-20% > 20% I/O等待时间
id > 20% 10-20% < 10% 空闲时间

4. mpstat -P ALL 1

$ mpstat -P ALL 1
Linux 3.13.0-49-generic (titanclusters-xxxxx)  07/14/2015  _x86_64_ (32 CPU)

07:38:49 PM  CPU   %usr  %nice   %sys %iowait   %irq  %soft  %steal  %guest  %gnice  %idle
07:38:50 PM  all  98.47   0.00   0.75    0.00   0.00   0.00    0.00    0.00    0.00   0.78
07:38:50 PM    0  96.04   0.00   2.97    0.00   0.00   0.00    0.00    0.00    0.00   0.99
07:38:50 PM    1  97.00   0.00   1.00    0.00   0.00   0.00    0.00    0.00    0.00   2.00
07:38:50 PM    2  98.00   0.00   1.00    0.00   0.00   0.00    0.00    0.00    0.00   1.00
07:38:50 PM    3  96.97   0.00   0.00    0.00   0.00   0.00    0.00    0.00    0.00   3.03
[...]

此命令打印每个CPU的CPU时间分解，可用于检查不平衡。单个热CPU可能是单线程应用程序的证据。

CPU负载不均的排查

如果发现某个CPU使用率特别高，可能的原因：

  1. 单线程应用：应用只使用一个CPU核心
  2. CPU亲和性设置：进程被绑定到特定CPU
  3. 中断处理：网络或磁盘中断集中在某个CPU
  4. NUMA架构：内存访问不均匀

检查CPU亲和性

# 查看进程的CPU亲和性
taskset -p <PID>

# 查看中断分布
cat /proc/interrupts | grep -E "CPU|eth0"

5. pidstat 1

$ pidstat 1
Linux 3.13.0-49-generic (titanclusters-xxxxx)  07/14/2015    _x86_64_    (32 CPU)

07:41:02 PM   UID       PID    %usr %system  %guest    %CPU   CPU  Command
07:41:03 PM     0         9    0.00    0.94    0.00    0.94     1  rcuos/0
07:41:03 PM     0      4214    5.66    5.66    0.00   11.32    15  mesos-slave
07:41:03 PM     0      4354    0.94    0.94    0.00   1.89     8  java
07:41:03 PM     0      6521 1596.23    1.89    0.00 1598.11    27  java
07:41:03 PM     0      6564 1571.70    7.55    0.00 1579.25    28  java
07:41:03 PM 60004     60154    0.94    4.72    0.00    5.66     9  pidstat

07:41:03 PM   UID       PID    %usr %system  %guest    %CPU   CPU  Command
07:41:04 PM     0      4214    6.00    2.00    0.00    8.00    15  mesos-slave
07:41:04 PM     0      6521 1590.00    1.00    0.00 1591.00    27  java
07:41:04 PM     0      6564 1573.00   10.00    0.00 1583.00    28  java
07:41:04 PM   108      6718    1.00    0.00    0.00    1.00     0  snmp-pass
07:41:04 PM 60004     60154    1.00    4.00    0.00    5.00     9  pidstat
^C

Pidstat有点像top的每进程摘要，但打印滚动摘要而不是清除屏幕。这对于观察随时间变化的模式很有用，还可以将你看到的内容（复制粘贴）记录到调查记录中。

上面的示例识别出两个java进程负责消耗CPU。%CPU列是所有CPU的总和；1591%显示该java进程消耗了近16个CPU。

pidstat高级用法

# 显示内存统计
pidstat -r 1

# 显示I/O统计
pidstat -d 1

# 显示上下文切换
pidstat -w 1

# 显示特定进程
pidstat -p <PID> 1

# 显示所有指标
pidstat -urd 1

定位高CPU进程后的操作

  1. 查看进程详细信息 
    ps aux | grep <PID>
ps -ef | grep <PID>
  2. 查看线程信息 
    top -H -p <PID>
pidstat -t -p <PID> 1
  3. 生成线程转储（Java应用） 
    jstack <PID> > thread_dump.txt
kill -3 <PID>  # 发送QUIT信号
  4. 使用strace跟踪系统调用 
    strace -p <PID> -c  # 统计模式
strace -p <PID> -e trace=open,read,write  # 跟踪特定调用

6. iostat -xz 1

$ iostat -xz 1
Linux 3.13.0-49-generic (titanclusters-xxxxx)  07/14/2015  _x86_64_ (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          73.96    0.00    3.73    0.03    0.06   22.21

Device:   rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvda        0.00     0.23    0.21    0.18     4.52     2.08    34.37     0.00    9.98   13.80    5.42   2.44   0.09
xvdb        0.01     0.00    1.02    8.94   127.97   598.53   145.79     0.00    0.43    1.78    0.28   0.25   0.25
xvdc        0.01     0.00    1.02    8.86   127.79   595.94   146.50     0.00    0.45    1.82    0.30   0.27   0.26
dm-0        0.00     0.00    0.69    2.32    10.47    31.69    28.01     0.01    3.23    0.71    3.98   0.13   0.04
dm-1        0.00     0.00    0.00    0.94     0.01     3.78     8.00     0.33  345.84    0.04  346.81   0.01   0.00
dm-2        0.00     0.00    0.09    0.07     1.35     0.36    22.50     0.00    2.55    0.23    5.62   1.78   0.03
[...]
^C

这是理解块设备（磁盘）的绝佳工具，包括应用的工作负载和由此产生的性能。查找：

  • r/s, w/s, rkB/s, wkB/s：这些是每秒对设备的读取、写入、读取千字节和写入千字节。使用这些进行工作负载特征分析。性能问题可能仅仅是由于应用了过多的负载。
  • await：I/O的平均时间（以毫秒为单位）。这是应用程序遭受的时间，因为它包括排队时间和正在服务的时间。大于预期的平均时间可能是设备饱和或设备问题的指标。
  • avgqu-sz：向设备发出的平均请求数。大于1的值可能是饱和的证据（尽管设备通常可以并行处理请求，特别是前端多个后端磁盘的虚拟设备）。
  • %util：设备利用率。这实际上是一个繁忙百分比，显示设备每秒执行工作的时间。大于60%的值通常会导致性能不佳（这应该在await中看到），尽管这取决于设备。接近100%的值通常表示饱和。

如果存储设备是前端多个后端磁盘的逻辑磁盘设备，那么100%的利用率可能只是意味着某些I/O正在100%的时间内被处理，但是，后端磁盘可能远未饱和，并且可能能够处理更多工作。

请记住，性能不佳的磁盘I/O不一定是应用程序问题。通常使用许多技术来异步执行I/O，以便应用程序不会阻塞并直接遭受延迟（例如，读取的预读和写入的缓冲）。

磁盘I/O性能指标解读

指标 正常范围 警告范围 危险范围 说明
%util < 60% 60-80% > 80% 设备利用率
await < 10ms 10-50ms > 50ms 平均等待时间
avgqu-sz < 1 1-5 > 5 平均队列长度
r/s + w/s 根据设备 - - IOPS
rkB/s + wkB/s 根据设备 - - 吞吐量

磁盘I/O问题排查

  1. 检查磁盘空间 
    df -h
du -sh /*  # 查找大文件
  2. 检查inode使用 
    df -i
  3. 检查磁盘健康 
    smartctl -a /dev/sda  # 需要smartmontools
  4. 检查文件系统错误 
    dmesg | grep -i "i/o error"
  5. 分析I/O等待的进程 
    iotop  # 需要iotop工具
pidstat -d 1

7. free -m

$ free -m
             total       used       free     shared    buffers     cached
Mem:        245998      24545     221453         83         59        541
-/+ buffers/cache:      23944     222053
Swap:            0          0          0

右侧两列显示：

  • buffers：用于缓冲区缓存，用于块设备I/O。
  • cached：用于页面缓存，由文件系统使用。

我们只想检查这些是否接近零大小，这可能导致更高的磁盘I/O（使用iostat确认）和更差的性能。上面的示例看起来很好，每个都有许多兆字节。

”-/+ buffers/cache”为已用和空闲内存提供了不太混乱的值。Linux使用空闲内存进行缓存，但如果应用程序需要，可以快速回收它。所以在某种程度上，缓存内存应该包含在空闲内存列中，这一行就是这样做的。甚至有一个网站linuxatemyram关于这种困惑。

如果在Linux上使用ZFS，这可能会更加混乱，就像我们对某些服务所做的那样，因为ZFS有自己的文件系统缓存，不能由free -m列正确反映。可能看起来系统空闲内存不足，但实际上该内存可以根据需要从ZFS缓存中使用。

内存使用分析

关键指标

  • total：总内存
  • used：已使用内存（包括buffers和cached）
  • free：完全空闲的内存
  • buffers：块设备缓冲区
  • cached：页面缓存
  • -/+ buffers/cache：实际可用内存 = free + buffers + cached

内存问题判断

  1. 可用内存不足
    • 检查：free -m 中 -/+ buffers/cache 的 free 列
    • 如果 < 总内存的10%，需要关注
  2. Swap使用
    • 检查：free -m 中 Swap 的 used 列
    • 如果 > 0，说明内存不足，系统在使用交换空间
  3. OOM风险
    • 检查：dmesg | grep -i oom
    • 如果出现OOM killer，说明内存严重不足

内存问题排查

# 查看内存使用详情
cat /proc/meminfo

# 查看进程内存使用
ps aux --sort=-%mem | head -20

# 查看内存映射
pmap -x <PID>

# 查看内存泄漏（需要valgrind）
valgrind --leak-check=full <program>

8. sar -n DEV 1

$ sar -n DEV 1
Linux 3.13.0-49-generic (titanclusters-xxxxx)  07/14/2015     _x86_64_    (32 CPU)

12:16:48 AM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s   %ifutil
12:16:49 AM      eth0  18763.00   5032.00  20686.42    478.30      0.00      0.00      0.00      0.00
12:16:49 AM        lo     14.00     14.00      1.36      1.36      0.00      0.00      0.00      0.00
12:16:49 AM   docker0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00

12:16:49 AM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s   %ifutil
12:16:50 AM      eth0  19763.00   5101.00  21999.10    482.56      0.00      0.00      0.00      0.00
12:16:50 AM        lo     20.00     20.00      3.25      3.25      0.00      0.00      0.00      0.00
12:16:50 AM   docker0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
^C

使用此工具检查网络接口吞吐量：rxkB/s和txkB/s作为工作负载的度量，并检查是否已达到任何限制。在上面的示例中，eth0接收达到22 Mbytes/s，即176 Mbits/sec（远低于，例如，1 Gbit/sec限制）。

此版本还具有%ifutil用于设备利用率（全双工两个方向的最大值），这也是我们使用Brendan的nicstat工具来测量的。与nicstat一样，这很难正确获取，在这个示例中似乎不起作用（0.00）。

网络性能指标

指标 说明 关注点
rxpck/s 每秒接收包数 包处理能力
txpck/s 每秒发送包数 包处理能力
rxkB/s 每秒接收KB数 带宽使用
txkB/s 每秒发送KB数 带宽使用
%ifutil 接口利用率 接近100%表示饱和

网络问题排查

  1. 检查网络连接数 
    netstat -an | wc -l
ss -s  # 更现代的替代
  2. 检查网络错误 
    ifconfig  # 查看RX/TX errors
ip -s link show  # 更现代的方式
  3. 检查网络延迟 
    ping <host>
traceroute <host>
  4. 检查网络带宽 
    iperf3 -c <server>  # 需要iperf3工具
  5. 分析网络流量 
    tcpdump -i eth0 -n  # 需要tcpdump
wireshark  # GUI工具

9. sar -n TCP,ETCP 1

$ sar -n TCP,ETCP 1
Linux 3.13.0-49-generic (titanclusters-xxxxx)  07/14/2015    _x86_64_    (32 CPU)

12:17:19 AM  active/s passive/s    iseg/s    oseg/s
12:17:20 AM      1.00      0.00  10233.00  18846.00

12:17:19 AM  atmptf/s  estres/s retrans/s isegerr/s   orsts/s
12:17:20 AM      0.00      0.00      0.00      0.00      0.00

12:17:20 AM  active/s passive/s    iseg/s    oseg/s
12:17:21 AM      1.00      0.00   8359.00   6039.00

12:17:20 AM  atmptf/s  estres/s retrans/s isegerr/s   orsts/s
12:17:21 AM      0.00      0.00      0.00      0.00      0.00
^C

这是一些关键TCP指标的汇总视图。这些包括：

  • active/s：每秒本地发起的TCP连接数（例如，通过connect()）。
  • passive/s：每秒远程发起的TCP连接数（例如，通过accept()）。
  • retrans/s：每秒TCP重传数。

主动和被动计数通常用作服务器负载的粗略度量：新接受的连接数（被动）和下游连接数（主动）。将主动视为出站，被动视为入站可能有助于思考，但这并不严格正确（例如，考虑localhost到localhost的连接）。

重传是网络或服务器问题的标志；它可能是不可靠的网络（例如，公共互联网），或者可能是由于服务器过载并丢弃数据包。上面的示例显示每秒只有一个新TCP连接。

TCP指标解读

指标 正常范围 警告范围 危险范围 说明
active/s 根据应用 - - 主动连接数
passive/s 根据应用 - - 被动连接数
retrans/s 0 < 10 > 10 重传数
isegerr/s 0 > 0 持续 > 0 输入段错误
orsts/s 0 > 0 持续 > 0 输出RST

TCP连接问题排查

  1. 查看连接状态分布 
    netstat -an | awk '/^tcp/ {print $6}' | sort | uniq -c
ss -ant | awk '{print $1}' | sort | uniq -c  # 更现代
  2. 查看TIME_WAIT连接 
    netstat -an | grep TIME_WAIT | wc -l
  3. 查看连接数限制 
    cat /proc/sys/net/core/somaxconn
ulimit -n
  4. 检查TCP参数 
    sysctl -a | grep net.ipv4.tcp
  5. 分析连接问题 
    # 查看连接详情
ss -antp
   
# 查看重传统计
cat /proc/net/sockstat

10. top

$ top
top - 00:15:40 up 21:56,  1 user,  load average: 31.09, 29.87, 29.92
Tasks: 871 total,   1 running, 868 sleeping,   0 stopped,   2 zombie
%Cpu(s): 96.8 us,  0.4 sy,  0.0 ni,  2.7 id,  0.1 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:  25190241+total, 24921688 used, 22698073+free,    60448 buffers
KiB Swap:        0 total,        0 used,        0 free.   554208 cached Mem

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 20248 root      20   0  0.227t 0.012t  18748 S  3090  5.2  29812:58 java
  4213 root      20   0 2722544  64640  44232 S  23.5  0.0 233:35.37 mesos-slave
 66128 titancl+  20   0   24344   2332   1172 R   1.0  0.0   0:00.07 top
  5235 root      20   0 38.227g 547004  49996 S   0.7  0.2   2:02.74 java
  4299 root      20   0 20.015g 2.682g  16836 S   0.3  1.1  33:14.42 java
     1 root      20   0   33620   2920   1496 S   0.0  0.0   0:03.82 init
     2 root      20   0       0      0      0 S   0.0  0.0   0:00.02 kthreadd
     3 root      20   0       0      0      0 S   0.0  0.0   0:05.35 ksoftirqd/0
     5 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:0H
     6 root      20   0       0      0      0 S   0.0  0.0   0:06.94 kworker/u256:0
     8 root      20   0       0      0      0 S   0.0  0.0   2:38.05 rcu_sched

top命令包括我们之前检查的许多指标。运行它很方便，看看是否有任何与早期命令看起来大不相同的内容，这将表明负载是可变的。

top的一个缺点是很难看到随时间变化的模式，这在像vmstat和pidstat这样的工具中可能更清楚，它们提供滚动输出。如果你没有足够快地暂停输出（Ctrl-S暂停，Ctrl-Q继续），并且屏幕清除，间歇性问题的证据也可能丢失。

top实用技巧

  1. 交互式命令
    • P：按CPU使用率排序
    • M：按内存使用率排序
    • T：按运行时间排序
    • k：杀死进程
    • f：选择显示字段
    • 1：显示所有CPU核心
    • H：显示线程
  2. 批处理模式 
    top -b -n 1 > top_output.txt
  3. 监控特定进程 
    top -p <PID1>,<PID2>

top的替代工具

  • htop：更友好的交互式界面
  • atop：更详细的系统监控
  • glances：跨平台监控工具
  • btop：现代化的top替代品

快速检查清单

60秒检查流程

  1. uptime - 查看负载平均值（5秒）
  2. **dmesg tail** - 检查系统错误（5秒）
  3. vmstat 1 - 查看系统整体状态（10秒）
  4. mpstat -P ALL 1 - 查看CPU使用情况（10秒）
  5. pidstat 1 - 查看进程CPU使用（10秒）
  6. iostat -xz 1 - 查看磁盘I/O（10秒）
  7. free -m - 查看内存使用（5秒）
  8. sar -n DEV 1 - 查看网络流量（5秒）
  9. sar -n TCP,ETCP 1 - 查看TCP连接（5秒）
  10. top - 综合查看（剩余时间）

问题定位思路

CPU问题

  • 症状：负载高、CPU使用率高
  • 检查：uptime, vmstat, mpstat, pidstat
  • 定位：找出高CPU进程，分析线程

内存问题

  • 症状：OOM、Swap使用、内存不足
  • 检查：free, vmstat, dmesg
  • 定位：找出内存占用高的进程

磁盘I/O问题

  • 症状：I/O等待高、响应慢
  • 检查：iostat, vmstat (wa列)
  • 定位：找出I/O密集型进程

网络问题

  • 症状：连接超时、重传多、带宽不足
  • 检查：sar -n DEV, sar -n TCP,ETCP
  • 定位：分析网络流量和连接状态

进阶工具推荐

性能分析工具

  1. perf - Linux性能分析工具 
    perf top
perf record -a
perf report
  2. strace - 系统调用跟踪 
    strace -p <PID>
strace -c <command>
  3. tcpdump - 网络包分析 
    tcpdump -i eth0 -n
  4. eBPF工具 - 现代性能分析
    • bcc工具集
    • bpftrace
  5. 火焰图 - 可视化性能分析
    • CPU火焰图
    • 内存火焰图
    • Off-CPU火焰图

持续监控工具

  1. Prometheus + Grafana - 指标监控和可视化
  2. ELK Stack - 日志分析
  3. Jaeger/Zipkin - 分布式追踪
  4. APM工具 - 应用性能监控

总结

这10个命令提供了Linux系统性能问题的快速诊断方法。关键是要：

  1. 系统化：按照固定流程检查，不要遗漏
  2. 关注异常：寻找错误、饱和度和异常高的利用率
  3. 排除法：通过排除正常资源，缩小问题范围
  4. 记录：保存检查结果，便于后续分析
  5. 持续监控：建立监控体系，预防问题

记住，性能问题往往是多方面的，需要综合多个指标来判断。这60秒的检查只是开始，深入分析可能需要更多时间和工具。

Twitter Facebook Google+
# 性能 # Linux