windows下如何查看磁盤IO性能

http://www.51testing.com/?uid-211722-action-viewspace-itemid-233892

服務器性能瓶頸如何判斷、CPU瓶頸、內存泄漏、內存不足、硬件問題、磁盤瓶頸——LoadRunner負載測試之Windows常見性能計數器，分析服務器性能瓶頸

?

判斷瓶頸
?一、判斷應用程序的問題?

如果系統由于應用程序代碼效率低下或者系統結構設計有缺陷而導致大量的上下文切換(context switches/sec顯示的上下文切換次數太高)那么就會占用大量的系統資源,如果系統的吞吐量降低并且CPU的使用率很高,并且此現象發生時切換水平在15000以上,那么意味著上下文切換次數過高.
?

contextswitches/sec
從圖的整體看.context switches/sec變化不大,throughout曲線的斜率較高,并且此時的contextswitches/sec已經超過了15000.程序還是需要進一步優化.
二、判斷CPU瓶頸
如果processor queue length顯示的隊列長度保持不變(>=2)個并且處理器的利用率%Processortime超過90%,那么很可能存在處理器瓶頸. 如果發現processor queue length顯示的隊列長度超過2,而處理器的利用率卻一直很低,或許更應該去解決處理器阻塞問題,這里處理器一般不是瓶頸.
?

CPU瓶頸
%processor time平均值大于95,processor queue length大于2.可以確定CPU瓶頸.此時的CPU已經不能滿足程序需要.急需擴展. CPU資源成為系統性能的瓶頸的征兆: 很慢的響應時間(slow response time) CPU空閑時間為零(zero percent idle CPU) 過高的用戶占用CPU時間(%User Time) 過高的系統占用CPU時間(%Priviliaged Time：長期大于90%或者95%) 長時間的有很長的運行進程隊列(Process Queue Lengt：大于處理器個數+1)
三、判斷內存泄露問題
內存問題主要檢查應用程序是否存在內存泄漏,如果發生了內存泄漏,process\private bytes計數器和process\working set 計數器的值往往會升高,同時avaiable bytes的值會降低.內存泄漏應該通過一個長時間的,用來研究分析所有內存都耗盡時,應用程序反應情況的測試來檢驗.
?

內存泄露
圖中可以看到該程序并不存在內存泄露的問題.內存泄露問題經常出現在服務長時間運轉的時候,由于部分程序對內存沒有釋放,而將內存慢慢耗盡.也是提醒大家對系統穩定性測試的關注. Windows資源監控中，如果Process\Private Bytes計數器和Process\Working Set計數器的值在長時間內持續升高，同時Memory\Available bytes計數器的值持續降低，則很可能存在內存泄漏。
四、判斷內存不足
如果隊列長度（Avg.Disk Queue Length）增加的同時頁面讀取速率（Page Reads/sec）并未降低，則內存不足。 如果Available Mbytes（剩余物理內存數）的值很小(4 MB 或更小)，則說明計算機上總的內存可能不足，或某程序沒有釋放內存。
五、硬件問題
請觀察 Processor\ Interrupts/sec 計數器的值，該計數器測量來自輸入/輸出 (I/O) 設備的服務請求的速度。如果此計數器的值明顯增加，而系統活動沒有相應增加，則表明存在硬件問題。
六、I/O資源成為系統性能的瓶頸的征兆
IO Data Bytes/sec(處理從I/O操作讀取/寫入字節的速度。這個計數器為所有由本處理產生的包括文件、網絡和設備I/O的活動計數。) IO Data Operations/sec IO Other Bytes/sec IO Other Operations/sec IO Read Bytes/sec(每秒IO讀取字節數) IO Read Operations/sec IO Write Bytes/sec(每秒IO寫出字節數) IO Write Operations/sec 過高的磁盤利用率(high disk utilization) 太長的磁盤等待隊列(Physical Disk\ Current Disk Queue Length,正在等待磁盤訪問的系統請求數量) 等待磁盤I/O的時間所占的百分率太高(Average Disk Queue Length) 太高的物理I/O速率:large physical I/O rate(not sufficient in itself) 過低的緩存命中率(low buffer cache hit ratio(not sufficient in itself)) 太長的運行進程隊列，但CPU卻空閑(Process Queue Length) 在方案運行中，如果出現了大于3個用戶的業務操作失敗，或出現了服務器shutdown的情況，則說明在當前環境下，系統承受不了當前并發用戶的負載壓力，那么最大并發用戶數就是前一個沒有出現這種現象的并發用戶數
七、監視磁盤的使用情況
監視磁盤活動涉及兩個主要方面：
監視磁盤 I/O 及檢測過度換頁
隔離 SQL Server 產生的磁盤活動
監視磁盤 I/O 及檢測過度換頁? 可以對下面兩個計數器進行監視以確定磁盤活動：
PhysicalDisk: % Disk Time 
PhysicalDisk: Avg. Disk Queue Length 
在系統監視器中，PhysicalDisk:% Disk Time計數器監視磁盤忙于讀/寫活動所用時間的百分比。如果PhysicalDisk: % Disk Time計數器的值較高（大于 90%），請檢查PhysicalDisk: Current Disk Queue Length計數器了解等待進行磁盤訪問的系統請求數量。等待 I/O 請求的數量應該保持在不超過組成物理磁盤的軸數的 1.5 到 2 倍。大多數磁盤只有一個軸，但獨立磁盤冗余陣列 (RAID) 設備通常有多個軸。硬件 RAID 設備在系統監視器中顯示為一個物理磁盤。通過軟件創建的多個 RAID 設備在系統監視器中顯示為多個實例。 可以使用Current Disk Queue Length和% Disk Time計數器的值檢測磁盤子系統中的瓶頸。如果Current Disk Queue Length和% Disk Time計數器的值一直很高，則考慮下列事項：
使用速度更快的磁盤驅動器。
將某些文件移至其他磁盤或服務器。
如果正在使用一個 RAID 陣列，則在該陣列中添加磁盤。
如果使用 RAID 設備，% Disk Time計數器會指示大于 100% 的值。如果出現這種情況，則使用PhysicalDisk: Avg.Disk Queue Length計數器來確定等待進行磁盤訪問的平均系統請求數量。 I/O 依賴的應用程序或系統可能會使磁盤持續處于活動狀態。 監視 Memory: Page Faults/sec計數器可以確保磁盤活動不是由分頁導致的。在 Windows 中，換頁的原因包括：
配置進程占用了過多內存。
文件系統活動。
如果在同一硬盤上有多個邏輯分區，請使用Logical Disk計數器而非Physical Disk計數器。查看邏輯磁盤計數器有助于確定哪些文件被頻繁訪問。當發現磁盤有大量讀/寫活動時，請查看讀寫專用計數器以確定導致每個邏輯卷負荷增加的磁盤活動類型，例如，Logical Disk: Disk Write Bytes/sec。
八、判斷磁盤瓶頸
Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec頁面讀取操作速率很低，則可能存在磁盤瓶徑。 Physical Disk\ Disk Reads/sec and Disk Writes/sec Physical Disk\ Current Disk Queue Length Physical Disk\ % Disk Time LogicalDisk\ % Free Space 測試磁盤性能時，將性能數據記錄到另一個磁盤或計算機，以便這些數據不會干擾您正在測試的磁盤。 可能需要觀察的附加計數器包括 Physical Disk\ Avg.Disk sec/Transfer 、Avg.DiskBytes/Transfer，和Disk Bytes/sec。 Avg.Disk sec/Transfer 計數器反映磁盤完成請求所用的時間。較高的值表明磁盤控制器由于失敗而不斷重試該磁盤。這些故障會增加平均磁盤傳送時間。對于大多數磁盤，較高的磁盤平均傳送時間是大于 0.3 秒。 也可以查看 Avg.Disk Bytes/Transfer 的值。值大于 20 KB 表示該磁盤驅動器通常運行良好;如果應用程序正在訪問磁盤，則會產生較低的值。例如，隨機訪問磁盤的應用程序會增加平均 Disk sec/Transfer 時間，因為隨機傳送需要增加搜索時間。 Disk Bytes/sec 提供磁盤系統的吞吐率。 決定工作負載的平衡要平衡網絡服務器上的負載，需要了解服務器磁盤驅動器的繁忙程度。使用 Physical Disk\ %Disk Time 計數器，該計數器顯示驅動器活動時間的百分比。如果 % Disk Time 較高(超過90%)，請檢查 Physical Disk\ Current Disk Queue Length 計數器以查看正在等待磁盤訪問的系統請求數量。等待 I/O 請求的數量應當保持在不大于組成物理磁盤的主軸數的 1.5 到2倍。 盡管廉價磁盤冗余陣列 (RAID) 設備通常有多個主軸，大多數磁盤有一個主軸。硬件 RAID設備在“系統監視器”中顯示為一個物理磁盤;通過軟件創建的 RAID 設備顯示為多個驅動器(實例)。可以監視每個物理驅動器(而不是 RAID)的 Physical Disk 計數器，也可以使用 _Total 實例來監視所有計算機驅動器的數據。 使用 Current Disk Queue Length 和 % Disk Time 計數器來檢測磁盤子系統的瓶頸。如果Current Disk Queue Length 和 % Disk Time 的值始終較高，可以考慮升級磁盤驅動器或將某些文件移動到其他磁盤或服務器。 Windows操作系統：
（1）%Disk Time %:指所選磁盤驅動器忙于為讀或寫入請求提供服務所用的時間的百分比。如果Physical Disk\ % Disk Time 、Physical Disk\ Avg.Disk Queue Length 、Memory\ Pages/sec三個計數器都比較大，那么硬盤不是瓶頸。如果只有%Disk Time比較大，另外兩個都比較適中，硬盤可能會是瓶頸。在記錄該計數器之前，請在Windows 2000 的命令行窗口中運行diskperf -yD。若數值持續超過80%，則可能是內存泄漏。
（2）Avg.Disk Queue Length:指讀取和寫入請求(為所選磁盤在實例間隔中列隊的)的平均數。該值應不超過磁盤數的1.5~2 倍。要提高性能，可增加磁盤。注意：一個Raid Disk實際有多個磁盤。
（3）Average Disk Read/Write Queue Length: 指讀取(寫入)請求(列隊)的平均數。
（4）Disk Reads(Writes)/s: 物理磁盤上每秒鐘磁盤讀、寫的次數。兩者相加，應小于磁盤設備最大容量。
（5）Average Disksec/Read: 指以秒計算的在此盤上讀取數據的所需平均時間。
（6）verage Disk sec/Transfer: 指以秒計算的在此盤上寫入數據的所需平均時間。
?

通常，我們很容易觀察到數據庫服務器的內存和CPU壓力。但是對I/O壓力沒有直觀的判斷方法。磁盤有兩個重要的參數： Seek time、 Rotational latency。正常的I/O計數為：①1000/(Seek time+Rotational latency)*0.75，在此范圍內屬正常。當達到85％的I/O計數以上時則基本認為已經存在I/O瓶勁。理論情況下，磁盤的隨機讀計數為125、順序讀計數為225。對于數據文件而言是隨機讀寫，日志文件是順序讀寫。因此，數據文件建議存放于RAID5上，而日志文件存放于RAID10或RAID1中。? 下面假設在有4塊硬盤的RAID5中觀察到的Physical Disk性能對象的部分值：? Avg. Disk Queue Length 12? Avg. Disk Sec/Read .035? Avg. Disk Sec/Write .045? Disk Reads/sec 320? Disk Writes/sec 100? Avg. Disk Queue Length，12/4=3，每塊磁盤的平均隊列建議不超過2。? Avg. Disk Sec/Read一般不要超過11～15ms。? Avg. Disk Sec/Write一般建議小于12ms。? 從上面的結果，我們看到磁盤本身的I/O能力是滿足我們的要求的，原因是因為有大量的請求才導致隊列等待，這很可能是因為你的SQL語句導致大量的表掃描所致。在進行優化后，如果還是不能達到要求，下面的公式可以幫助你計算使用幾塊硬盤可以滿足這樣的并發要求：? Raid 0 -- I/Os per disk = (reads + writes) / number of disks Raid 1 -- I/Os per disk = [reads + (2 * writes)] / 2 Raid 5 -- I/Os per disk = [reads + (4 * writes)] / number of disks Raid 10 -- I/Os per disk = [reads + (2 * writes)] / number of disks? 我們得到的結果是：(320+400)/4=180，這時你可以根據公式①來得到磁盤的正常I/O值。假設現在正常I/O計數為125，為了達到這個結果：720/125=5.76。就是說要用6塊磁盤才能達到這樣的要求。? 但是上面的Disk Reads/sec和Disk Writes/sec是個很難正確估算的值。因此只能在系統比較忙時，大概估算一個平均值，作為計算公式的依據。另一個是你很難從客戶那里得到Seek time、 Rotational latency參數的值，這也只能用理論值125進行計算。?

通常，我們很容易觀察到數據庫服務器的內存和CPU壓力。但是對I/O壓力沒有直觀的判斷方法。磁盤有兩個重要的參數： Seek time、 Rotational latency。正常的I/O計數為：①1000/(Seek time+Rotational latency)*0.75，在此范圍內屬正常。當達到85％的I/O計數以上時則基本認為已經存在I/O瓶勁。理論情況下，磁盤的隨機讀計數為125、順序讀計數為225。對于數據文件而言是隨機讀寫，日志文件是順序讀寫。因此，數據文件建議存放于RAID5上，而日志文件存放于RAID10或RAID1中。?

下面假設在有4塊硬盤的RAID5中觀察到的Physical Disk性能對象的部分值：?

Avg. Disk Queue Length 12?

Avg. Disk Sec/Read .035?

Avg. Disk Sec/Write .045?

Disk Reads/sec 320?

Disk Writes/sec 100?

Avg. Disk Queue Length，12/4=3，每塊磁盤的平均隊列建議不超過2。?

Avg. Disk Sec/Read一般不要超過11～15ms。?

Avg. Disk Sec/Write一般建議小于12ms。?

從上面的結果，我們看到磁盤本身的I/O能力是滿足我們的要求的，原因是因為有大量的請求才導致隊列等待，這很可能是因為你的SQL語句導致大量的表掃描所致。在進行優化后，如果還是不能達到要求，下面的公式可以幫助你計算使用幾塊硬盤可以滿足這樣的并發要求：?

Raid 0 -- I/Os per disk = (reads + writes) / number of disks
Raid 1 -- I/Os per disk = [reads + (2 * writes)] / 2
Raid 5 -- I/Os per disk = [reads + (4 * writes)] / number of disks
Raid 10 -- I/Os per disk = [reads + (2 * writes)] / number of disks?

我們得到的結果是：(320+400)/4=180，這時你可以根據公式①來得到磁盤的正常I/O值。假設現在正常I/O計數為125，為了達到這個結果：720/125=5.76。就是說要用6塊磁盤才能達到這樣的要求。?

但是上面的Disk Reads/sec和Disk Writes/sec是個很難正確估算的值。因此只能在系統比較忙時，大概估算一個平均值，作為計算公式的依據。另一個是你很難從客戶那里得到Seek time、 Rotational latency參數的值，這也只能用理論值125進行計算。?
SUM服務器監控軟件對Windows磁盤的IO監控是目前所有監控軟件中最全面。每一項監控內容均為Windows磁盤IO最為核心的項目，是運行磁盤操作量大的應用服務器必須監控的項目。

轉載于:https://blog.51cto.com/bluemood/901595

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的windows下磁盘IO性能数据评测的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。