在 Windows 上，每当我想要验证/确认数据库或其他低延迟应用程序所在的卷上可能存在与 IO 相关的问题时，我都会检查磁盘延迟。
如果我看到窗户平均磁盘秒/传输计数器持续 > 18-20ms，那么我的煤矿金丝雀就死了，我需要进一步调查。非常简单。
我现在正在查看 Linux，没有看到类似的基于延迟的指标。我所做的快速研究表明我可能甚至不想这样做...我看到很多参考资料都提到 I/O 等待是大多数人跟踪此问题的方式。
您是否对此有一个大致的经验法则？例如，我看到的任何 I/O 等待是否对数据库的卷不利？是否有一个简单的 iostat 命令可以让我更好地了解整体磁盘健康状况，而不仅仅是目测 TOP？
非常感谢！
答案1
我个人使用命令iostat -xk 10并查看await列。
- -x 显示扩展统计信息。
- -k 以每秒千字节为单位显示统计信息。或者使用 m 表示每秒兆字节。
- 10 显示间隔（秒）
这是一个几乎与窗户相同的指标平均磁盘秒/传输并以毫秒而不是秒为单位列出。因此可以应用类似的经验法则，尽管这将取决于各种因素。我通常发现用户在 15 毫秒时开始抱怨，而 20 毫秒则非常糟糕。
按 ctrl+c 退出，或者使用 count 参数指定要查看的迭代次数。请注意，由于第一次迭代使用的时间样本较少，因此第一次迭代结果偏差很大。
从man iostat页面
等待向设备发出 I/O 请求并等待服务的平均时间（以毫秒为单位）。这包括请求在队列中花费的时间和为这些请求提供服务所花费的时间。
编辑：
await是我用来观察生产负载下的磁盘的主要指标，以查看其吞吐量和 iops 是否能够满足需求。
%iowait 统计信息更多地是关于 CPU 和磁盘使用率之间的平衡。如果两个都CPU 和磁盘活动很高。另一方面，从相当低的磁盘使用率开始，如果 CPU 处于空闲状态，%iostat 可能会相对较高。也就是说，await 也需要谨慎对待。如果发生大量连续读取/写入，它将使数字偏向较低的值，并且您的 18~20ms 经验法则在这些条件下将不起作用，因为大多数写入的块将是连续数据，并且将很快由磁盘提供服务，而其他随机 io 将等待，这是由于内置于磁盘的本机命令排队 (NCQ) 系统通过让磁盘选择请求的服务顺序来优化吞吐量。