先说个真实场景：某天线上服务突然变慢，接口耗时从50ms涨到5秒，CPU跑满，但没人知道瓶颈在哪。我看过太多人这时候打开top扫一眼，看到某个进程CPU高就直接kill重启，反反复复好几天解决不了问题。不是top不好用，是没搞懂性能分析的正确打开方式。
这篇东西写给我自己，也写给所有被Linux性能问题折磨过的工程师。我不是要把man page抄一遍，而是想把我在生产环境里真正用得上、能解决实际问题的分析工具和排查思路整理出来。适合刚接触Linux性能调优的运维和开发，也能给有一定基础但没形成方法论的同行一些参考。核心就一句话：工具不在多，关键在于知道每类工具解决什么问题、什么时候用哪个、输出的指标怎么解读。
在开始之前，想明确一点：性能调优这件事，本质上是在回答三个问题——瓶颈在哪个资源、瓶颈由谁产生、为什么会产生。所有的工具都是围绕这三个问题展开的。带着这个思路看下去，你会发现工具之间的逻辑关系很清晰，而不是一堆命令的堆砌。
1. 先搞清楚性能分析的三个层次：资源、进程、调用链
很多人一上来就铺开一堆工具，今天学top明天学perf，学完还是不会排查问题。核心原因是没建立正确的分析框架。我自己的经验是，性能分析必须分层，每层用不同的工具，每层回答不同的问题。
1.1 资源层：机器到底缺什么
第一层是资源层，回答“瓶颈在哪个硬件资源”。一台Linux服务器对外提供服务，本质是CPU、内存、磁盘I/O、网络I/O这四类资源在支撑。任何性能问题的表象，最终都能归结到某类资源耗尽或分配不合理。
判定方法很简单：如果CPU使用率长期高于70%，先怀疑CPU瓶颈；如果内存使用率到了swap阈值，先怀疑内存；如果iowait持续偏高，先怀疑磁盘；如果网络重传率高，先怀疑网络。这个层次用到的工具是最基础的：top、vmstat、iostat、sar、free、mpstat。这些工具能快速缩小排查范围，告诉你“病”在哪个器官，但说不清病因。
1.2 进程层：是谁在消耗资源
第二层定位到具体进程，回答“瓶颈由谁产生”。资源层知道CPU满了，但你看不到是哪个进程把CPU吃满的，也不知道这个进程在做什么操作。这时候需要用pidstat、top的进程视图、ps辅助定位。
这一层的关键是理解进程和资源的关系。同一个进程可能同时消耗多种资源，比如高CPU伴随高频磁盘读写，那就要看是计算密集还是I/O密集。结合资源层的数据，基本能锁定嫌疑进程。
1.3 调用链层：进程在干什么导致瓶颈
第三层深入进程内部，回答“为什么会产生瓶颈”。锁定进程后，需要知道这个进程在哪个函数、哪个系统调用上耗时最多。这个层次的工具是strace、perf、gdb、bpftrace。它们能看到程序执行的具体路径，定位到代码级别的热点。
三层缺一不可。跳过第一层直接上perf，你会发现面对海量输出无从下手；停在第二层不深入第三层，你只能杀掉进程重启，解决不了根本问题。下面的内容，我按照这个框架逐一展开每个层的工具和用法。
2. 资源层工具实战：top、vmstat、iostat、sar的用法与指标解读
2.1 top的"20秒体检法"
top是接触最多的工具，但不是每个人都会用。多数人看top只看一眼CPU和内存占用率就完事，这远远不够。我自己习惯的节奏是：进入top界面后，连续观察20秒到1分钟，重点关注几个容易被忽略的细节。
负载均值（load average）要结合CPU核数判断，不是看到1.0就觉得正常。单核机器负载1.0等于跑满，但四核机器负载4.0才算满。负载值长期高于核数，说明任务排队严重，反应用户感知就是卡顿。
us与sy的比例值得深挖。us（user space）高说明是应用业务逻辑在消耗CPU；sy（system space）高说明是内核态在消耗CPU。两者比例大于3:1算健康，sy占比过高，往往意味着频繁系统调用、上下文切换或者内核锁竞争。
wa（iowait）反映磁盘I/O等待。wa高说明CPU在等待磁盘，通常是磁盘I/O瓶颈的信号。注意wa是“等待”而非“忙碌”，它代表CPU空闲但被迫等待I/O完成。
按1键切换到多核视图，看单个核心是否跑满。有些场景整体CPU不高，但某个核心满载，这通常是单线程热点问题，应用层看不到完整的多核利用率。按x高亮排序列，按M按内存排序、按P按CPU排序，快速切换视角。
top的字段里，RES是物理内存占用，SHR是共享内存，S是进程状态（R运行、S睡眠、D不可中断）。特别提一下D状态，这种状态的进程在做磁盘I/O且不可被打断，大量D状态进程往往伴随iowait飙升，是I/O瓶颈的典型信号。
2.2 vmstat：系统整体状态一屏看全
vmstat的输出比top更适合做趋势判断。最常敲的命令是vmstat 2 5，表示每2秒采样一次共5次。第一行是启动以来的平均值，后面每行是实际的采样值，分析时看第一行之外的记录。
关键看几个列：r表示运行队列中进程数，持续大于CPU核数代表有进程在排队等CPU；b表示阻塞进程数，常在I/O等待时升高；swpd是交换分区使用量，不等于0不一定有问题，但持续增长就要警惕；si和so是每秒换入换出内存量，这两个数值只要不为0基本能判断内存已经不够用了；cs是每秒上下文切换次数，这个值过高说明系统调度频繁，需要进一步分析是线程过多还是锁竞争。
我曾遇到过一个Java应用，cs列长期在几万的水平，后来用pidstat定位到是线程池开得过大，大量线程在无意义地切换。调整线程池参数后，性能提升非常明显。
2.3 iostat：磁盘I/O能力的量化分析
磁盘I/O瓶颈容易被忽视，因为很多性能问题表象是CPU高或响应慢，根因却是磁盘拖后腿。iostat -x 1展开扩展统计信息，信息量很大。
%util是设备繁忙程度，接近100%说明磁盘已经很忙了。但要明确一点，%util高不一定等于磁盘性能差，还要结合await（平均I/O响应时间）来看。如果%util高且await也高（比如超过20ms），磁盘大概率是真瓶颈；如果%util高但await很低，可能只是I/O请求非常密集，磁盘本身还能吃得住。
r/s和w/s分别对应每秒读请求数和写请求数，rkB/s和wkB/s是吞吐量。这里有一个常见误区：很多人只盯着吞吐量看，忽略了IOPS（每秒I/O次数）。对于大量小文件的随机读写场景，IOPS比吞吐量更关键；而顺序大文件读写时吞吐量才有参考意义。
2.4 sar：历史性能数据的"回放机"
sar是这套工具链里最被低估的一个。它不仅能监控当前状态，还能通过sar命令回溯历史数据。前提是sysstat包安装后，cron会定时采集数据到/var/log/sa/目录。
排查线上问题时，问题往往已经发生了，来不及开监控。sar就是这时候的救星：sar -u -f /var/log/sa/sa$(date +%d)查看今天的CPU记录，sar -r看内存，sar -d看磁盘，sar -n DEV看网络流量。配合-s 10:00 -e 12:00指定时间范围，精确复现故障时刻的系统状态。
我最常用的是sar -q看历史load average和运行队列，用来判断故障什么时候开始、持续了多久。再结合sar -n DEV看同一时段的网络流量，基本能还原一个故障的全貌。
2.5 资源层的选型逻辑
这层工具很多，我的选择逻辑很简单：临时排查用top和vmstat交互式观察，回溯分析用sar，深度I/O分析用iostat，内存专项排查用free。工具的输出维度侧重点各不相同，但核心是快速判断哪类资源告急。还有个小技巧：各个工具的默认单位不同，top显示的是KiB，free默认也是KiB，但现代版本可以用free -h看人类可读格式，iostat默认是KB/s，这些单位坑会误导判断，用之前先确认单位。
3. 进程层工具：pidstat定位"元凶"
资源层锁定了瓶颈资源，下一步要找到消耗这个资源的进程。这一层的主角是pidstat，它比top的优势在于可以按进程维度输出历史统计，方便做时间维度的对比分析。
3.1 pidstat的日常用法
pidstat 1默认输出所有进程的CPU使用情况，每1秒刷一次。想单独看某个进程加-p PID。pidstat -r 1看内存，pidstat -d 1看磁盘I/O，pidstat -w 1看上下文切换。
我最常用的组合是pidstat -u -d -w 1，一个命令同时监控CPU、磁盘I/O和上下文切换，快速判断进程是CPU密集、I/O密集还是锁竞争激烈。
这里要插一个很重要的知识点：pidstat输出的CPU使用率是平均值，会掩盖瞬间峰值。遇到间歇性CPU飙高的问题，可以用短间隔采样，比如pidstat -u -p 1234 1 100采样100次，再把输出重定向到文件分析峰值。但更精细的定位还是要靠perf那一层工具。
3.2 上下文切换的分析方法
pidstat -w输出的cswch/s是自愿上下文切换，nvcswch/s是非自愿上下文切换。两者含义不同：自愿切换是进程主动让出CPU（比如等待I/O或锁），非自愿切换是被系统强制抢占（比如时间片耗尽）。
非自愿切换过多，通常是线程数量多于CPU核心数，系统在频繁调度。自愿切换过多则要怀疑锁竞争或频繁的I/O等待。结合vmstat的cs列，能整体到局部地还原调度状况。
3.3 与top输出互为补充
top也能看到进程维度的CPU和内存，为什么还需要pidstat？区别在于top是交互式快照，适合即时观察；pidstat可以持续采样并输出日志，适合后续分析和脚本化处理。而且pidstat的-t参数按线程维度输出，定位多线程应用内部的单线程热点时比top更准确。
在排查Java应用问题时，我经常会把pidstat输出的线程PID，配合jstack转换成十六进制线程号，精确定位到出问题的业务线程。这是跨工具协作排查的一个典型例子，后面讲排查思路时还会提到。
4. I/O瓶颈深入：从iostat到进程再到文件的完整链路
I/O瓶颈是性能问题里最难定位的一类，因为I/O涉及的环节多：应用层读写、页缓存、块设备层、磁盘硬件。我从实践里摸索出的一套链路是这样的。
4.1 用iostat确认I/O瓶颈后，用pidstat定位进程
iostat -x 1发现%util接近100%、await过高，确认磁盘是瓶颈。接下来用pidstat -d 1找哪个进程在大量读写磁盘。
pidstat -d输出的kB_rd/s、kB_wr/s是进程的读写速率。这里有个常见误区：pidstat -d统计的是进程通过系统调用发起的I/O，不一定等于实际落到磁盘的量。因为有页缓存的存在，很多写操作先写到内存缓存就返回了。想看清真实落盘情况，需要进一步用iostat观察块设备层的wrkB/s对比。
4.2 找到进程后，如何定位它在读写哪个文件
这步比较棘手，传统做法是看/proc/PID/fd目录下的文件描述符，但动态变化的文件需要实时跟踪。更实用的工具是lsof加-p PID列出所有打开的文件，然后结合strace跟踪系统调用。
strace -p PID -e trace=read,write -f可以实时看到进程在读写的文件描述符，再配合/proc/PID/fdinfo对应的文件名。不过strace对性能有较大开销，生产环境慎用，更适合压测环境或问题已经严重到需要牺牲一点性能来诊断的场景。
4.3 还有一类特殊的I/O问题：页缓存与脏页回写
有时候磁盘看起来不忙（%util低），但性能就是上不去。这种场景要检查内存页缓存和脏页回写机制。/proc/meminfo里的Dirty字段记录待写回磁盘的脏页数量，如果长期很高，说明内存写压力大但磁盘回写跟不上。
调整/proc/sys/vm/dirty_ratio和dirty_background_ratio参数可以改善写性能，但参数设置不当会导致大量数据积压在内存，突然断电丢数据，调优时需要权衡，不能盲目调高。这里给一个参考：dirty_background_ratio一般建议5-10，dirty_ratio控制在20-30。
5. 调用链层工具：perf与strace的核心逻辑
前两层锁定进程后，最后一步是深入进程内部找热点函数和系统调用。这层的工具最有门槛，但也最有价值。
5.1 strace：恶心的工具，但关键时刻救命
strace跟踪进程的系统调用，能告诉你进程在执行什么操作。常用参数：-p PID附加到进程，-e trace=network只看网络相关调用，-e trace=file只看文件操作，-f跟踪子进程，-c统计各系统调用耗时和次数。
需要说清楚strace的坑：它会把进程的执行速度拖慢数倍甚至一个数量级，生产环境使用要非常谨慎。我见过一次线上服务因为有人strace -p挂上去，本来能撑住的流量直接被打崩。所以我的原则是：strace只在测试环境用，或者线上已经故障到不可用、不在乎再慢一点的时候才用。
用strace排查的一个经典案例：某个服务间歇性卡顿，用strace -p PID -c跑几秒，发现futex调用次数异常多，结合调用栈判断是线程池锁竞争。最终优化了锁粒度，问题解决。这个案例让我意识到，性能工具的价值不在于高端，而在于理解和用对。
5.2 perf：采样式性能剖析器
perf是Linux内核自带的性能剖析工具，核心工作原理是基于硬件性能计数器的采样。它不需要修改程序代码，以固定频率中断正在执行的CPU，记录当前执行到哪个函数，最终统计出每个函数的采样占比。
最常用的命令是perf top交互式查看实时热点函数，类似于top的界面风格。perf record -p PID -g -- sleep 30采集30秒数据并记录调用栈，perf report查看分析报告。-g参数开启调用栈采集，这步很关键，它把问题定位从“这个函数占用CPU高”推进到“从哪个调用来路径到达这个函数”，你能看到完整调用链。
perf的威力在于能看到用户态和内核态的调用栈，不像strace只盯系统调用。实际使用中常见的热点类型：
- 用户态函数热点：说明业务代码有CPU密集计算或有锁竞争
- 内核态函数热点：可能是频繁的系统调用、内存分配、中断处理
- 缓存未命中：说明数据访问模式对CPU缓存不友好
perf report里还有一个--children选项，展示包含子函数调用的累计占比。排查一个错误印象：某个函数自身CPU占比不高，但加上它调用的所有子函数后占比很高，那这个函数才是你应该优化的入口。
5.3 动态追踪工具：更现代的I/O分析与热点定位
perf和strace之外，动态追踪工具正在成为新宠，典型代表是bcc和bpftrace。它们基于内核的eBPF技术，可以在生产环境安全地注入观测代码，几乎没有性能损耗。
比如用bcc的filetop工具可以实时查看哪些文件被大量读写，biotop看清BIO请求的进程分布，bpftrace脚本则可以根据需要定制观测逻辑。对传统工具难以定位的场景——比如大量短连接、短生命周期进程——效果极佳。
写一段简单的bpftrace示例，统计各进程打开文件的次数：
bpftrace -e 'tracepoint:syscalls:sys_enter_openat { @[comm] = count(); }'这类工具的学习曲线很陡，但性价比确实高，值得投入时间。不过我的建议是先把前两层的工具用熟、形成排查方法论，再考虑进阶到eBPF这一层。
6. 实战排查案例：一次完整的性能分析过程
讲了这么多工具，我用一个实际案例把整个分析链路串起来。这个案例很典型，能直观看到工具怎么配合使用。
6.1 现象：服务响应变慢，但负载看起来不高
某应用在业务高峰期响应时间突然增加，开发反馈“CPU不高、内存也不高，不知道瓶颈在哪”。我先用sar -q -f /var/log/sa/sa$(date +%d) -s 14:00 -e 14:30查了负载，发现load average在高峰期确实不高，但sar -d显示对应时段的磁盘util从平时20%涨到了85%。
初步判断是磁盘I/O瓶颈。接着用pidstat -d 1实时观察，发现有个日志进程每秒写200MB以上的数据。顺藤摸瓜排查，发现这个日志进程在写一个不断增长的日志文件，原来的日志轮转配置失效了，导致单文件持续增大、写入效率下降。
6.2 进一步深挖：为什么日志写入会拖慢整个服务
定位到具体文件和进程后，我看了磁盘的iostat输出，await已经到了40ms，远超正常值。这说明磁盘本身已经跟不上写入节奏了。
进一步用iostat -x 1看每个磁盘设备，发现数据盘和日志盘共用同一个物理磁盘。日志疯狂写入拖累了数据盘的正常读写，导致应用数据库查询变慢。
6.3 解决方案与复盘
解决方案很直接：把日志目录迁移到单独的磁盘，同时修复日志轮转配置。迁移完成后，磁盘util降回20%，服务响应时间恢复。
这个案例没有用perf、strace那些“高级”工具，只用了sar、iostat、pidstat就解决问题。我的感受是：性能调优，很多时候不是缺乏高级手段，而是基础工具没用好，排查链路不清晰。先看历史数据缩小范围，再实时定位进程，最后确认根因，这套思路比工具本身更重要。
7. 调优经验总结与工具使用心得
最后分享一些我在生产环境里积累的经验和教训。
7.1 数据采集比分析更重要
凡是经手过的线上问题，不管是当时就解决的还是事后复盘，我都会确保有监控数据可以回溯。有人说“等出了问题再开监控来不及”，所以现在很多公司会默认开启sysstat采集。我个人的做法是，新上线的服务器第一件事就是确保sysstat服务正常运行，同时配置好监控告警。没有数据，再厉害的工具也等于零。
7.2 都是高CPU，原因可能完全不同
同样是CPU跑满，可能是死循环、可能是GC频繁、可能是锁等待、可能是内存分配过多。我们不能看到CPU高就直接杀进程。分析时至少要把us和sy分开，再结合上下文切换等辅助指标一起看。这个习惯帮我避过很多坑。
7.3 工具组合常见配置
给一个我自己常用的命令速查表：
| 问题类型 | 首选工具 | 关键指标 | 辅助工具 |
|---|---|---|---|
| CPU瓶颈 | top, mpstat | us/sy, per-core使用率 | pidstat, perf |
| 内存瓶颈 | free, vmstat | si/so, swap使用 | pidstat -r, sar -r |
| 磁盘I/O | iostat -x | %util, await, svctm | pidstat -d, lsof |
| 网络瓶颈 | sar -n DEV, ss | 重传率, 连接数 | nethogs, iftop |
| 上下文切换 | vmstat, pidstat -w | cs, cswch/nvcswch | perf sched |
这张表的逻辑就是前面反复强调的三层框架：资源层→进程层→调用链层。每一类问题从最左边工具入手，按需往右推进。
7.4 安全边缘：工具对生产环境的影响
perf和strace这类工具在某些场景会影响业务，必须在变更窗口或者压测环境操作。bpftrace设计上对生产影响很小，但脚本写错也可能造成内核事件风暴。我给自己定了一条规矩：重工具必须走变更流程，先在小流量节点验证。在性能工具的工具箱里，最贵的永远不是工具本身，而是错误操作带来的二次故障。
7.5 排查性能问题的心态
性能问题容易让人焦虑，特别是线上故障时。但越急越容易乱，乱操作往往加重问题。我给自己定的排查SOP是：先看历史数据压住时间范围，再逐层排除资源类型，锁进程，最后才深入进程内部。每完成一步都记录结果，而不是凭感觉跳来跳去。
8. 写在最后：工具之外的功力
大概两年前，我花了一个周末研究perf和bpftrace的用法，感觉掌握了新技能。后来真到线上用的时候才发现，最难的不是命令语法，而是判断“现在该用哪个工具、怎么解读这个数字”。工具是术，排查思路才是道。把资源层、进程层、调用链层这套框架理解透、用熟练，比记住一百个命令都管用。
当前，也是在踩过无数次坑之后才总结出来的。比如曾经在一次故障里，我盯着top看了十分钟没看出问题，后来冷静下来跑了一次sar -d才找到磁盘根源。那次之后我再也不提倡“只凭肉眼观察top”，而是坚持用数据说话。
希望这些经验能为刚入门性能调优的朋友节省一些弯路。Linux性能分析不是一个“学会”的动作，而是一个持续积累的过程。把基础工具用透，把排查逻辑理顺，遇到新问题时不慌不忙按流程走——你也能从“看到CPU高就重启”进阶到“三分钟定位根因”。
