IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

通过『iostat -dx 1』命令监控IO性能

火丁笔记 2011-07-14 23:51:28 累计浏览 5,170 次
本机暂存

    网站的很多性能问题最终都会归结到IO头上,所以说理解iostat命令是非常有必要的。

    小技巧:你知道iostat是从哪里得到IO相关信息的吗?使用strace命令能跟踪到答案:

shell> strace -eopen iostat
open("/proc/diskstats", O_RDONLY)

    注:关于diskstats的说明,参见官方文档(field1 ~ field11)。

    我最常用的iostat命令格式是:『iostat -dx 1』,意思是每隔一秒显示一次IO扩展信息。

shell> iostat -dx 1
Device:         rrqm/s   wrqm/s   r/s   w/s   rsec/s   wsec/s
sda               0.18    37.71  0.65  2.63    50.18   322.08
                avgrq-sz avgqu-sz   await  svctm  %util
                  113.46     0.35  107.49   1.67   0.55

Device:         rrqm/s   wrqm/s   r/s   w/s   rsec/s   wsec/s
sda               0.00  4208.00  0.00 165.00     0.00 163872.00
                avgrq-sz avgqu-sz   await  svctm  %util
                  993.16   119.54 1144.36   6.07 100.10

    注:开头显示的是自系统启动开始的平均值,后面显示的是每段时间间隔里的平均值。

    介绍一下相关参数的含义:

  • rrqm/s:队列中每秒钟合并的读请求数量
  • wrqm/s:队列中每秒钟合并的写请求数量
  • r/s:每秒钟完成的读请求数量
  • w/s:每秒钟完成的写请求数量
  • rsec/s:每秒钟读取的扇区数量
  • wsec/s:每秒钟写入的扇区数量
  • avgrq-sz:平均请求数据的大小
  • avgqu-sz:平均请求队列的长度
  • await:平均每次请求的等待时间
  • svctm:平均每次请求的服务时间
  • util:设备的利用率
  •     注:建议对照源代码来记忆这些参数都是如何计算出来的。

        关于这些参数,相对重要的是后面几个,具体来说是:util,svctm,await,avgqu-sz:

        util是设备的利用率。如果它接近100%,通常说明设备能力趋于饱和(并不绝对,比如设备有写缓存)。有时候可能会出现大于100%的情况,这多半是计算时四舍五入引起的。

        svctm是平均每次请求的服务时间。这里有一个公式:(r/s+w/s)*(svctm/1000)=util。举例子:如果util达到100%,那么此时svctm=1000/(r/s+w/s),假设IOPS是1000,则svctm大概在1毫秒左右,如果长时间大于这个数值,说明系统出了问题。

        await是平均每次请求的等待时间。这个时间包括了队列时间和服务时间,也就是说,一般情况下,await大于svctm,它们的差值越小,队列时间越短,反之差值越大,队列时间越长,说明系统出了问题。

        avgqu-sz是平均请求队列的长度。毫无疑问,队列长度越短越好,这就不用多做解释了。

        提醒:如果是RAID等多盘系统,iostat结果的参考价值可能有变化,建议查阅相关资料。

        说明:svctm参数在未来某个版本的iostat会被删除,官方文档是这样描述原因的:

        The average service time (svctm field) value is meaningless, as I/O statistics are calculated at block level, and we don’t know when the disk driver starts to process a request. For this reason, this field will be removed in a future sysstat version.

        另外,有时候iostat会显示一些很离谱的结果,官方FAQ给出了如下的解释:

        Because of a Linux kernel bug, iostat -x may display huge I/O response times (svctm) and a bandwidth utilization (%util) of 100% for some devices. Indeed these devices have a value for the field #9 (beginning after the device name) in /proc/{partitions,diskstats} which is always different from 0, and even negative sometimes. Yet this field should go to zero, since it gives the number of I/Os currently in progress (it is incremented as requests are submitted, and decremented as they finish). To (temporarily) solve the problem, you should reboot your system to reset the counters in /proc/{partitions,diskstats}.

        参考资料:

  • iostat -x
  • How Linux iostat computes its results
  • iostat: (r/s + w/s) * svctm = %util on Linux
  • 同分类推荐文章

    1. 从零重建 macOS 开发机:可复现的环境初始化流程 (2026-06-14 20:36:00)
    2. 百度物理网络监控工具开源第二弹:毫秒级监控工具 baize,让你的网络问题无处遁形 (2026-06-11 08:10:28)
    3. How to Set Up Homebrew Tap for Private CLI Tools: A Complete Guide (2026-05-27 02:13:03)

    查看更多 DevOps 文章 →

    建议继续学习

    1. WEB系统需要关注的一些点 (累计阅读 18,218)
    2. Linux如何统计进程的CPU利用率 (累计阅读 16,307)
    3. 批量添加主机到cacti+nagios的监控报警系统中 (累计阅读 14,990)
    4. 我的 RHCA 之路 (累计阅读 14,011)
    5. 我常用的主机监控shell脚本 (累计阅读 13,429)
    6. Linux内存点滴 用户进程内存空间 (累计阅读 13,228)
    7. 给程序员新手的一些建议 (累计阅读 13,088)
    8. Linux 性能监控、测试、优化工具 (累计阅读 13,010)
    9. 关于linux内存free的一些事情 (累计阅读 12,866)
    10. ps - 按进程消耗内存多少排序 (累计阅读 12,685)