我不是存储人。我知道如何拼写 SAN 和一些除此之外的基础知识，但并不多。
标准磁盘计数器在测量 SAN 存储方面是否可靠？我们有 2 台 MS SQL (2005) 服务器都连接到昨天开始出现问题的同一个 SAN。我们无法控制硬件，因此我没有太多关于如何配置存储的信息，除了我通过 Veritas Enterprise Admin 看到的 LUN（即，只是基本的卷配置）。我无法使用任何工具来监控控制器或交换机上的吞吐量。
取而代之的是，我正在运行 perfmon 计数器（物理和逻辑的磁盘时间百分比，物理和逻辑的磁盘队列长度）。物理磁盘的 % 磁盘时间数字似乎很糟糕 - 高达 32000%（是的，32K）。
是这样吗，或者我认为某些东西是从 LUN 级别以下聚合以形成该指标，而我不应该对 SAN 存储使用这个计数器，这是否正确？
编辑：
应该补充一点，我们最近发现 32 个缓存模块中的一个有问题并且被排除在外。我知道它是日立的，但我不知道模型的任何细节。
更新：
日立刚刚完成更换有故障的内存模块并重新初始化光纤端口卡，现在一切似乎恢复正常。感谢您的信息！
%Disk Time 的明显疯狂数字确实表明了一些东西，但 Perfmon 派生 %Disk Time 的方式意味着数字>100% 并非不可能。
%Disk time 实际上是一个计算出来的计数器，它来自：
Avg Disk Sec/transfer 采用当前间隔内所有 IO 的完成时间的总和除以 IO 的数量，得出平均端到端完成时间。每秒磁盘传输数只是完成 IO 的总数除以间隔。
其中许多 IO 可能已在当前间隔之外启动，因此它们的产品可能 > 100%。这可能发生在任何系统上，但在像 SAN 这样的复杂磁盘阵列上会超过 100%。
由于它的计算方式 %Disk Time 并不能真正告诉你太多，尽管在这种情况下它告诉你出了点问题。使用 (100-%idle time) 计算利用率是一个更好的主意，因为 %idle time 实际上是直接测量的。
磁盘队列长度可能比在简单的本地存储设置上大得多，但通常如果队列长度为 >> 支持 LUN 的心轴数，那么事情正在备份，特别是如果队列长度在任何重要时期内稳定上升的时间。在具有 10 到 15 个磁盘的 LUN 上，10 甚至 20 的值根本不是问题，但 350 肯定是说有些事情搞砸了。错误或配置不当的缓存肯定会导致类似的问题，但也可能有其他原因。
也就是说，如果您想知道您真正需要查看的是 SAN 级别本身的性能监控，您将不得不从您的 SAN 人员那里获得。问题可能出在 LUN 上的磁盘上（可能某个磁盘发生故障并且正在进行 RAID 重建，可能缓存由于某种原因被禁用，可能从同一磁盘上剥离的其他 LUN 具有更高的优先级并且很忙），可能该特定阵列上的缓存被禁用\失败，可能是 SAN 结构或交换机遇到问题。
这里有一篇关于Windows 磁盘计数器的旧但非常好的文章。
你的“平均”是多少？磁盘读取队列长度'和'平均。这些 LUN 的磁盘写入队列长度的性能值，每个服务器如何相互比较。
如果您可以与您的 SAN 人员协商一些安静的时间，那么您可以在两台机器上运行IOZone并比较结果。
有些计数器对您有用，有些则没有。当前磁盘队列之类的内容将告诉您 Windows 主机在发送读/写命令和针对 SAN 中的缓存处理该命令之间看到的队列。但如果磁盘运行良好，您仍然可以看到由于缓存问题、交换机问题或光纤问题而在主机上排队。
每次读取的秒数和每次写入的秒数之类的工作方式相同，它们告诉您写入缓存需要多长时间。
像每秒 IO 写入这样的数字更有用一些。同样，这是 SAN 缓存的 IO，但该 IO 必须在某个点上将其发送到磁盘。每秒 IO 读取也是如此。它是从磁盘和缓存中读取的，但如果它在读取缓存中，它会在某个时候从磁盘上脱落。