（一个 Windows 人问）在 Linux 上测量磁盘延迟：我打扰了吗？

Question

在 Windows 上，每当我想验证/确认数据库或其他低延迟应用程序所在的卷上可能存在与 IO 相关的问题时，我都会检查磁盘延迟。

如果我看到 Windows平均磁盘秒/传输计数器始终 > 18-20 毫秒，那么我在煤矿中的金丝雀就死了，我需要进一步调查。非常简单。

我现在正在研究 Linux，但没有看到类似的基于延迟的指标。我所做的快速研究表明我什至可能不想...我看到很多对 I/O Wait 的引用是大多数人跟踪它的方式。

对此，您是否使用了大致的经验法则？例如，是否有任何 i/o 等待我认为数据库卷不好？是否有一个简单的 iostat 命令可以让我更好地了解整体磁盘健康状况，而不仅仅是盯着 TOP？

非常感谢！

Answer 1

我个人使用命令iostat -xk 10并查看await列。

• -x 显示扩展统计信息。
• -k 以千字节每秒显示统计信息。或使用 m 表示兆字节/秒。
• 10 秒显示间隔

这实际上是与 windows平均磁盘秒/传输相同的指标，并以毫秒而不是秒为单位列出。因此可以应用类似的经验法则，尽管这将取决于各种事情。我通常发现用户在 15 毫秒和 20 毫秒开始抱怨是非常糟糕的。

按ctrl+c退出，或者用count参数指定要查看的迭代次数。请注意，由于第一次迭代中使用的时间样本较小，因此第一次迭代结果严重偏斜。

从man iostat页面

await向要服务的设备发出的 I/O 请求的平均时间（以毫秒为单位）。这包括队列中的请求所花费的时间以及为它们提供服务所花费的时间。

编辑： await是我用来在生产负载下观察磁盘以查看其吞吐量和 iops 是否能够满足需求的主要指标。

%iowait 统计更多的是关于 cpu 和磁盘使用率之间的平衡。iostat的％将保持较低，如果比预期的两个CPU和磁盘活动都很高。另一方面，从相当低的磁盘使用水平开始，如果 cpu 空闲，%iostat 可能会相对较高。这就是说 await 也需要保留一粒盐。如果发生大量顺序读/写，它会将数字偏斜到较低的值，并且您的 18~20ms 经验法则在这些情况下将没有用，因为正在写入的大多数块将是顺序数据并将得到服务由于磁盘内置的 Native-Command-Queuing (NCQ) 系统通过让磁盘选择请求服务的顺序来优化吞吐量，因此其他随机 io 将非常快地通过磁盘等待。