1. 引言当服务器告警响起你的第一分钟应该做什么作为一名在运维和性能分析领域摸爬滚打了十多年的老手我处理过无数次线上服务器的性能危机。无论是凌晨三点被电话叫醒还是正在开会时大屏突然飘红那种肾上腺素飙升的感觉相信很多同行都深有体会。在Netflix这样规模的环境中我们依赖像Atlas这样的云监控和Vector这样的按需分析工具它们像7x24小时不眠的哨兵为我们描绘了系统健康的宏观图景。然而当警报真正拉响你需要SSH登录到那台具体的EC2 Linux实例进行深度排查时工具就只是工具真正关键的是你头脑中的排查思路和手速——尤其是在最初的黄金60秒内。这最初的60秒是定位问题的“侦查阶段”。你的目标不是立刻解决所有问题而是快速、准确地抓住系统的“生命体征”判断问题的性质和严重程度为后续的深度分析指明方向。盲目地运行一堆复杂命令或者一头扎进日志海洋往往是最低效的做法。今天我想分享的正是Netflix性能工程团队内部传承的一套“60秒快速检查清单”。这套方法的核心不是介绍什么高深莫测的新工具而是教你如何像老练的急诊医生一样利用Linux系统内置的、唾手可得的命令行工具在最短时间内完成一次高效的系统“体检”。我们会聚焦于CPU、内存、磁盘I/O和网络这些核心资源通过10个命令快速评估其使用率Utilization、饱和度Saturation和错误Errors——也就是业界常说的USE方法。记住我们的原则是先看整体再抓细节先找异常指标再深挖根因。2. 性能排查的核心思路与USE方法解析在具体介绍命令之前我们必须先统一思想性能问题的本质是什么在我看来绝大多数性能瓶颈都可以归结为资源争用。当应用程序对某种资源CPU、内存、磁盘、网络的需求超过了该资源所能提供的供给时排队、等待、超时、错误便随之而来最终体现为用户感知的延迟增高、吞吐下降或服务不可用。因此系统化的性能分析不是漫无目的地瞎猜而是有章可循的侦查。这里我强烈推荐Brendan Gregg提出的USE方法Utilization Saturation Errors。这是一个极其高效的问题定位框架使用率Utilization资源忙于提供服务的时间百分比。例如CPU使用率90%磁盘使用率70%。高使用率是潜在问题的信号但未必直接导致性能下降比如一个CPU核100%运行一个单线程计算任务只要没有其他任务等待就不是问题。饱和度Saturation资源因无法服务更多请求而被迫排队或等待的程度。这是衡量性能劣化的更直接指标。例如CPU运行队列长度有多少进程在等待CPU、磁盘I/O等待队列长度、TCP连接队列溢出等。饱和度往往比单纯的高使用率更能说明问题。错误Errors资源在提供服务时发生的错误数量或频率。例如网络丢包、TCP重传、磁盘读写错误、内存分配失败OOM等。错误通常是问题已经发生或即将发生的明确信号。我们的“60秒清单”就是围绕这三个维度设计的。在登录服务器的第一分钟你需要像扫描仪一样快速收集这些核心资源的USE指标。这能帮你迅速回答几个关键问题系统整体负载如何瓶颈可能出现在哪个资源上是CPU算力不足还是内存吃紧或是磁盘I/O卡顿有没有发生严重的错误有了这些初步判断你才能决定下一步是去分析Java应用的GC日志还是去检查数据库的慢查询抑或是去排查网络链路的稳定性。注意以下部分命令如mpstat,pidstat,iostat,sar来自sysstat工具包。在大多数Linux发行版上你可以通过yum install sysstatRHEL/CentOS或apt-get install sysstatUbuntu/Debian来安装。建议在系统构建阶段就预先安装好这个工具包避免在故障排查时手忙脚乱。3. 黄金60秒十大命令详解与实战解读现在让我们进入实战环节。假设你刚刚连接到一台疑似存在性能问题的生产服务器。请按顺序或根据直觉并行执行以下命令。为了获得动态视图多数命令我们使用1作为参数表示每秒刷新一次。3.1 全局概览uptime– 系统负载的“第一印象”命令与输出示例$ uptime 23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02解读与实战技巧uptime可能是所有命令中最简单也最富含信息的一个。它输出的最后三个数字——系统平均负载Load Average——是理解系统整体压力的钥匙。它是什么平均负载表示的是系统中处于可运行状态正在使用CPU或等待使用CPU和不可中断状态通常是在等待磁盘I/O的平均进程数。注意它不是一个百分比而是一个数量。三个数字的含义分别代表过去1分钟、5分钟、15分钟的平均值。这三个值构成的趋势至关重要。如何分析看绝对值与CPU核心数的关系一个粗略但有效的经验法则是如果平均负载持续高于CPU逻辑核心数就可能存在CPU资源饱和。例如一台4核机器负载长期在8以上肯定有问题。上例中的30.02无论多少核都高得吓人。看趋势关键比较1分钟、5分钟、15分钟的值。1分钟值远高于15分钟值如 30.02 vs 19.02说明负载在近期急剧上升问题可能正在发生或刚刚发生。这是需要立刻警惕的信号。1分钟值远低于15分钟值可能意味着一个高负载事件已经过去你来得有点晚需要依赖历史日志分析了。三个值都高且平稳说明系统长期处于高负载状态需要优化。它能告诉你什么uptime给出了一个关于系统饱和度的顶级视图。高负载意味着有进程在排队等待资源CPU或I/O。但它不能告诉你具体是CPU饱和还是I/O饱和。这是后续命令如vmstat要解决的问题。实操心得我习惯在登录任何服务器的第一时间运行uptime。如果负载看起来正常我会稍微松一口气如果数字异常我会立刻进入战斗状态并根据负载趋势决定下一步排查的紧迫性。3.2 内核日志速览dmesg | tail– 捕捉致命错误的“黑匣子”命令与输出示例$ dmesg | tail [1880957.563] Out of memory: Kill process 18694 (java) score 511 or sacrifice child [1880957.567] Killed process 18694 (java) total-vm:2532680kB, anon-rss:1416508kB, file-rss:0kB [1880980.322] TCP: Possible SYN flooding on port 8080. Sending cookies.解读与实战技巧dmesg显示的是内核环形缓冲区中的消息。这些消息往往记录了系统底层发生的重大事件很多性能问题在这里会留下直接的“罪证”。关注什么OOMOut-Of-Memory杀手记录如上例第一行。这是最严重的信号之一表明物理内存和交换空间都已耗尽内核被迫杀死一个或多个进程来释放内存。如果你看到这个内存问题就是当前的主要矛盾。硬件错误磁盘I/O错误、CPU纠正错误等。网络异常TCP丢包、连接溢出如SYN flooding等警告。文件系统错误EXT4/JFS/Btrfs等文件系统报告的错误。为什么用tail因为缓冲区可能很大我们只关心最近发生的、最可能相关的事件。有时我也会用dmesg | tail -20多看几行。时间戳解读方括号[1880957.563]里的数字是系统启动后的秒数。你可以用date -d $(awk {print $1} /proc/uptime)来估算系统启动的绝对时间从而判断错误发生的大致时刻。注意事项dmesg的输出可能被配置了速率限制一些非关键信息可能不会显示。如果怀疑有更早的关键错误可以尝试dmesg | grep -E -i “(oom|kill|error|fail|tcp drop)”进行过滤搜索。3.3 系统资源全景图vmstat 1– 虚拟内存与CPU状态的动态监控命令与输出示例$ 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 6 2 24580 15232 3200 1024000 0 0 0 12 450 890 65 10 20 5 0 12 1 24580 8432 3200 1024500 1 0 1024 256 980 1200 70 15 10 5 0解读与实战技巧vmstat 1每秒输出一行提供了一个关于进程、内存、交换区、I/O和CPU的实时、动态的全景视图。请忽略第一行自启动以来的平均值从第二行开始看实时数据。我们按列分组解读Procs进程r运行队列长度。等待CPU资源的可运行进程数。这是CPU饱和度的关键指标。如果r的值持续大于CPU逻辑核心数说明CPU已经饱和进程在排队。上例中r在6到12之间波动如果这是台4核机器饱和度就很高。b 处于不可中断睡眠状态的进程数通常是在等待I/O如磁盘I/O。如果这个值持续大于0可能意味着I/O是瓶颈。Memory内存swpd 已使用的虚拟内存交换分区大小。如果这个值不为0且在增长结合后面的si/so看是内存不足的信号。free 空闲的物理内存。在Linux中这个值小不一定有问题因为系统会利用空闲内存做缓存cache和buff。buff/cache 用于缓冲区缓存和页面缓存的内存。这部分内存可以被应用程序快速回收。Swap交换si 每秒从磁盘交换区读入到内存的数据量kB。so 每秒从内存写入到磁盘交换区的数据量kB。这是关键只要si或so持续为非零值哪怕很小就说明系统正在发生交换swapping。由于磁盘速度远慢于内存交换会带来严重的性能下降。这是内存瓶颈的明确信号。I/O块设备bi 每秒从块设备接收的块数blocks in。bo 每秒发送到块设备的块数blocks out。这两个值反映了磁盘I/O的负载。但更详细的I/O分析需要iostat。System系统in 每秒的中断数。cs 每秒的上下文切换次数。异常高的中断或上下文切换可能意味着不合理的进程调度或硬件问题。CPU处理器 – 最重要的部分之一us 用户态进程占用CPU时间百分比。sy 内核态系统占用CPU时间百分比。id CPU空闲时间百分比。wa CPU等待I/O的时间百分比。st 被虚拟化环境如VMware Xen“偷走”的时间百分比对于物理机或大多数云主机通常为0。分析模式us sy高如 80%CPU繁忙。如果us很高通常是应用代码问题如果sy很高如持续 20%可能系统调用频繁或内核处理I/O效率低。wa高CPU花费大量时间等待I/O。这是I/O瓶颈的强烈指示。此时id空闲可能很低但CPU并非忙于计算而是在“空等”。上例中wa为5%需要结合iostat进一步确认磁盘是否真的饱和。id高CPU空闲。但如果此时r运行队列也高则可能是进程在等待锁或其他资源而非CPU。实操心得vmstat 1是我在怀疑系统资源问题时必看的“仪表盘”。我会同时开一个终端窗口运行它观察几秒到十几秒的动态变化。重点关注r,b,si/so,wa这几列的趋势。一个稳定的高wa配上增长的b几乎可以断定是磁盘I/O问题。3.4 CPU核心负载均衡洞察mpstat -P ALL 1– 发现单核热点命令与输出示例$ mpstat -P ALL 1 Linux 5.4.0-... 04/10/2024 _x86_64_ (8 CPU) ... 05:30:01 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 05:30:02 PM all 70.12 0.00 15.25 4.63 0.00 0.12 0.00 0.00 0.00 9.88 05:30:02 PM 0 98.00 0.00 2.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 05:30:02 PM 1 10.00 0.00 90.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 05:30:02 PM 2 65.00 0.00 30.00 5.00 0.00 0.00 0.00 0.00 0.00 0.00 ...解读与实战技巧mpstat是vmstat中CPU数据的多核详细版。-P ALL表示报告所有CPU核心的统计1表示每秒刷新。核心价值发现负载不均衡。在多核系统中整体CPU使用率可能看起来不高比如all行显示%idle有9.88%但个别核心可能已经100%繁忙。这通常是单线程应用或锁竞争激烈的典型表现。上例中CPU 0 的%usr高达98%而CPU 1 的%sys高达90%说明有两个不同的瓶颈点一个在用户态计算一个在内核态系统调用。字段解读与vmstat类似但更细%usr 用户态。%sys 内核态。%iowait 等待I/O。%irq/%soft 处理硬件/软件中断的时间。%idle 空闲。如何行动如果发现某个核心持续100%繁忙而其他核心空闲下一步就应该用pidstat或top找出是哪个进程的哪个线程绑在了这个核心上然后分析该进程的代码或配置。3.5 进程级CPU消耗追踪pidstat 1– 定位“罪魁祸首”命令与输出示例$ pidstat 1 Linux 5.4.0-... 04/10/2024 _x86_64_ (8 CPU) 05:32:01 PM UID PID %usr %system %guest %wait %CPU CPU Command 05:32:02 PM 1001 12345 1250.00 350.00 0.00 0.00 1600.00 3 java 05:32:02 PM 1001 23456 15.00 5.00 0.00 1.00 20.00 1 nginx解读与实战技巧pidstat像是一个动态的、进程级别的top但它以滚动方式输出更便于记录和观察趋势。默认显示CPU使用情况。关键列%CPU 该进程使用的总CPU百分比。注意这是所有CPU核心的占用总和因此可以超过100%。一个进程占用1600%的CPU意味着它平均使用了16个核心的算力。上例中的Java进程就是如此这是一个典型的CPU密集型或多线程应用。%usr/%system 进程在用户态/内核态的CPU使用率。CPU 该进程最近一次运行所在的核心编号。结合mpstat可以验证热点进程是否集中在某个核心。进阶用法pidstat -d 1 查看进程的磁盘I/O统计。pidstat -r 1 查看进程的内存统计如常驻集大小RSS、缺页异常。pidstat -w 1 查看进程的上下文切换情况。实战流程当vmstat或mpstat显示CPU使用率高时立刻运行pidstat 1通常能在前几行迅速定位到消耗CPU最多的进程。这是从系统层面定位到具体应用层面的关键一步。3.6 磁盘I/O性能深度剖析iostat -xz 1– 定位存储瓶颈命令与输出示例$ iostat -xz 1 Linux 5.4.0-... 04/10/2024 _x86_64_ (8 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 65.12 0.00 10.25 15.63 0.00 9.00 Device r/s w/s rkB/s wkB/s await r_await w_await aqu-sz %util vda 0.00 250.00 0.00 20480.00 120.50 0.00 120.50 15.20 99.80解读与实战技巧iostat是分析块设备磁盘性能的利器。-x显示扩展统计-z省略在采样期间没有活动的设备让输出更简洁。关键指标解读r/s,w/s 每秒向设备发起的读/写请求数IOPS。rkB/s,wkB/s 每秒读/写的数据量吞吐量。await 每个I/O请求的平均等待时间毫秒。这是衡量磁盘响应速度、影响应用性能的直接指标。它包括请求在队列中的排队时间和服务时间。通常机械硬盘的await应低于20msSSD应低于5ms。上例中的120.5ms非常高。r_await,w_await 分别针对读和写的平均等待时间。aqu-sz 平均请求队列长度。如果大于1说明设备可能已经饱和请求开始堆积。%util设备利用率即设备忙于处理I/O请求的时间百分比。对于单块磁盘如果持续接近100%通常意味着磁盘已饱和是性能瓶颈。但请注意一个重要的例外对于由多块磁盘组成的RAID阵列或逻辑卷LVM%util达到100%可能只意味着部分底层磁盘繁忙而其他磁盘可能还有余力。此时需要结合await和aqu-sz判断。分析模式高%util 高await 高aqu-sz 经典的磁盘I/O饱和现象。应用性能会因I/O等待而严重下降。高%util 低await 磁盘处理能力良好请求能被快速处理。这可能不是问题。低%util 高await 这可能意味着磁盘本身有问题如即将故障或者文件系统、驱动程序存在问题导致单个请求服务时间异常长。结合vmstat的wa如果vmstat显示高waiostat就能告诉你具体是哪个磁盘设备导致的以及严重程度。注意事项云环境如AWS EBS中的磁盘性能有其特殊性通常有IOPS和吞吐量的突发额度与基线限制。当iostat显示性能不佳时也需要检查是否达到了云磁盘的性能上限。3.7 内存使用真相free -m与缓存机制命令与输出示例$ free -m total used free shared buff/cache available Mem: 7982 5120 132 100 2730 2450 Swap: 2047 200 1847解读与实战技巧free命令看内存新手和老手常常得出截然不同的结论关键在于理解Linux的内存管理机制。不要只看free列这是最常见的误区。Linux内核会充分利用未被应用程序使用的内存来缓存磁盘数据buff/cache以提升后续的读性能。因此free内存少是正常且良好的现象。关键看available列这个指标在较新内核中引入估算的是在不进行交换swap的情况下可供新应用程序使用的内存量。它考虑了free内存和可回收的缓存buff/cache。上例中虽然free只有132MB但available高达2450MB说明内存非常充足。关注Swap的使用。如果Swap的used持续增长或者free命令下方的si/so需结合vmstat不为零说明系统正在发生交换这是内存不足的明确信号会严重影响性能。关于buff/cachebuffers 主要用于缓存文件系统的元数据如目录结构、inode和缓存裸磁盘的块操作。cache 主要是页缓存Page Cache缓存文件的实际数据。当应用程序需要内存时这部分缓存可以被快速释放。所以它们本质上是“可用的”内存。一个经典陷阱有网站叫“Linux ate my RAM”专门解释这个现象。简单说内存用了才是赚了空闲着就是浪费。只要available内存充足buff/cache再大也不是问题。3.8 网络吞吐量观测sar -n DEV 1– 监控网络接口流量命令与输出示例$ sar -n DEV 1 Linux 5.4.0-... 04/10/2024 _x86_64_ (8 CPU) 05:35:01 PM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil 05:35:02 PM eth0 1250.00 800.00 10240.00 5120.00 0.00 0.00 5.00 0.80 05:35:02 PM lo 10.00 10.00 0.80 0.80 0.00 0.00 0.00 0.00解读与实战技巧sarSystem Activity Reporter是sysstat套件中的历史数据收集和报告工具但用1参数也可以做实时监控。-n DEV用于查看网络设备统计。关键指标rxkB/s,txkB/s 每秒接收/发送的千字节数。这是衡量网络吞吐量的核心指标。你需要知道你的网卡上限如1 Gbit/s ≈ 125 MB/s 10 Gbit/s ≈ 1.25 GB/s。上例中接收约10MB/s发送约5MB/s对于千兆网卡远未饱和。rxpck/s,txpck/s 每秒接收/发送的数据包数。异常高的包速率尤其是小包可能给CPU带来中断处理压力。%ifutil 网络接口利用率。这是一个理论上的最大值百分比但sar和大多数工具很难精确计算它有时显示为0.00。更准确的工具是nicstat但sar的rxkB/s/txkB/s已足够判断是否接近带宽上限。如何判断瓶颈如果rxkB/s或txkB/s持续接近网络接口的理论带宽并且应用表现出网络延迟那么网络带宽可能就是瓶颈。同时可以结合后面的TCP重传指标来看。3.9 TCP连接与重传监控sar -n TCP,ETCP 1– 洞察网络健康度命令与输出示例$ sar -n TCP,ETCP 1 Linux 5.4.0-... 04/10/2024 _x86_64_ (8 CPU) 05:36:01 PM active/s passive/s iseg/s oseg/s 05:36:02 PM 1.20 15.50 1250.00 1300.00 05:36:01 PM atmptf/s estres/s retrans/s isegerr/s orsts/s 05:36:02 PM 0.00 0.00 5.20 0.00 0.00解读与实战技巧这个命令专注于TCP层的指标对于网络服务如Web服务器、数据库的性能排查至关重要。关键指标解读active/s 每秒本地主动发起的TCP连接数客户端行为如connect()。passive/s 每秒远程发起的、本地接受的TCP连接数服务器行为如accept()。这两个数字可以粗略衡量服务器的新建连接压力。retrans/s 每秒TCP重传的段数。这是网络问题或服务器过载的黄金指标**。**非零的重传意味着数据包在网络上丢失或严重延迟或者服务器因过载而未能及时响应导致客户端超时重传。偶尔的重传在公网环境中是正常的但持续的重传如每秒几次以上就是严重问题。上例中5.20 retrans/s需要警惕。atmptf/s 每秒失败的TCP连接尝试数如超时。高数值可能意味着网络问题或对端服务不可用。estres/s 每秒从ESTABLISHED状态直接到CLOSED状态的连接数异常断开。实战应用当应用报告网络慢或连接超时时查看retrans/s。如果这个值很高问题很可能出在网络层面包括本地服务器因负载过高导致的“软”网络问题。如果重传率正常但应用依然慢就需要从应用层或更上层的协议如HTTP找原因了。3.10 交互式全局监控top/htop– 熟悉的“控制面板”命令解读top是大家最熟悉的工具它提供了一个动态更新的、交互式的系统进程视图。它整合了前面许多命令的信息系统负载load average、CPU使用率、内存使用情况以及详细的进程列表。优势与局限优势交互性强可以排序按CPU、内存、搜索、杀死进程。htop是其增强版界面更友好支持鼠标操作和树状视图。局限信息是瞬态的滚动刷新会清屏不利于观察趋势和记录历史数据。在快速变化的场景下容易错过关键瞬间。在60秒清单中的定位top或htop更适合在通过前述命令初步定位方向后进行深入的进程级交互式调查。例如用pidstat找到高CPU进程后用top查看该进程的更多细节如打开的文件、线程数或者用htop的树状模式查看进程父子关系。在最初的快速扫描阶段非交互的、持续滚动的命令如vmstat 1,pidstat 1往往更有效率因为你可以让它们持续运行并观察模式同时在一个单独的终端窗口执行其他命令。4. 组合拳实战典型性能问题排查流程与案例掌握了单个工具更重要的是学会在实战中组合使用它们。下面我通过两个常见的场景来演示如何在60秒内运用这套组合拳。4.1 场景一应用响应缓慢怀疑CPU或I/O问题第0-10秒全局健康检查uptime: 发现负载平均值很高如load average: 25.00, 20.00, 15.00且1分钟值高于15分钟值说明负载在上升。dmesg | tail: 快速扫一眼没有OOM或硬件错误。第11-30秒资源瓶颈定位vmstat 1: 观察几秒。发现r列运行队列数值持续远大于CPU核心数如r: 30且ussy超过90%但wa很低。初步判断CPU饱和。mpstat -P ALL 1: 确认是否所有核心都忙还是个别核心热点。发现所有核心%usr或%sys都很高说明是普遍性计算压力。第31-50秒定位元凶进程pidstat 1: 立刻看到某个Java或Python进程的%CPU列高达800%或更多。锁定进程PID。第51-60秒深入探查与决策top -p [PID]: 切换到top查看该进程的详细状态或者用htop查看其线程。可以按H查看线程模式确认是否是某个特定线程吃满CPU。结论与行动基本确定是某个应用进程CPU使用异常。接下来可以收集该进程的堆栈信息jstackfor Java,perf/pstackfor others、检查应用日志或者考虑临时重启该实例。4.2 场景二数据库查询超时怀疑磁盘或内存问题第0-10秒全局健康检查uptime: 负载高。dmesg | tail: 没有明显错误。第11-30秒资源瓶颈定位vmstat 1: 观察几秒。发现wa列I/O等待持续很高如wa: 40%id空闲很低但ussy不高。同时b列阻塞进程也有数值。初步判断I/O瓶颈。注意看si/so交换如果非零则内存不足加剧了I/O问题。第31-50秒细化I/O与内存分析iostat -xz 1: 确认是哪个磁盘设备%util接近100%且await很高如 100ms。假设是/dev/vdb。free -m: 查看available内存是否充足Swap used是否在增长。第51-60秒定位I/O发起者pidstat -d 1: 查看哪个进程对/dev/vdb的读写最频繁。很可能是数据库进程如mysqld,postgres。结论与行动确定是磁盘I/O瓶颈且可能由数据库大量读写导致。接下来需要登录数据库分析慢查询日志、检查索引、或者查看是否有全表扫描等操作。如果是云盘还需要检查是否达到了IOPS或吞吐量限制。5. 常见陷阱、进阶工具与排查心法5.1 新手常踩的坑与误区只看free内存惊呼“内存没了” 如前所述这是最大的误区。请认准available列。%util100% 就等于磁盘坏了 对于RAID或逻辑卷%util100% 可能只是部分磁盘忙。要结合await和aqu-sz判断。如果await依然很低说明阵列还能处理请求。负载高一定是CPU问题 负载高可能是CPU队列也可能是I/O等待队列不可中断进程。一定要用vmstat看r和b用iostat看await来区分。忽略单个核心的热点 整体CPU使用率不高但应用依然慢。可能是单个线程绑死在某个核心上mpstat能发现导致该核心上的任务排队。不关注趋势只看单点数据 性能问题往往是动态的。运行命令时一定要加间隔参数如1观察几秒到几十秒的变化趋势才能捕捉到间歇性的峰值或规律。5.2 60秒之后的武器库进阶性能工具简介最初的60秒是为了快速定位方向。一旦确定了怀疑对象就需要更专业的工具进行深度剖析CPU深度分析perf Linux内核自带的性能分析神器。可以做CPU性能计数器采样perf record/perf report生成火焰图精准定位热点函数。strace/ltrace 跟踪进程的系统调用或库函数调用适用于分析卡顿在哪个具体调用上。内存深度分析slabtop 查看内核slab缓存使用情况诊断内核内存泄漏。valgrind/AddressSanitizer 用于开发环境检测用户态程序的内存错误和泄漏。pmap 查看进程详细的内存映射。I/O深度分析iotop 类似top但针对磁盘I/O实时显示每个进程的I/O速率。blktrace/btt 块设备I/O的终极追踪工具可以分析I/O请求在块设备层的完整生命周期但比较复杂。网络深度分析nicstat 比sar -n DEV更精确地测量网络接口利用率。netstat -s或ss -s 查看丰富的TCP/UDP层统计信息。tcpdump/wireshark 抓包分析解决复杂的网络协议问题。全链路追踪BCC/bpftrace 基于eBPF的动态追踪工具集可以编写脚本对内核和用户态程序进行超低开销的深度观测功能极其强大是现代性能分析的标杆。5.3 性能排查心法像侦探一样思考最后分享几点我多年总结的心得假设驱动数据验证 不要瞎猜。先根据现象如“API延迟高”提出假设“可能是数据库慢”然后用工具收集数据去验证或推翻它。自上而下逐层排查 从宏观负载、整体资源到微观具体进程、线程、函数。USE方法就是很好的自上而下框架。对比基线关注变化 了解系统在正常状态下的指标基线至关重要。很多问题表现为指标的“异常变化”而非绝对值。一次只变一个变量 在尝试优化或修改配置时避免同时改变多个参数否则你无法知道是哪个改动生效了。日志是你的朋友 系统命令告诉你“是什么”应用日志和错误日志往往能告诉你“为什么”。永远不要忽略/var/log/下的相关日志。这套“60秒性能检查清单”是我工具箱里最常用、最可靠的一部分。它不能解决所有问题但能确保你在面对一台陌生的问题服务器时不会手足无措而是能像经验丰富的侦探一样在最短时间内找到最有价值的线索为后续的深度排查打开突破口。记住工具是死的思路是活的。将这些命令和USE方法论内化形成你的肌肉记忆和条件反射你就能在每一次性能危机中抢得至关重要的先机。
Netflix性能工程师分享：Linux服务器性能排查黄金60秒检查清单
1. 引言当服务器告警响起你的第一分钟应该做什么作为一名在运维和性能分析领域摸爬滚打了十多年的老手我处理过无数次线上服务器的性能危机。无论是凌晨三点被电话叫醒还是正在开会时大屏突然飘红那种肾上腺素飙升的感觉相信很多同行都深有体会。在Netflix这样规模的环境中我们依赖像Atlas这样的云监控和Vector这样的按需分析工具它们像7x24小时不眠的哨兵为我们描绘了系统健康的宏观图景。然而当警报真正拉响你需要SSH登录到那台具体的EC2 Linux实例进行深度排查时工具就只是工具真正关键的是你头脑中的排查思路和手速——尤其是在最初的黄金60秒内。这最初的60秒是定位问题的“侦查阶段”。你的目标不是立刻解决所有问题而是快速、准确地抓住系统的“生命体征”判断问题的性质和严重程度为后续的深度分析指明方向。盲目地运行一堆复杂命令或者一头扎进日志海洋往往是最低效的做法。今天我想分享的正是Netflix性能工程团队内部传承的一套“60秒快速检查清单”。这套方法的核心不是介绍什么高深莫测的新工具而是教你如何像老练的急诊医生一样利用Linux系统内置的、唾手可得的命令行工具在最短时间内完成一次高效的系统“体检”。我们会聚焦于CPU、内存、磁盘I/O和网络这些核心资源通过10个命令快速评估其使用率Utilization、饱和度Saturation和错误Errors——也就是业界常说的USE方法。记住我们的原则是先看整体再抓细节先找异常指标再深挖根因。2. 性能排查的核心思路与USE方法解析在具体介绍命令之前我们必须先统一思想性能问题的本质是什么在我看来绝大多数性能瓶颈都可以归结为资源争用。当应用程序对某种资源CPU、内存、磁盘、网络的需求超过了该资源所能提供的供给时排队、等待、超时、错误便随之而来最终体现为用户感知的延迟增高、吞吐下降或服务不可用。因此系统化的性能分析不是漫无目的地瞎猜而是有章可循的侦查。这里我强烈推荐Brendan Gregg提出的USE方法Utilization Saturation Errors。这是一个极其高效的问题定位框架使用率Utilization资源忙于提供服务的时间百分比。例如CPU使用率90%磁盘使用率70%。高使用率是潜在问题的信号但未必直接导致性能下降比如一个CPU核100%运行一个单线程计算任务只要没有其他任务等待就不是问题。饱和度Saturation资源因无法服务更多请求而被迫排队或等待的程度。这是衡量性能劣化的更直接指标。例如CPU运行队列长度有多少进程在等待CPU、磁盘I/O等待队列长度、TCP连接队列溢出等。饱和度往往比单纯的高使用率更能说明问题。错误Errors资源在提供服务时发生的错误数量或频率。例如网络丢包、TCP重传、磁盘读写错误、内存分配失败OOM等。错误通常是问题已经发生或即将发生的明确信号。我们的“60秒清单”就是围绕这三个维度设计的。在登录服务器的第一分钟你需要像扫描仪一样快速收集这些核心资源的USE指标。这能帮你迅速回答几个关键问题系统整体负载如何瓶颈可能出现在哪个资源上是CPU算力不足还是内存吃紧或是磁盘I/O卡顿有没有发生严重的错误有了这些初步判断你才能决定下一步是去分析Java应用的GC日志还是去检查数据库的慢查询抑或是去排查网络链路的稳定性。注意以下部分命令如mpstat,pidstat,iostat,sar来自sysstat工具包。在大多数Linux发行版上你可以通过yum install sysstatRHEL/CentOS或apt-get install sysstatUbuntu/Debian来安装。建议在系统构建阶段就预先安装好这个工具包避免在故障排查时手忙脚乱。3. 黄金60秒十大命令详解与实战解读现在让我们进入实战环节。假设你刚刚连接到一台疑似存在性能问题的生产服务器。请按顺序或根据直觉并行执行以下命令。为了获得动态视图多数命令我们使用1作为参数表示每秒刷新一次。3.1 全局概览uptime– 系统负载的“第一印象”命令与输出示例$ uptime 23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02解读与实战技巧uptime可能是所有命令中最简单也最富含信息的一个。它输出的最后三个数字——系统平均负载Load Average——是理解系统整体压力的钥匙。它是什么平均负载表示的是系统中处于可运行状态正在使用CPU或等待使用CPU和不可中断状态通常是在等待磁盘I/O的平均进程数。注意它不是一个百分比而是一个数量。三个数字的含义分别代表过去1分钟、5分钟、15分钟的平均值。这三个值构成的趋势至关重要。如何分析看绝对值与CPU核心数的关系一个粗略但有效的经验法则是如果平均负载持续高于CPU逻辑核心数就可能存在CPU资源饱和。例如一台4核机器负载长期在8以上肯定有问题。上例中的30.02无论多少核都高得吓人。看趋势关键比较1分钟、5分钟、15分钟的值。1分钟值远高于15分钟值如 30.02 vs 19.02说明负载在近期急剧上升问题可能正在发生或刚刚发生。这是需要立刻警惕的信号。1分钟值远低于15分钟值可能意味着一个高负载事件已经过去你来得有点晚需要依赖历史日志分析了。三个值都高且平稳说明系统长期处于高负载状态需要优化。它能告诉你什么uptime给出了一个关于系统饱和度的顶级视图。高负载意味着有进程在排队等待资源CPU或I/O。但它不能告诉你具体是CPU饱和还是I/O饱和。这是后续命令如vmstat要解决的问题。实操心得我习惯在登录任何服务器的第一时间运行uptime。如果负载看起来正常我会稍微松一口气如果数字异常我会立刻进入战斗状态并根据负载趋势决定下一步排查的紧迫性。3.2 内核日志速览dmesg | tail– 捕捉致命错误的“黑匣子”命令与输出示例$ dmesg | tail [1880957.563] Out of memory: Kill process 18694 (java) score 511 or sacrifice child [1880957.567] Killed process 18694 (java) total-vm:2532680kB, anon-rss:1416508kB, file-rss:0kB [1880980.322] TCP: Possible SYN flooding on port 8080. Sending cookies.解读与实战技巧dmesg显示的是内核环形缓冲区中的消息。这些消息往往记录了系统底层发生的重大事件很多性能问题在这里会留下直接的“罪证”。关注什么OOMOut-Of-Memory杀手记录如上例第一行。这是最严重的信号之一表明物理内存和交换空间都已耗尽内核被迫杀死一个或多个进程来释放内存。如果你看到这个内存问题就是当前的主要矛盾。硬件错误磁盘I/O错误、CPU纠正错误等。网络异常TCP丢包、连接溢出如SYN flooding等警告。文件系统错误EXT4/JFS/Btrfs等文件系统报告的错误。为什么用tail因为缓冲区可能很大我们只关心最近发生的、最可能相关的事件。有时我也会用dmesg | tail -20多看几行。时间戳解读方括号[1880957.563]里的数字是系统启动后的秒数。你可以用date -d $(awk {print $1} /proc/uptime)来估算系统启动的绝对时间从而判断错误发生的大致时刻。注意事项dmesg的输出可能被配置了速率限制一些非关键信息可能不会显示。如果怀疑有更早的关键错误可以尝试dmesg | grep -E -i “(oom|kill|error|fail|tcp drop)”进行过滤搜索。3.3 系统资源全景图vmstat 1– 虚拟内存与CPU状态的动态监控命令与输出示例$ 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 6 2 24580 15232 3200 1024000 0 0 0 12 450 890 65 10 20 5 0 12 1 24580 8432 3200 1024500 1 0 1024 256 980 1200 70 15 10 5 0解读与实战技巧vmstat 1每秒输出一行提供了一个关于进程、内存、交换区、I/O和CPU的实时、动态的全景视图。请忽略第一行自启动以来的平均值从第二行开始看实时数据。我们按列分组解读Procs进程r运行队列长度。等待CPU资源的可运行进程数。这是CPU饱和度的关键指标。如果r的值持续大于CPU逻辑核心数说明CPU已经饱和进程在排队。上例中r在6到12之间波动如果这是台4核机器饱和度就很高。b 处于不可中断睡眠状态的进程数通常是在等待I/O如磁盘I/O。如果这个值持续大于0可能意味着I/O是瓶颈。Memory内存swpd 已使用的虚拟内存交换分区大小。如果这个值不为0且在增长结合后面的si/so看是内存不足的信号。free 空闲的物理内存。在Linux中这个值小不一定有问题因为系统会利用空闲内存做缓存cache和buff。buff/cache 用于缓冲区缓存和页面缓存的内存。这部分内存可以被应用程序快速回收。Swap交换si 每秒从磁盘交换区读入到内存的数据量kB。so 每秒从内存写入到磁盘交换区的数据量kB。这是关键只要si或so持续为非零值哪怕很小就说明系统正在发生交换swapping。由于磁盘速度远慢于内存交换会带来严重的性能下降。这是内存瓶颈的明确信号。I/O块设备bi 每秒从块设备接收的块数blocks in。bo 每秒发送到块设备的块数blocks out。这两个值反映了磁盘I/O的负载。但更详细的I/O分析需要iostat。System系统in 每秒的中断数。cs 每秒的上下文切换次数。异常高的中断或上下文切换可能意味着不合理的进程调度或硬件问题。CPU处理器 – 最重要的部分之一us 用户态进程占用CPU时间百分比。sy 内核态系统占用CPU时间百分比。id CPU空闲时间百分比。wa CPU等待I/O的时间百分比。st 被虚拟化环境如VMware Xen“偷走”的时间百分比对于物理机或大多数云主机通常为0。分析模式us sy高如 80%CPU繁忙。如果us很高通常是应用代码问题如果sy很高如持续 20%可能系统调用频繁或内核处理I/O效率低。wa高CPU花费大量时间等待I/O。这是I/O瓶颈的强烈指示。此时id空闲可能很低但CPU并非忙于计算而是在“空等”。上例中wa为5%需要结合iostat进一步确认磁盘是否真的饱和。id高CPU空闲。但如果此时r运行队列也高则可能是进程在等待锁或其他资源而非CPU。实操心得vmstat 1是我在怀疑系统资源问题时必看的“仪表盘”。我会同时开一个终端窗口运行它观察几秒到十几秒的动态变化。重点关注r,b,si/so,wa这几列的趋势。一个稳定的高wa配上增长的b几乎可以断定是磁盘I/O问题。3.4 CPU核心负载均衡洞察mpstat -P ALL 1– 发现单核热点命令与输出示例$ mpstat -P ALL 1 Linux 5.4.0-... 04/10/2024 _x86_64_ (8 CPU) ... 05:30:01 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 05:30:02 PM all 70.12 0.00 15.25 4.63 0.00 0.12 0.00 0.00 0.00 9.88 05:30:02 PM 0 98.00 0.00 2.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 05:30:02 PM 1 10.00 0.00 90.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 05:30:02 PM 2 65.00 0.00 30.00 5.00 0.00 0.00 0.00 0.00 0.00 0.00 ...解读与实战技巧mpstat是vmstat中CPU数据的多核详细版。-P ALL表示报告所有CPU核心的统计1表示每秒刷新。核心价值发现负载不均衡。在多核系统中整体CPU使用率可能看起来不高比如all行显示%idle有9.88%但个别核心可能已经100%繁忙。这通常是单线程应用或锁竞争激烈的典型表现。上例中CPU 0 的%usr高达98%而CPU 1 的%sys高达90%说明有两个不同的瓶颈点一个在用户态计算一个在内核态系统调用。字段解读与vmstat类似但更细%usr 用户态。%sys 内核态。%iowait 等待I/O。%irq/%soft 处理硬件/软件中断的时间。%idle 空闲。如何行动如果发现某个核心持续100%繁忙而其他核心空闲下一步就应该用pidstat或top找出是哪个进程的哪个线程绑在了这个核心上然后分析该进程的代码或配置。3.5 进程级CPU消耗追踪pidstat 1– 定位“罪魁祸首”命令与输出示例$ pidstat 1 Linux 5.4.0-... 04/10/2024 _x86_64_ (8 CPU) 05:32:01 PM UID PID %usr %system %guest %wait %CPU CPU Command 05:32:02 PM 1001 12345 1250.00 350.00 0.00 0.00 1600.00 3 java 05:32:02 PM 1001 23456 15.00 5.00 0.00 1.00 20.00 1 nginx解读与实战技巧pidstat像是一个动态的、进程级别的top但它以滚动方式输出更便于记录和观察趋势。默认显示CPU使用情况。关键列%CPU 该进程使用的总CPU百分比。注意这是所有CPU核心的占用总和因此可以超过100%。一个进程占用1600%的CPU意味着它平均使用了16个核心的算力。上例中的Java进程就是如此这是一个典型的CPU密集型或多线程应用。%usr/%system 进程在用户态/内核态的CPU使用率。CPU 该进程最近一次运行所在的核心编号。结合mpstat可以验证热点进程是否集中在某个核心。进阶用法pidstat -d 1 查看进程的磁盘I/O统计。pidstat -r 1 查看进程的内存统计如常驻集大小RSS、缺页异常。pidstat -w 1 查看进程的上下文切换情况。实战流程当vmstat或mpstat显示CPU使用率高时立刻运行pidstat 1通常能在前几行迅速定位到消耗CPU最多的进程。这是从系统层面定位到具体应用层面的关键一步。3.6 磁盘I/O性能深度剖析iostat -xz 1– 定位存储瓶颈命令与输出示例$ iostat -xz 1 Linux 5.4.0-... 04/10/2024 _x86_64_ (8 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 65.12 0.00 10.25 15.63 0.00 9.00 Device r/s w/s rkB/s wkB/s await r_await w_await aqu-sz %util vda 0.00 250.00 0.00 20480.00 120.50 0.00 120.50 15.20 99.80解读与实战技巧iostat是分析块设备磁盘性能的利器。-x显示扩展统计-z省略在采样期间没有活动的设备让输出更简洁。关键指标解读r/s,w/s 每秒向设备发起的读/写请求数IOPS。rkB/s,wkB/s 每秒读/写的数据量吞吐量。await 每个I/O请求的平均等待时间毫秒。这是衡量磁盘响应速度、影响应用性能的直接指标。它包括请求在队列中的排队时间和服务时间。通常机械硬盘的await应低于20msSSD应低于5ms。上例中的120.5ms非常高。r_await,w_await 分别针对读和写的平均等待时间。aqu-sz 平均请求队列长度。如果大于1说明设备可能已经饱和请求开始堆积。%util设备利用率即设备忙于处理I/O请求的时间百分比。对于单块磁盘如果持续接近100%通常意味着磁盘已饱和是性能瓶颈。但请注意一个重要的例外对于由多块磁盘组成的RAID阵列或逻辑卷LVM%util达到100%可能只意味着部分底层磁盘繁忙而其他磁盘可能还有余力。此时需要结合await和aqu-sz判断。分析模式高%util 高await 高aqu-sz 经典的磁盘I/O饱和现象。应用性能会因I/O等待而严重下降。高%util 低await 磁盘处理能力良好请求能被快速处理。这可能不是问题。低%util 高await 这可能意味着磁盘本身有问题如即将故障或者文件系统、驱动程序存在问题导致单个请求服务时间异常长。结合vmstat的wa如果vmstat显示高waiostat就能告诉你具体是哪个磁盘设备导致的以及严重程度。注意事项云环境如AWS EBS中的磁盘性能有其特殊性通常有IOPS和吞吐量的突发额度与基线限制。当iostat显示性能不佳时也需要检查是否达到了云磁盘的性能上限。3.7 内存使用真相free -m与缓存机制命令与输出示例$ free -m total used free shared buff/cache available Mem: 7982 5120 132 100 2730 2450 Swap: 2047 200 1847解读与实战技巧free命令看内存新手和老手常常得出截然不同的结论关键在于理解Linux的内存管理机制。不要只看free列这是最常见的误区。Linux内核会充分利用未被应用程序使用的内存来缓存磁盘数据buff/cache以提升后续的读性能。因此free内存少是正常且良好的现象。关键看available列这个指标在较新内核中引入估算的是在不进行交换swap的情况下可供新应用程序使用的内存量。它考虑了free内存和可回收的缓存buff/cache。上例中虽然free只有132MB但available高达2450MB说明内存非常充足。关注Swap的使用。如果Swap的used持续增长或者free命令下方的si/so需结合vmstat不为零说明系统正在发生交换这是内存不足的明确信号会严重影响性能。关于buff/cachebuffers 主要用于缓存文件系统的元数据如目录结构、inode和缓存裸磁盘的块操作。cache 主要是页缓存Page Cache缓存文件的实际数据。当应用程序需要内存时这部分缓存可以被快速释放。所以它们本质上是“可用的”内存。一个经典陷阱有网站叫“Linux ate my RAM”专门解释这个现象。简单说内存用了才是赚了空闲着就是浪费。只要available内存充足buff/cache再大也不是问题。3.8 网络吞吐量观测sar -n DEV 1– 监控网络接口流量命令与输出示例$ sar -n DEV 1 Linux 5.4.0-... 04/10/2024 _x86_64_ (8 CPU) 05:35:01 PM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil 05:35:02 PM eth0 1250.00 800.00 10240.00 5120.00 0.00 0.00 5.00 0.80 05:35:02 PM lo 10.00 10.00 0.80 0.80 0.00 0.00 0.00 0.00解读与实战技巧sarSystem Activity Reporter是sysstat套件中的历史数据收集和报告工具但用1参数也可以做实时监控。-n DEV用于查看网络设备统计。关键指标rxkB/s,txkB/s 每秒接收/发送的千字节数。这是衡量网络吞吐量的核心指标。你需要知道你的网卡上限如1 Gbit/s ≈ 125 MB/s 10 Gbit/s ≈ 1.25 GB/s。上例中接收约10MB/s发送约5MB/s对于千兆网卡远未饱和。rxpck/s,txpck/s 每秒接收/发送的数据包数。异常高的包速率尤其是小包可能给CPU带来中断处理压力。%ifutil 网络接口利用率。这是一个理论上的最大值百分比但sar和大多数工具很难精确计算它有时显示为0.00。更准确的工具是nicstat但sar的rxkB/s/txkB/s已足够判断是否接近带宽上限。如何判断瓶颈如果rxkB/s或txkB/s持续接近网络接口的理论带宽并且应用表现出网络延迟那么网络带宽可能就是瓶颈。同时可以结合后面的TCP重传指标来看。3.9 TCP连接与重传监控sar -n TCP,ETCP 1– 洞察网络健康度命令与输出示例$ sar -n TCP,ETCP 1 Linux 5.4.0-... 04/10/2024 _x86_64_ (8 CPU) 05:36:01 PM active/s passive/s iseg/s oseg/s 05:36:02 PM 1.20 15.50 1250.00 1300.00 05:36:01 PM atmptf/s estres/s retrans/s isegerr/s orsts/s 05:36:02 PM 0.00 0.00 5.20 0.00 0.00解读与实战技巧这个命令专注于TCP层的指标对于网络服务如Web服务器、数据库的性能排查至关重要。关键指标解读active/s 每秒本地主动发起的TCP连接数客户端行为如connect()。passive/s 每秒远程发起的、本地接受的TCP连接数服务器行为如accept()。这两个数字可以粗略衡量服务器的新建连接压力。retrans/s 每秒TCP重传的段数。这是网络问题或服务器过载的黄金指标**。**非零的重传意味着数据包在网络上丢失或严重延迟或者服务器因过载而未能及时响应导致客户端超时重传。偶尔的重传在公网环境中是正常的但持续的重传如每秒几次以上就是严重问题。上例中5.20 retrans/s需要警惕。atmptf/s 每秒失败的TCP连接尝试数如超时。高数值可能意味着网络问题或对端服务不可用。estres/s 每秒从ESTABLISHED状态直接到CLOSED状态的连接数异常断开。实战应用当应用报告网络慢或连接超时时查看retrans/s。如果这个值很高问题很可能出在网络层面包括本地服务器因负载过高导致的“软”网络问题。如果重传率正常但应用依然慢就需要从应用层或更上层的协议如HTTP找原因了。3.10 交互式全局监控top/htop– 熟悉的“控制面板”命令解读top是大家最熟悉的工具它提供了一个动态更新的、交互式的系统进程视图。它整合了前面许多命令的信息系统负载load average、CPU使用率、内存使用情况以及详细的进程列表。优势与局限优势交互性强可以排序按CPU、内存、搜索、杀死进程。htop是其增强版界面更友好支持鼠标操作和树状视图。局限信息是瞬态的滚动刷新会清屏不利于观察趋势和记录历史数据。在快速变化的场景下容易错过关键瞬间。在60秒清单中的定位top或htop更适合在通过前述命令初步定位方向后进行深入的进程级交互式调查。例如用pidstat找到高CPU进程后用top查看该进程的更多细节如打开的文件、线程数或者用htop的树状模式查看进程父子关系。在最初的快速扫描阶段非交互的、持续滚动的命令如vmstat 1,pidstat 1往往更有效率因为你可以让它们持续运行并观察模式同时在一个单独的终端窗口执行其他命令。4. 组合拳实战典型性能问题排查流程与案例掌握了单个工具更重要的是学会在实战中组合使用它们。下面我通过两个常见的场景来演示如何在60秒内运用这套组合拳。4.1 场景一应用响应缓慢怀疑CPU或I/O问题第0-10秒全局健康检查uptime: 发现负载平均值很高如load average: 25.00, 20.00, 15.00且1分钟值高于15分钟值说明负载在上升。dmesg | tail: 快速扫一眼没有OOM或硬件错误。第11-30秒资源瓶颈定位vmstat 1: 观察几秒。发现r列运行队列数值持续远大于CPU核心数如r: 30且ussy超过90%但wa很低。初步判断CPU饱和。mpstat -P ALL 1: 确认是否所有核心都忙还是个别核心热点。发现所有核心%usr或%sys都很高说明是普遍性计算压力。第31-50秒定位元凶进程pidstat 1: 立刻看到某个Java或Python进程的%CPU列高达800%或更多。锁定进程PID。第51-60秒深入探查与决策top -p [PID]: 切换到top查看该进程的详细状态或者用htop查看其线程。可以按H查看线程模式确认是否是某个特定线程吃满CPU。结论与行动基本确定是某个应用进程CPU使用异常。接下来可以收集该进程的堆栈信息jstackfor Java,perf/pstackfor others、检查应用日志或者考虑临时重启该实例。4.2 场景二数据库查询超时怀疑磁盘或内存问题第0-10秒全局健康检查uptime: 负载高。dmesg | tail: 没有明显错误。第11-30秒资源瓶颈定位vmstat 1: 观察几秒。发现wa列I/O等待持续很高如wa: 40%id空闲很低但ussy不高。同时b列阻塞进程也有数值。初步判断I/O瓶颈。注意看si/so交换如果非零则内存不足加剧了I/O问题。第31-50秒细化I/O与内存分析iostat -xz 1: 确认是哪个磁盘设备%util接近100%且await很高如 100ms。假设是/dev/vdb。free -m: 查看available内存是否充足Swap used是否在增长。第51-60秒定位I/O发起者pidstat -d 1: 查看哪个进程对/dev/vdb的读写最频繁。很可能是数据库进程如mysqld,postgres。结论与行动确定是磁盘I/O瓶颈且可能由数据库大量读写导致。接下来需要登录数据库分析慢查询日志、检查索引、或者查看是否有全表扫描等操作。如果是云盘还需要检查是否达到了IOPS或吞吐量限制。5. 常见陷阱、进阶工具与排查心法5.1 新手常踩的坑与误区只看free内存惊呼“内存没了” 如前所述这是最大的误区。请认准available列。%util100% 就等于磁盘坏了 对于RAID或逻辑卷%util100% 可能只是部分磁盘忙。要结合await和aqu-sz判断。如果await依然很低说明阵列还能处理请求。负载高一定是CPU问题 负载高可能是CPU队列也可能是I/O等待队列不可中断进程。一定要用vmstat看r和b用iostat看await来区分。忽略单个核心的热点 整体CPU使用率不高但应用依然慢。可能是单个线程绑死在某个核心上mpstat能发现导致该核心上的任务排队。不关注趋势只看单点数据 性能问题往往是动态的。运行命令时一定要加间隔参数如1观察几秒到几十秒的变化趋势才能捕捉到间歇性的峰值或规律。5.2 60秒之后的武器库进阶性能工具简介最初的60秒是为了快速定位方向。一旦确定了怀疑对象就需要更专业的工具进行深度剖析CPU深度分析perf Linux内核自带的性能分析神器。可以做CPU性能计数器采样perf record/perf report生成火焰图精准定位热点函数。strace/ltrace 跟踪进程的系统调用或库函数调用适用于分析卡顿在哪个具体调用上。内存深度分析slabtop 查看内核slab缓存使用情况诊断内核内存泄漏。valgrind/AddressSanitizer 用于开发环境检测用户态程序的内存错误和泄漏。pmap 查看进程详细的内存映射。I/O深度分析iotop 类似top但针对磁盘I/O实时显示每个进程的I/O速率。blktrace/btt 块设备I/O的终极追踪工具可以分析I/O请求在块设备层的完整生命周期但比较复杂。网络深度分析nicstat 比sar -n DEV更精确地测量网络接口利用率。netstat -s或ss -s 查看丰富的TCP/UDP层统计信息。tcpdump/wireshark 抓包分析解决复杂的网络协议问题。全链路追踪BCC/bpftrace 基于eBPF的动态追踪工具集可以编写脚本对内核和用户态程序进行超低开销的深度观测功能极其强大是现代性能分析的标杆。5.3 性能排查心法像侦探一样思考最后分享几点我多年总结的心得假设驱动数据验证 不要瞎猜。先根据现象如“API延迟高”提出假设“可能是数据库慢”然后用工具收集数据去验证或推翻它。自上而下逐层排查 从宏观负载、整体资源到微观具体进程、线程、函数。USE方法就是很好的自上而下框架。对比基线关注变化 了解系统在正常状态下的指标基线至关重要。很多问题表现为指标的“异常变化”而非绝对值。一次只变一个变量 在尝试优化或修改配置时避免同时改变多个参数否则你无法知道是哪个改动生效了。日志是你的朋友 系统命令告诉你“是什么”应用日志和错误日志往往能告诉你“为什么”。永远不要忽略/var/log/下的相关日志。这套“60秒性能检查清单”是我工具箱里最常用、最可靠的一部分。它不能解决所有问题但能确保你在面对一台陌生的问题服务器时不会手足无措而是能像经验丰富的侦探一样在最短时间内找到最有价值的线索为后续的深度排查打开突破口。记住工具是死的思路是活的。将这些命令和USE方法论内化形成你的肌肉记忆和条件反射你就能在每一次性能危机中抢得至关重要的先机。
