2026/9/20 16:57:26
FEATURED · 精选文章 
先说个真实场景某天线上服务突然变慢接口耗时从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的比例值得深挖。ususer space高说明是应用业务逻辑在消耗CPUsysystem space高说明是内核态在消耗CPU。两者比例大于3:1算健康sy占比过高往往意味着频繁系统调用、上下文切换或者内核锁竞争。waiowait反映磁盘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核数代表有进程在排队等CPUb表示阻塞进程数常在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显示的是KiBfree默认也是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/Opidstat -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 traceread,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-10dirty_ratio控制在20-30。5. 调用链层工具perf与strace的核心逻辑前两层锁定进程后最后一步是深入进程内部找热点函数和系统调用。这层的工具最有门槛但也最有价值。5.1 strace恶心的工具但关键时刻救命strace跟踪进程的系统调用能告诉你进程在执行什么操作。常用参数-p PID附加到进程-e tracenetwork只看网络相关调用-e tracefile只看文件操作-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, mpstatus/sy, per-core使用率pidstat, perf内存瓶颈free, vmstatsi/so, swap使用pidstat -r, sar -r磁盘I/Oiostat -x%util, await, svctmpidstat -d, lsof网络瓶颈sar -n DEV, ss重传率, 连接数nethogs, iftop上下文切换vmstat, pidstat -wcs, cswch/nvcswchperf sched这张表的逻辑就是前面反复强调的三层框架资源层→进程层→调用链层。每一类问题从最左边工具入手按需往右推进。7.4 安全边缘工具对生产环境的影响perf和strace这类工具在某些场景会影响业务必须在变更窗口或者压测环境操作。bpftrace设计上对生产影响很小但脚本写错也可能造成内核事件风暴。我给自己定了一条规矩重工具必须走变更流程先在小流量节点验证。在性能工具的工具箱里最贵的永远不是工具本身而是错误操作带来的二次故障。7.5 排查性能问题的心态性能问题容易让人焦虑特别是线上故障时。但越急越容易乱乱操作往往加重问题。我给自己定的排查SOP是先看历史数据压住时间范围再逐层排除资源类型锁进程最后才深入进程内部。每完成一步都记录结果而不是凭感觉跳来跳去。8. 写在最后工具之外的功力大概两年前我花了一个周末研究perf和bpftrace的用法感觉掌握了新技能。后来真到线上用的时候才发现最难的不是命令语法而是判断“现在该用哪个工具、怎么解读这个数字”。工具是术排查思路才是道。把资源层、进程层、调用链层这套框架理解透、用熟练比记住一百个命令都管用。当前也是在踩过无数次坑之后才总结出来的。比如曾经在一次故障里我盯着top看了十分钟没看出问题后来冷静下来跑了一次sar -d才找到磁盘根源。那次之后我再也不提倡“只凭肉眼观察top”而是坚持用数据说话。希望这些经验能为刚入门性能调优的朋友节省一些弯路。Linux性能分析不是一个“学会”的动作而是一个持续积累的过程。把基础工具用透把排查逻辑理顺遇到新问题时不慌不忙按流程走——你也能从“看到CPU高就重启”进阶到“三分钟定位根因”。
Linux性能分析实战：三层框架与工具使用指南
先说个真实场景某天线上服务突然变慢接口耗时从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的比例值得深挖。ususer space高说明是应用业务逻辑在消耗CPUsysystem space高说明是内核态在消耗CPU。两者比例大于3:1算健康sy占比过高往往意味着频繁系统调用、上下文切换或者内核锁竞争。waiowait反映磁盘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核数代表有进程在排队等CPUb表示阻塞进程数常在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显示的是KiBfree默认也是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/Opidstat -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 traceread,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-10dirty_ratio控制在20-30。5. 调用链层工具perf与strace的核心逻辑前两层锁定进程后最后一步是深入进程内部找热点函数和系统调用。这层的工具最有门槛但也最有价值。5.1 strace恶心的工具但关键时刻救命strace跟踪进程的系统调用能告诉你进程在执行什么操作。常用参数-p PID附加到进程-e tracenetwork只看网络相关调用-e tracefile只看文件操作-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, mpstatus/sy, per-core使用率pidstat, perf内存瓶颈free, vmstatsi/so, swap使用pidstat -r, sar -r磁盘I/Oiostat -x%util, await, svctmpidstat -d, lsof网络瓶颈sar -n DEV, ss重传率, 连接数nethogs, iftop上下文切换vmstat, pidstat -wcs, cswch/nvcswchperf sched这张表的逻辑就是前面反复强调的三层框架资源层→进程层→调用链层。每一类问题从最左边工具入手按需往右推进。7.4 安全边缘工具对生产环境的影响perf和strace这类工具在某些场景会影响业务必须在变更窗口或者压测环境操作。bpftrace设计上对生产影响很小但脚本写错也可能造成内核事件风暴。我给自己定了一条规矩重工具必须走变更流程先在小流量节点验证。在性能工具的工具箱里最贵的永远不是工具本身而是错误操作带来的二次故障。7.5 排查性能问题的心态性能问题容易让人焦虑特别是线上故障时。但越急越容易乱乱操作往往加重问题。我给自己定的排查SOP是先看历史数据压住时间范围再逐层排除资源类型锁进程最后才深入进程内部。每完成一步都记录结果而不是凭感觉跳来跳去。8. 写在最后工具之外的功力大概两年前我花了一个周末研究perf和bpftrace的用法感觉掌握了新技能。后来真到线上用的时候才发现最难的不是命令语法而是判断“现在该用哪个工具、怎么解读这个数字”。工具是术排查思路才是道。把资源层、进程层、调用链层这套框架理解透、用熟练比记住一百个命令都管用。当前也是在踩过无数次坑之后才总结出来的。比如曾经在一次故障里我盯着top看了十分钟没看出问题后来冷静下来跑了一次sar -d才找到磁盘根源。那次之后我再也不提倡“只凭肉眼观察top”而是坚持用数据说话。希望这些经验能为刚入门性能调优的朋友节省一些弯路。Linux性能分析不是一个“学会”的动作而是一个持续积累的过程。把基础工具用透把排查逻辑理顺遇到新问题时不慌不忙按流程走——你也能从“看到CPU高就重启”进阶到“三分钟定位根因”。 
