（一个Windows专家问）在Linux上测量磁盘延迟：我麻烦吗？

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

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

我现在正在看Linux，没有看到类似的基于延迟的指标。我所做的快速研究表明，我什至都不愿意...我看到很多关于I / O等待的引用是大多数人跟踪此问题的方式。

在这方面，您是否有使用的经验法则？例如，是否有任何I / O等待我看到数据库容量不足？是否有一个简单的iostat命令可以让我更好地了解磁盘的总体运行状况，而不仅仅是盯着顶部？

非常感谢！

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

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

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

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

从man iostat页面

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

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

％iowait统计信息更多地是关于cpu和磁盘使用率之间的平衡。iostat的％将保持较低，如果比预期的两个 CPU和磁盘活动都很高。另一方面，从相当低的磁盘使用水平开始，如果cpu空闲，则％iostat可能会相对较高。据说这也需要与一粒盐一起服用。如果发生大量顺序读/写操作，则会使图形偏低，并且您的18〜20ms经验法则在这种情况下将无用，因为要写入的大部分数据块将是顺序数据并且将得到服务由于内置在磁盘中的本机命令队列（NCQ）系统通过让磁盘选择服务请求的顺序来优化吞吐量，因此磁盘可以非常快速地进行操作，而其他随机io将等待。