使用iostat监控Linux磁盘IO，通过安装sysstat包并运行iostat -xk 2 5获取每秒磁盘读写、吞吐量、await等待时间和%util利用率等关键指标，结合%util与await判断瓶颈，再用iotop、vmstat等工具辅助定位具体进程或系统负载问题。
在Linux系统中，监控磁盘IO最直接且常用的方法是使用
iostat命令。它能提供实时的磁盘活动统计数据，帮助你快速了解I/O负载、瓶颈所在，从而进行性能分析和故障排查。
解决方案
要深入了解Linux系统的磁盘IO状况，
iostat是一个不可或缺的工具。它属于
sysstat包，如果你的系统上没有，通常可以通过包管理器安装，比如在Debian/Ubuntu上是
sudo apt install sysstat，在CentOS/RHEL上是
sudo yum install sysstat或
sudo dnf install sysstat。
一旦安装完成，最基本的用法就是直接在终端输入
iostat。
iostat
这会显示自系统启动以来的平均I/O统计数据。对于实时监控，你需要指定一个刷新间隔和可选的计数。例如，每2秒刷新一次，共显示5次：
iostat 2 5
这会让你看到一个动态的I/O快照。然而，仅仅这些数据可能不够详细。为了获取更全面的信息，特别是关于每个设备（磁盘或分区）的详细统计，以及扩展的统计信息，我会加上
-x选项：
iostat -x 2 5
-x选项会显示扩展统计信息，这对于深入分析至关重要。如果你想看到以KB/s或MB/s为单位的吞吐量，而不是默认的块单位，可以分别使用
-k或
-m选项：
iostat -xk 2 5 iostat -xm 2 5
我个人更倾向于使用
-xk，因为KB/s在大多数日常场景下更直观，也更容易与网络带宽等其他指标进行比较。
有时候，你可能只关心特定的设备，比如
sda或
nvme0n1。你可以这样指定：
iostat -xk /dev/sda 2 5
这就能让你聚焦在某个特定磁盘的性能表现上，尤其是在多磁盘系统中排查问题时，这非常有用。
iostat输出的各项指标都代表什么？
iostat -x的输出包含了许多关键指标，理解它们是正确诊断磁盘性能问题的基础。我发现很多人刚接触时会被这些缩写搞得一头雾水，但它们其实都非常直观：
- r/s (read requests per second): 每秒从设备读取的请求次数。这反映了读取操作的频率。
- w/s (write requests per second): 每秒向设备写入的请求次数。这反映了写入操作的频率。
- rkB/s (read kilobytes per second): 每秒从设备读取的千字节数。这是读取吞吐量。
- wkB/s (write kilobytes per second): 每秒向设备写入的千字节数。这是写入吞吐量。
- rrqm/s (merged read requests per second): 每秒合并的读请求数。操作系统会将一些相邻的、小的读请求合并成一个大的请求，这个值越高，说明I/O调度器在合并请求方面做得不错，减少了实际的I/O操作次数。
- wrqm/s (merged write requests per second): 每秒合并的写请求数。同理，这表示合并的写请求数。
-
await (average wait time): 每个I/O请求的平均等待时间（毫秒）。这个时间包括了请求在队列中等待的时间和实际执行I/O操作的时间。这是我个人非常关注的一个指标，因为它直接反映了I/O响应速度。高
await
值通常意味着I/O操作正在排队，系统响应变慢。 -
svctm (average service time): 每个I/O请求的平均服务时间（毫秒）。这是I/O请求实际在设备上执行的时间，不包括在队列中等待的时间。这个值通常比较小，如果它突然飙升，可能意味着磁盘本身出了问题。但需要注意的是，
svctm
在Linux 2.6内核及之后，其计算方式变得不那么可靠，所以更多时候我还是会看await
。 -
%util (percentage of CPU utilization for I/O): 设备利用率。表示设备用于I/O操作的时间百分比。如果这个值接近100%，意味着磁盘几乎一直在忙碌，可能是I/O瓶颈的直接信号。但它不完全等于磁盘饱和，因为并行I/O的存在，一个磁盘在逻辑上100%忙碌，但如果它能处理大量并行请求，性能可能依然良好。然而，结合
await
来看，如果%util
很高且await
也高，那基本可以确定磁盘是瓶颈了。
如何根据iostat数据判断磁盘性能瓶颈？
判断磁盘性能瓶颈，不是简单看一个指标就能下结论的，需要综合分析。我通常会从几个关键点入手：
-
高 %util 伴随高 await： 这是最典型的磁盘瓶颈特征。如果
%util
持续接近100%，而await
值也显著升高（比如对于SSD，超过几毫秒就值得警惕；对于HDD，几十毫秒可能也算正常，但如果达到数百毫秒，那肯定有问题），这意味着磁盘已经饱和，I/O请求正在大量排队等待处理。- 对于SSD，我个人经验是
await
超过5-10ms就应该引起注意，超过20ms就很可能影响应用性能。 - 对于传统HDD，
await
超过20-50ms可能还算可以接受，但如果持续超过100ms，那肯定有问题了。
- 对于SSD，我个人经验是
-
高 rkB/s 或 wkB/s 但低 r/s 或 w/s： 这说明磁盘正在进行大量的大块数据传输（吞吐量高），但每秒的I/O操作次数（IOPS）并不高。这通常是顺序读写密集型应用（如文件传输、视频流）的特征。如果此时
await
也很高，可能是磁盘的顺序读写能力达到了上限。 -
高 r/s 或 w/s 但低 rkB/s 或 wkB/s： 这表示磁盘正在处理大量的小文件I/O请求（IOPS高），但总的吞吐量不高。这在数据库、邮件服务器等随机I/O密集型应用中很常见。如果此时
await
很高，说明磁盘的随机读写能力不足，或者说它的IOPS能力达到了瓶颈。 - 磁盘利用率（%util）很高，但吞吐量（rkB/s, wkB/s）和IOPS（r/s, w/s）却不高： 这可能意味着磁盘正在处理大量非常小的I/O请求，或者请求合并效率低下，导致每次I/O的开销相对较大，虽然数据量不大，但磁盘却很忙。
-
特定设备的指标异常： 如果你的系统有多个磁盘，
iostat -x
会列出每个磁盘的统计信息。如果只有一个或少数几个磁盘的await
和%util
异常高，那么问题很可能就出在这些磁盘上，或者有某个进程正在对它们进行大量I/O操作。
诊断时，我还会结合系统日志（
dmesg或
journalctl -k）查看是否有磁盘相关的错误信息，以及使用
df -h检查磁盘空间使用情况，有时候空间不足也会导致I/O性能下降。
除了iostat，还有哪些工具可以辅助监控Linux磁盘IO？
虽然
iostat是我的首选，但它并非唯一能帮助你了解磁盘I/O的工具。在某些特定场景下，其他工具能提供更细粒度的信息，或者从不同维度来展现问题。
-
vmstat： 这是一个通用的系统监控工具，除了CPU和内存，它也能显示I/O统计信息。运行
vmstat 2 5
会在输出中包含bi
(blocks in, 从磁盘读取的块数) 和bo
(blocks out, 写入磁盘的块数)。虽然不如iostat
详细，但它能快速提供一个系统整体的I/O概览，有时能帮助你判断问题是否与I/O相关，或者是否是更广泛的系统资源瓶颈。 -
iotop： 如果你想知道是哪个进程在疯狂地读写磁盘，
iotop
是你的最佳选择。它类似于top
命令，但专注于显示进程的I/O活动。直接运行sudo iotop
就能看到实时的进程I/O使用情况，包括读写带宽和IOPS。这对于定位“罪魁祸首”的应用程序非常有效，特别是当iostat
显示磁盘繁忙，但你不知道是哪个应用导致的。 -
sar (System Activity Reporter)：
sar
是一个非常强大的工具集，iostat
实际上是sysstat
包中的一部分，而sar
则是sysstat
的核心。sar
可以收集、报告或保存系统活动信息。你可以用sar -d
来查看磁盘活动，其输出与iostat
类似，但sar
的优势在于它可以查看历史数据，如果你配置了sysstat
服务，它会定期将系统性能数据保存下来，这样你就能分析过去某个时间点的性能问题。例如，sar -d -f /var/log/sysstat/saXX
可以查看特定日期的磁盘I/O历史数据。 -
pidstat：
pidstat
也是sysstat
包的一部分，它能提供进程级别的详细统计信息，包括CPU、内存、I/O等。使用pidstat -d 2 5
可以查看每个进程的I/O统计，例如每秒读写的KB数。与iotop
相比，pidstat
的输出可能更适合脚本化处理或集成到监控系统中，因为它不是一个交互式界面。
这些工具各有侧重，我通常会从
iostat开始，如果发现I/O是瓶颈，就用
iotop或
pidstat定位具体进程，再结合
vmstat看看是否有其他资源问题。这种组合拳往往能高效地解决大部分磁盘性能问题。
