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