磁盘读取速度间歇性缓慢是否是由操作系统本身造成的？

Question

根据手册页：

   -t     Perform timings of device reads  for  benchmark  and  comparison
          purposes.   For  meaningful  results,  this  operation should be
          repeated 2-3 times on an otherwise  inactive  system  (no  other
          active  processes)  with  at least a couple of megabytes of free
          memory.

所以，其他过程确实会干扰这些结果。

还有其他区域或测试我可以运行吗？

查看其他进程是否正在使用磁盘的一种方法是sysstat从主网页下载这里。Sysstat 当然可以从 repo 中获取，但不幸的是它不包含pidstat检查所需的命令。

EL5 内核自 EL5.4 起将磁盘会计功能移植到内核中，但没有提供使用它的接口，但是一旦完成此操作，pidstat 就会工作。

然后运行pidstat -d命令来生成有用的磁盘 I/O 指标，特别是其他进程对磁盘的操作。您还可以使用它pidstat -d <interval> <count>来获取正在使用的磁盘的更实时的争用指标。

任何类型的 VM/OS 损坏都会导致这种行为吗？

操作系统损坏的可能性很小（我猜系统调用不知怎么搞砸了）。hdparm 不使用文件系统进行测试，从而消除了该区域的任何减速，包括碎片化问题。如果您使用 LVM，则存在您恰好从碎片化的范围读取的风险。但是，您的示例并未表明这一点。

VM 损坏，我想任何游戏都是这样，这取决于我能想到的许多因素，但可能还包括更多：

磁盘采用的是什么映像格式。
如何将数据分配到底层存储机制（它本身是一个具有范围的逻辑卷吗？）
如果磁盘控制器内部正在进行 raid 重建或其他块级维护。例如，如果控制器实际上是一个 SAN，正在执行某种形式的 raid 重新平衡。
团队中的磁盘故障强制进行奇偶校验计算。
实际上数据是否是由 FusionIO 之类的“快速”缓存、SAN 中的数据缓存或电池支持的磁盘阵列卡读取。
底层媒体是否以某种方式对您的存储进行分层。
虚拟机管理程序的磁盘争用导致您的 I/O 请求排队时间更长。
SAN 的磁盘争用导致 I/O 请求排队时间更长（虚拟机驻留在共享存储上是很常见的）。
精简配置卷存在较高的碎片风险。这对您的测试的影响完全取决于您为精简配置区分配了多少块。例如，在 Linux 中的 LVM 精简配置中，区大小默认为 32M，因此在磁盘上传递 32M 标记可能会产生额外的寻道，从而扰乱您的计时。

重建/替换虚拟机有帮助吗？

我猜是好是坏，这得看运气。请参阅上述可能有帮助/阻碍的环境因素。

最终，如果您在将数据写入介质的流程中的任何阶段（在主机上、在 VM 级别、在 SAN/控制器级别）使用卷管理软件或精简配置软件，那么您可以拥有没有可靠的预期您执行的顺序读取确实是顺序的，或者您正在写入的媒体是一致的（如果它是快速磁盘或者数据被移动到慢速磁盘）。

虚拟化之所以如此强大，是因为它为主机添加了一个逻辑抽象层。但是，由于存在该抽象层，因此在主机上执行任何可靠程度的容量管理也可能非常困难。

Answer 1