Linux性能监控工具：sar、iotop与perf使用全解析

一分耕耘，一分收获！既然都打开这篇《Linux性能监控工具详解：sar、iotop与perf使用指南》，就坚持看下去，学下去吧！本文主要会给大家讲到等等知识点，如果大家对本文有好的建议或者看到有不足之处，非常欢迎大家积极提出！在后续文章我会继续更新文章相关的内容，希望对大家都有所帮助！

1.sar、iotop和perf是Linux性能监控三大工具，分别用于宏观趋势分析、实时I/O监控和底层事件追踪。sar能收集历史数据，支持CPU、内存、磁盘等多维度统计；iotop实时展示I/O大户进程；perf深入代码级性能分析。2.定位CPU瓶颈时，先用top/htop查看高CPU进程，再结合sar -u分析用户态、系统态或I/O等待占比，%us高则用perf top分析热点函数，%sy高则统计系统调用次数，%wa高则转向iotop排查I/O问题。3.排查内存泄露或交换空间使用时，先用free -h查看整体情况，sar -r看内存趋势，ps aux按RSS排序找内存消耗进程，valgrind检测C/C++程序内存问题，同时观察VSZ/RSS变化。4.磁盘I/O下降时，iostat提供await和%util指标判断磁盘负载，vmstat看整体I/O趋势，lsof查文件占用，dmesg排查硬件错误。

Linux系统性能监控，核心在于理解系统在做什么、哪里是瓶颈。sar、iotop 和 perf 这三款工具，就像是系统诊断的三把利器，分别从宏观趋势、实时I/O和底层事件的角度，帮助我们精准定位并解决性能问题。它们各有侧重，但结合使用，就能勾勒出系统运行的全貌。

sar (System Activity Reporter)

我个人觉得 sar 的强大在于它的历史数据能力，排查偶发性问题时简直是救星。它能收集并报告几乎所有系统活动信息，从CPU利用率、内存使用、磁盘I/O到网络流量，甚至进程上下文切换。

要看实时的CPU使用情况，你可以用 sar -u 1 5，这表示每秒刷新一次，共显示五次。输出会告诉你用户态 (%user)、系统态 (%system)、I/O等待 (%iowait) 和空闲 (%idle) 的CPU占比。如果 %iowait 很高，那CPU其实是在等I/O完成，问题根源就不在CPU本身了。

内存方面，sar -r 1 5 能显示内存和交换空间的使用情况。如果看到 kbswpfree 持续减少或者 kbswpused 很高，那系统可能面临内存压力。

磁盘I/O，sar -b 1 5 可以展示块设备的I/O传输速率和队列长度。如果 tps (每秒传输次数) 很高而 rd_sec/s (每秒读取扇区数) 或 wr_sec/s (每秒写入扇区数) 相对较低，可能意味着小文件读写频繁。

sar 最厉害的还是它的后台数据收集机制。通过 sadc 和 sa 文件，你可以回溯过去几天的系统性能数据，这对于分析周期性或突发性的性能下降至关重要。

iotop

当系统突然卡顿，硬盘灯狂闪，iotop 几乎是我第一个想到的工具，直观得让人安心。它是一个实时监控磁盘I/O的工具，有点像 top 命令之于CPU和内存。

直接运行 iotop，它会显示当前正在进行I/O操作的进程或线程，包括它们的PID、用户、读写速度等。默认情况下，它会显示所有进程，即使它们没有I/O活动。如果你只想看那些真正有I/O活动的进程，可以使用 iotop -o。

这个工具对于快速识别哪个进程正在大量读写磁盘非常有效。比如，如果你发现一个备份程序或日志服务正在疯狂写入，导致系统响应缓慢，iotop 就能立刻帮你揪出它。它能让你迅速判断，是不是某个应用导致了I/O瓶颈，而不是系统硬件或配置问题。

perf

perf 这玩意儿，说实话，一开始用起来有点门槛，但一旦你掌握了它，就像拿到了一把解剖刀，能深入到代码执行的每一个细节。它是Linux内核自带的性能分析工具，能够利用CPU的性能计数器来收集各种硬件事件（如CPU周期、缓存命中/未命中、分支预测错误）和软件事件（如系统调用、上下文切换）。

最常用的几个命令：

• perf stat ：运行一个命令并统计其执行期间的各种性能事件。比如 perf stat ls 会告诉你 ls 命令执行了多少CPU周期，多少指令，发生了多少缓存未命中。
• perf top：实时显示CPU上哪些函数或指令消耗了最多的CPU时间，类似 top，但更聚焦于函数级别的热点。
• perf record -g && perf report：这是进行函数调用栈分析的利器。perf record -g 会记录指定命令的执行过程，包括调用栈信息，然后 perf report 会以交互式界面展示这些数据，让你能看到哪个函数是性能瓶颈，以及它的调用路径。

perf 的强大之处在于它能帮你找到代码层面的性能瓶颈，比如某个循环效率低下，或者某个系统调用被频繁触发。不过，要充分发挥它的威力，通常需要安装调试符号（debug symbols），这样 perf report 才能把地址映射回具体的函数名甚至源代码行号。

如何快速定位Linux系统中的CPU瓶颈？

定位CPU瓶颈，我通常会分几步走。首先，top 或 htop 是快速概览的利器，一眼就能看到哪些进程的CPU使用率最高。如果看到某个进程的 %CPU 持续居高不下，那它就是首要怀疑对象。

但光看 %CPU 还不够，得看是用户态 (us) 高还是系统态 (sy) 高，或者是I/O等待 (wa) 高。我经常看到有人一上来就说CPU高就是代码问题，但实际情况复杂多了，得看是用户态、内核态还是I/O等待。

如果 %us (用户态CPU) 很高，这通常意味着应用程序代码本身在大量计算。这时，perf top 或 perf record -g 就派上用场了。你可以用 perf top 实时查看是哪个函数消耗了大量CPU，然后用 perf record -g <你的高CPU应用> 记录一段时间，再用 perf report 深入分析调用栈，找出真正的热点函数。

如果 %sy (系统态CPU) 很高，那说明内核在忙。这可能是因为大量的系统调用、上下文切换或者内核模块的问题。perf stat -e syscalls:sys_enter_* <你的应用> 可以帮你统计系统调用次数，看看是不是某个系统调用被过度频繁地触发。sar -w 可以看上下文切换次数。

如果 %wa (I/O等待) 很高，那CPU其实是在等I/O完成，瓶颈不在CPU，而在磁盘或网络I/O。这时候，iotop 和 sar -b 会是更好的选择，它们能帮你定位是哪个进程在进行大量I/O操作，或者磁盘本身是否存在性能问题。

最后，别忘了 sar -u，它能提供CPU利用率的历史趋势，帮你判断CPU高是突发情况还是持续性问题。

内存泄露或交换空间频繁使用该如何排查？

内存问题特别棘手，有时候不是真的泄露，而是程序设计上对内存使用不合理。排查内存泄露或交换空间频繁使用，我会从几个方面入手。

第一步，当然是 free -h，快速查看当前系统的总内存、已用内存、空闲内存以及交换空间的使用情况。如果 used 接近 total，并且 swap used 很高，那系统内存压力就很大了。

接下来，我会用 sar -r 来查看内存和交换空间的长期趋势。sar -r 真的能帮你看出是不是一个缓慢的内存增长趋势，这往往是内存泄露的典型表现。如果 kbswpfree 持续下降，或者 %swpused 居高不下，并且与应用程序启动时间吻合，那内存泄露的可能性就非常大了。

要找出哪个进程是内存消耗大户，ps aux --sort=-rss 是个好选择，它会按物理内存使用量（RSS）从高到低排序进程。你会看到哪些进程占用了最多的RAM。

如果确定是某个应用程序导致了内存问题，并且怀疑是内存泄露，对于C/C++程序，valgrind --tool=memcheck 是一个强大的内存错误检测工具，它可以帮你找出未释放的内存块。但 valgrind 会显著降低程序运行速度，通常用于开发或测试环境。

对于生产环境，或者无法直接用 valgrind 的情况，可以结合 perf 来分析。虽然 perf 不直接检测内存泄露，但你可以用它来分析与内存相关的事件，比如 perf stat -e page-faults <你的应用>，看看是不是有大量的缺页中断，这可能间接反映出内存访问模式的问题。此外，观察程序的虚拟内存（VSZ）和常驻内存（RSS）随时间的变化，如果VSZ和RSS持续增长且不释放，那内存泄露的嫌疑就更大了。

有时候，频繁使用交换空间不一定是内存泄露，而是内存不足或者内核对内存回收策略的问题。调整 swappiness 参数（例如设置为10或更低）可以减少内核使用交换空间的倾向，但这需要谨慎，因为它可能会导致在内存真正耗尽时系统变得不稳定。

磁盘I/O性能下降，除了iotop还能用哪些工具辅助分析？

除了 iotop 的实时性，iostat 提供的数据维度更广，特别是 await 和 util 这两个指标，能帮你判断是不是磁盘本身出了问题，还是队列太长。当磁盘I/O性能下降时，我会将 iostat 作为 iotop 的有力补充。

iostat 是 sysstat 包的一部分（和 sar 同源），它能提供详细的设备I/O统计信息。

• iostat -xz 1：这个命令会每秒刷新一次，显示所有设备的扩展统计信息。
  • r/s, w/s: 每秒读写请求次数。
  • rkB/s, wkB/s: 每秒读写数据量（KB）。
  • await: 平均I/O操作的等待时间（包括排队时间和服务时间），单位毫秒。这个值如果很高，说明I/O操作等待时间长，可能是磁盘繁忙或队列深度大。
  • %util: 设备利用率。如果接近100%，说明磁盘几乎一直在忙碌，可能是I/O瓶颈。

如果 await 值很高但 %util 不高，那可能是I/O请求队列过长，但磁盘本身处理能力还有余量。如果 await 和 %util 都很高，那磁盘很可能就是瓶颈了。

另一个有用的工具是 vmstat。虽然它更侧重于虚拟内存，但它也提供I/O相关的统计信息：

• vmstat 1：每秒刷新一次。
  • bi (blocks in): 每秒从块设备读取的块数。
  • bo (blocks out): 每秒写入到块设备的块数。 这些指标能让你对系统的整体I/O活动有个大致了解。

当怀疑是文件系统层面的问题时，lsof 可以帮你查看哪些文件被哪些进程打开了。例如，lsof | grep 可以列出在该挂载点上的所有打开文件。这对于排查某个目录被大量文件操作占用时很有用。

如果怀疑是硬件层面的问题，比如磁盘本身性能下降或有坏道，可以查看 dmesg 输出，里面可能会有磁盘错误相关的日志。对于裸盘性能测试，hdparm -tT /dev/sda 可以测试磁盘的读取速度，但要注意这会产生大量I/O，不建议在生产环境频繁执行。

综合来看，iotop 帮你抓实时I/O大户，iostat 提供更细致的磁盘维度数据，vmstat 给出系统整体I/O概览，而 lsof 和 dmesg 则用于更深层次的问题排查。

以上就是《Linux性能监控工具：sar、iotop与perf使用全解析》的详细内容，更多关于的资料请关注golang学习网公众号！