什么会导致IO在SAN上等待？

由于物理学的基本定律，SAN比本地磁盘具有更高的IO延迟。 所以如果你的应用程序在每个之后都做了很多的小写和fsync() ，你会看到很多iowait。

例如，以下是包含许多小事务的相同数据集的两个mysql复制器，您将看到SAN上的从属设备花费大量时间来执行IO。

三：

本地：

SAN等待时间可能意味着您的存储是瓶颈。 它也可能是服务器设置或服务器与存储之间的连接，但更频繁的是，当我看到SAN磁盘等待时，它只是一个繁忙的SAN。

首先，检查支持卷的磁盘上的性能。 您正在寻找IO / s或MB / s读取或写入的高峰，并可能导致高速caching利用率的高峰。 试着只看看你正在调查的卷所涉及的硬件。 此外，稍微回顾一下，看看是否有更高的峰值，不会造成问题。 如果是这样，那么存储硬件不太可能成为问题。 存储上的硬件瓶颈纠正措施可能包括将该卷迁移到另一个池或RAID，或者增加主轴或caching的数量。

其次，检查服务器上的队列深度设置。 如果您的队列深度非常高，那么您的服务器将在大量使用期间看到更高的延迟。 队列深度是存储告诉服务器遏制他们的IO的一种方式，允许存储赶上。 32是一个很好的平均数量，大多数服务器操作系统和我见过的大多数存储设备都可以支持。 我也看到了更高和更低的工作，但是如果它设置为1024或者什么的，这可以解释高等待时间。 在队列深度非常高的情况下，服务器将所有想做的事情排队，然后存储的速度就会像队列深度要低的那样快。 由于服务器测量等待时间，从某个事物进入队列并离开队列之后，等待时间将会增加。

最后，检查服务器的错误日志。 确保没有传输级别问题（如磁盘超时或path故障）。 如果有，你会想看看开关。

它的测量方式与在服务器上没有区别：有更多的IO请求进来，可用硬件资源处理。

SANpipe理软件报告的高IO等待意味着SAN硬件无法满足SAN客户端的需求。 这要么是因为你的硬件没有你的负载能力，要么是因为失败和性能不佳。

一个缓慢的失败的驱动器造成不佳的performance实际上是相当普遍的，特别是在RAID5设置。 拉出所有驱动器的SMART日志，我敢打赌，你会发现一个驱动器具有非常多的纠正错误。 （纠正这些错误需要时间，如果在一定的时间内纠正了一个单独的错误，那么RAID控制器不会logging一个错误，但是堆积了很多这些错误，这就增加了很多时间。如何得到糟糕的performance。）