打擾的存在和職位的情況下。 這是過去一年過山車人身傷害和平了工作日程，所以我很少有時間或動機到博客或顯示我的臉，周圍的社區。 我向你道歉，我決心要打破這種習慣，並再次進入回事情！ 但足夠的喋喋不休，著作...

這不是我常看的很，但是當我這樣做，這是有趣的統計為自己說話。 我幾年前了他們的NetApp房地產的腳本部署與客戶，它沒有過多的照顧或注意（我要討論的另一天）設計或交付。 與SQL，Exchange和其他的事情，他們有一個VMware的房地產。 這一切都貫穿共有超過100 15K FC紗錠。 與其他網站相比，它不是一個巨大的房地產，所以我到他們為什麼有這樣的性能問題感興趣。

現在，當您通過“SYSSTAT-U”運行，你可以看到，文件管理器本身做的很少，很樂意應該做些什麼。 但磁盤往往達到100％。 立刻，這表明磁盤問題。 他們需要更多的紗錠，很明顯嗎？

首先是主軸不平衡。 他們有一個夥伴控制器，只有測試卷上的第二個總。 我得到的許可，以消除和熱，我重新分配這些其他控制器和擴大現有的總和。 這雙打主軸計數，但我知道它不會做任何現有的業績（在該數據將不會自動重新分配本身！）。

如果我通過“：*：統計顯示磁盤disk_busy”跑，我可以看到很明顯的。 達到100％，在整個系統中，有一個單一的磁盤，其餘的都沒有。 還有一堆其他磁盤（約10），正在運行的50-60％，然後滴答作響在20-30％左右，其餘的磁盤。 因此，這裡發生了什麼事情？ NetApp技術應防止任何形式的熱系統中的主軸。

這是我的理論。 被折磨的文件管理器和堆疊的開箱，但總沒有增長（3磁盤聚合，1數據2校驗）。 一些存儲配置和數據遷移。 他們跑出來的空間，因此增長的總和（少許），然後複製到磁盤一束更多的數據。 這一切後，他們再加入其餘的磁盤。 現在，因為數據不會自動重新分配上的蒼蠅，任何數據不變（VM系統磁盤，舊的Exchange電子郵件，和老數據倉庫數據會發生），那麼他們仍坐在原來的主軸，甚至作為他們第一次安裝時的主軸。

所以我現在就盼著週末。 我們將它們升級至Data ONTAP 7.3.2，然後我就可以運行一些再分配，掃描，不影響整個系統的快照空間使用情況（巨額獎金，感​​謝你NetApp的！）。 我希望，這將消除熱主軸問題。 我之前統計，我拉出後統計下週。 我會更新這個職位。

從這個故事的教訓？ 設置存儲系統完全，徹底，然後再開始扔在它的數據。 不要使用新的存儲玩具興奮，立即拋出數據。 我看過多次的上述情況，現在，和前ONTAP的7.3，它是一個痛苦的修復。

快速快照的統計輸出。 請記住，在集群，這將顯示所有磁盤，使所有磁盤的統計是完全相關的。 只是在這裡忙碌的磁盤，不添加到實際系統中的磁盤數量，你可以清楚地看到一個忙碌的磁盤。

> SYSSTAT-U 1
CPU總淨kb / s的磁盤kb / s的磁帶kb / s的Cache緩存CP CP的磁盤
OPS /在輸出讀寫，讀寫年齡命中時間TY UTIL
3220 6942 3270 4232 0 0 0 12 95％0％ - 60％11％
2898 7385 4030 4892 0 0 0 11 94％0％11％ - 69％
3547 1820 3496 3920 24 0 0 11 93％0％9％ - 89％
2329 1160 3048 3892 0 0 0 11 93％0％7％ - 81％
3173 2055 4851 4644 8 0 0 11 93％0％ - 67％10％
2491 1860 4547 4568 24 0 0 11 91％0％9％ - 98％
2523 2960 4404 5372 0 0 0 11 90％0％9％ - 89％
5136 8173 4465 3352 0 0 0 11 95％0％ - 81％​​14％

>統計顯示盤：*：disk_busy
......喀嚓......

......喀嚓......