我不是一個儲存人員。我知道如何拼寫 SAN 以及除此之外的一些基礎知識，但僅此而已。
標準磁碟計數器在衡量 SAN 儲存方面是否可靠？我們有 2 台 MS SQL (2005) 伺服器都連接到昨天開始遇到問題的同一個 SAN。我們無法控制硬件，因此除了我透過 Veritas Enterprise Admin 查看到的 LUN 資訊（即，只是基本磁碟區配置）之外，我沒有太多有關如何配置儲存的資訊。我無法使用任何工具來監控控制器或交換器上的吞吐量。
相反，我正在運行 perfmon 計數器（物理和邏輯的磁碟時間百分比，物理和邏輯的磁碟佇列長度）。實體磁碟的磁碟時間百分比數字似乎很驚人 - 高達 32000%（是的，32K）。
這是正確的嗎？
編輯：
應該補充一點的是，我們最近發現 32 個快取模組之一有問題，因此被從組合中刪除。我知道是日立的，但不知道具體型號。
更新：
日立剛完成更換故障的記憶體模組並重新初始化光纖連接埠卡，現在一切似乎都恢復正常。謝謝你們的資訊！
答案1
%Disk Time 明顯瘋狂的數字確實表明了一些事情，但 Perfmon 導出 %Disk Time 的方式意味著數字 >100% 並非不可能。
％磁碟時間實際上是一個計算計數器，它來自：
Avg Disk Sec/Transfer * Disk Transfers/sec.
平均磁碟秒/傳輸取目前時間間隔內所有 IO 完成時間的總和，然後除以 IO 數量，得出平均端對端完成時間。每秒磁碟傳輸數就是完整 IO 總數除以時間間隔。
其中許多 IO 可能是在當前間隔之外啟動的，因此它們的乘積可能 >100%。這種情況可能發生在任何系統上，但在 SAN 等複雜磁碟陣列上發生的頻率會超過 100%。
由於它的計算方式，%Disk Time 並不能真正告訴您太多信息，儘管在本例中它告訴您出現了問題。使用（100-％空閒時間）計算利用率是一個更好的主意，因為％空閒時間實際上是直接測量的。
磁碟佇列長度可能比簡單的本機儲存設定大得多，但一般來說，如果佇列長度>> 支援LUN 的心軸數量，那麼就會進行備份，尤其是在佇列長度在任何重要時期內穩定上升的情況下的時間。在具有 10-15 個磁碟的 LUN 上，值為 10 甚至 20 根本不會有問題，但 350 肯定表示某些地方搞砸了。快取錯誤或配置不當肯定會導致此類問題，但也可能有其他原因。
也就是說，如果您想了解什麼，您必須查看 SAN 等級本身的效能監控，並且您必須從 SAN 人員那裡獲得這些資訊。問題可能出在LUN 上的磁碟上（可能某個磁碟發生故障並且正在進行RAID 重建，可能由於某種原因禁用緩存，可能從同一磁碟上剝離的其他LUN 具有更高的優先權並且正忙），可能該特定陣列上的快取已停用\失敗，可能是 SAN 結構或交換器遇到問題。
有一篇很舊但非常好的文章Windows 中的磁碟計數器在這裡。
答案2
您的「平均」是多少？磁碟讀取佇列長度'和'平均。這些 LUN 的「磁碟寫入佇列長度」perfmon 值，每個伺服器如何相互比較。
如果你能和你的 SAN 人員協商一些安靜的時間，那麼你就可以運行IO區在兩台機器上並比較結果。
答案3
有些計數器對您有用，有些則沒有。當前磁碟佇列之類的資訊將告訴您 Windows 主機在發送讀取/寫入命令和針對 SAN 中的快取處理該命令之間所看到的排隊情況。但如果磁碟運作良好，您仍然可以看到由於快取問題、交換器問題或光纖問題而在主機上排隊。
每次讀取的秒數和每次寫入的秒數之類的東西都會以相同的方式工作，它們告訴您寫入快取需要多長時間。
每秒 IO 寫入等數字更有用。同樣，這是對 SAN 快取的 IO，但該 IO 必須在某個點到達磁碟。每秒 IO 讀取次數也是如此。它是從磁碟和快取中讀取的，但如果它位於讀取快取中，它會在某個時刻從磁碟中取出。