当我在服务器上看到 IO 等待时，我理解这是因为 CPU 被阻塞，等待 IO 赶上进度[来源]。
我试图了解为什么 SAN 统计数据会显示高 IO 等待时间 - 这是否表明 SAN CPU 被 SAN 磁盘阻塞，还是其他原因？
答案1
由于物理基本定律，SAN 的 IO 延迟比本地磁盘高得多。因此，如果您的应用程序执行大量小写入，并且fsync()每次写入后，您都会看到大量的 iowait。
例如，这里有两个包含许多小事务的同一数据集的 mysql 复制器，您会看到 SAN 上的从属服务器花费大量时间进行 IO。
桑：
当地的：
答案2
SAN 等待时间可能意味着您的存储是瓶颈。也可能是服务器设置或服务器与存储之间的连接，但更常见的是，当我看到 SAN 磁盘的等待时间时，它只是一个繁忙的 SAN。
首先，检查支持该卷的磁盘的性能。您要查找 IO/s 或 MB/s 读取或写入的峰值，以及可能的缓存利用率峰值。尝试仅查看您正在调查的卷所涉及的硬件。此外，回顾一下过去和未来，看看是否有更高的峰值没有引起问题。如果是这样，那么存储硬件不太可能是问题所在。存储硬件瓶颈的纠正措施可能包括将此卷迁移到另一个池或 RAID，或增加主轴或缓存的数量。
其次，检查服务器上的队列深度设置。如果队列深度非常高，则在高使用率期间，服务器的延迟会更高。队列深度是存储告诉服务器限制其 IO 以允许存储赶上的一种方式。32 是一个很好的平均数字，大多数服务器操作系统和大多数存储设备都支持它。我也见过更高和更低的值，但如果将其设置为 1024 或类似值，则可能解释为何等待时间较长。在队列深度非常高的情况下，服务器会将其想要执行的所有操作排队，然后存储会以队列深度低得多时的速度执行这些操作。由于服务器测量从某些东西进入队列到离开队列的等待时间，因此等待时间会增加。
最后，检查服务器的错误日志。确保没有传输级别问题（如磁盘超时或路径故障）。如果有，您需要检查交换机。
答案3
它的测量方式与服务器上的测量方式没有什么不同：传入的 IO 请求数量超出了可用硬件资源可以处理的数量。
答案4
SAN 管理软件报告的高 IO 等待时间意味着 SAN 硬件无法满足 SAN 客户端的需求。这要么是因为您的硬件没有能力处理您的负载，要么是某些东西出现故障且性能不佳。
驱动器缓慢故障导致性能不佳实际上相当常见，尤其是在 RAID5 设置中。提取所有驱动器的 SMART 日志，我敢打赌，您会发现一个驱动器具有大量已更正的错误。（更正这些错误需要时间。如果在一定时间内更正了单个错误，则 RAID 控制器不会记录错误。但是，如果累积了大量这些错误，就会花费大量时间。这就是导致性能不佳的原因。）