在Windows上，无论何时我要validation/确认数据库或其他低延迟应用程序所在的卷上可能存在与IO有关的问题，我都会检查磁盘延迟。
如果我一直看到Windows 平均磁盘秒数/传输计数器> 18-20ms，那么我的金丝雀在一个煤矿刚刚死亡，我需要进一步调查。 堕落简单。
我现在在看Linux，没有看到类似的基于延迟的指标。 我所做的快速研究表明，我可能甚至不希望…我看到很多引用I / O等待大多数人跟踪这个。
在这方面有没有一个经验法则？ 例如，是否任何I / O等待我看到数据库的音量不好？ 有没有一个简单的iostat命令，让我更好地看看整体磁盘的健康状况，而不是只是眼球TOP？
非常感谢！
就我个人而言，我使用命令iostat -xk 10并查看await列。
这是一个几乎相同的衡量指标的Windows 平均磁盘秒/传输，并以毫秒，而不是秒列出。 所以可以应用类似的经验法则，尽pipe这取决于各种各样的事情。 我通常发现，用户开始抱怨15毫秒和20毫秒是非常糟糕的。
按ctrl + c退出，或用count参数指定要查看的迭代次数。 请注意，由于在第一次迭代中使用的小时间样本，第一次迭代的结果会严重偏斜。
从man iostat页面
等待发送到要提供服务的设备的I / O请求的平均时间（以毫秒为单位）。 这包括队列中的请求花费的时间以及花费在队列中的时间。
编辑： await是我用来观看生产负载下的磁盘，看它的吞吐量和iops是否能跟上需求的主要指标。
％iowait统计更多地关于CPU和磁盘使用之间的平衡。 如果cpu和磁盘活动都很高，％iostat将保持低于预期的水平。 另一方面，从相当低的磁盘使用率开始，如果CPU空闲，％iostat可能会相对较高。 这就是所谓的等待需要与一粒盐，以及。 如果发生大量连续的读/写操作，它会将数字倾斜到一个较低的值，而在这些条件下，你的18〜20ms的经验法则将不会有用，因为大部分被写入的数据块都是连续的数据， ，而另一个随机io则会等待，因为磁盘内置了Native-Command-Queuing（NCQ）系统，通过让磁盘select服务请求的顺序来优化吞吐量。