Windows 效能監控器的基本指標（CPU,記憶體,硬碟參數）

標籤：

轉載：http://kms.lenovots.com/kb/article.php?id=7045

Windows 效能監控器的基本指標（CPU,記憶體,硬碟參數）

 

作為一個系統工程師來說，要看懂監控的資料至關重要，關係著最佳化和分析出現的問題，因此，今天給出Windows 效能監控器的一些基本指標（CPU,記憶體,硬碟參數），希望對大家將來最佳化和分析問題提供幫忙。 Windows -Processor 指標名稱 指標描述 指標範圍 指標單位 CPU利用率 （% Processor Time） % Processor Time指處理器執行非閑置線程時間的百分比。這個計數器設計成用來作為處理器活動的主要指標。它通過在每個時間間隔中衡量處理器用於執行閑置處理線程的時間，並且用100%減去該值得出。可將其視為範例間隔用於做有用工作的百分比。 根據應用系統情況，在80%±5%範圍內波動為宜。過低，則伺服器CPU利用率不高；過高，則CPU可能成為系統的處理瓶頸。 % 中斷率 （Interrupts/sec.） 每秒鐘裝置中斷處理器的次數。在完成一個任務或需要注意時，裝置會發出中斷訊號給處理器。可以產生中斷的裝置包括系統定時器、滑鼠、資料通訊聯機、網路卡以及其它的外部裝置。在中斷過程中，一般的執行緒執行將被暫停，而且一個中斷可以使處理器切換到另一個具有較高優先等級的執行緒。頻率中斷是頻繁和周期性的，並且中斷動作在背景執行。 取決於處理器，越低越好；不宜超過1,000； 如果該值顯著增加而系統活動沒有相應的增加，則表明存在硬體問題，需要檢查引起中斷的網路介面卡、磁碟或其他硬體。 次/sec 系統調用率 System Call/sec. 指運行在電腦上的所有處理器叫用作業系統服務例行程式的綜合速率。這些例行程式執行所有在電腦上的如安排和同步活動等基本的程式，並提供對非圖形裝置、記憶體管理和名稱空間管理的訪問。 如果Interrupts/sec大於System Calls/sec.,則系統中某一硬體裝置產生過多的中斷。 次/sec Processor Queue Length 處理器隊列的線程數量。此計數器只顯示就緒線程，而不是正在啟動並執行線程。 如果處理器隊列中總是有兩個以上的線程通常表示處理器堵塞。   進程切換率 Context Switches/sec 指電腦上的所有處理器全都從一個線程轉換到另一個線程的綜合速率。當正在啟動並執行線程自動放棄處理器時出現上下文轉換，由一個有更高優先就緒的線程佔先或在使用者模式和特權 (核心) 模式之間轉換以使用執行或分系統服務 如果此計數器的數值較大，則表明鎖定競爭很激烈，或者線程在使用者和核心模式之間頻繁切換。   Windows -Memory  指標名稱 指標描述 指標範圍 指標單位 Pages/sec Pages Input/sec Pages Output/sec Page Fault/sec Page Faults/sec 是處理器每秒鐘處理的錯誤頁（包括軟性錯誤和硬性錯誤）。Pages Input/sec 是為瞭解決硬性錯誤頁，從硬碟上讀取的頁數， 而Page Reads/sec是為瞭解決硬性錯誤，從硬碟讀取的次數。Pages/sec是Pages Input/sec 和Pages Output/sec 的總和。 該系列指標是可以顯示導致系統範圍延緩類型錯誤的主要指標。 當處理器向記憶體指定的位置請求一頁（可能是資料或代碼）出現錯誤時，這就構成一個Page Fault。如果該頁在記憶體的其他位置，該錯誤被稱為軟性錯誤（ 用Transition Fault/sec衡量）； 如果該頁必須從硬碟上重新讀取時， 被稱為硬性錯誤。許多處理器可以在有大軟性錯誤的情況下繼續操作。但是， 硬性錯誤可以導致明顯的拖延。 如果Page Reads/Sec持續保持為5，表示可能記憶體不足。Page/sec推薦0-20。如果伺服器沒有足夠的記憶體處理其工作負載，此數值將一直很高。如果大於80，表示有問題(太多的讀寫資料操作要訪問磁碟，可考慮增加記憶體或最佳化讀寫資料的演算法)。 該系列計數器的值比較低， 說明響應請求比較快， 否則可能是伺服器系統記憶體短缺引起（也可能是緩衝太大， 導致系統記憶體太少）。 次/sec Available Bytes 顯示出當前閒置實體記憶體總量，它等於分配給待機(緩衝的)、空閑和零分頁列表記憶體的總和。 空閑記憶體可以馬上使用; 清零記憶體是由零值填滿的記憶體頁，用來防止後續進程獲得舊進程使用的資料; 待機記憶體是從進程工作集(其實體記憶體)中刪除然後進入磁碟的記憶體，但是該記憶體仍然可以收回。該指標僅顯示最後一次觀察到的值，不是平均值。 當這個數值變小時，Windows開始頻繁地調用磁碟分頁檔。如果這個數值很小，例如小於5 MB，系統會將大部分時間消耗在操作分頁檔上。 一般要保留10%的可用記憶體。最低不能<4M，此值過小可能是記憶體不足或記憶體流失。   Committed Bytes 是指以位元組表示的確認虛擬記憶體，是磁碟分頁檔上保留空間的實體記憶體。 不超過實體記憶體的 75%           Windows – Disk  指標名稱 指標描述 指標範圍 指標單位 % Disk Time 指所選磁碟機忙於為讀或寫入請求提供服務所用的時間的百分比。 正常值<10，此值過大表示耗費太多時間來訪問磁碟，可考慮增加記憶體、更換更快的硬碟、最佳化讀寫資料的演算法。若數值持續超過80 (此時處理器及網路連接並沒有飽和)，則可能是記憶體流失。   Current Disk Queue Length 是在收集效能資料時磁碟上當前的請求數量。它還包括在收集時處於服務的請求。這是瞬間的快照，不是時間間隔的平均值。多軸磁碟裝置能有一次處於運行狀態的多重請求，但是其他同期請求正在等待服務。此計數器會反映暫時的高或低的隊列長度，但是如果磁碟機被迫持續運行，它有可能一直處於高的狀態。 請求的延遲與此隊列的長度減去磁碟的軸數成正比。為了提高效能，此差應該平均小於二。   Avg.Disk Queue Length Avg. Disk Read Queue Length Avg. Disk Write Queue Length 指讀取和寫入請求(為所選磁碟在執行個體間隔中列隊的)的平均數。 Avg.Disk Queue Length正常值<0.5，此值過大表示磁碟IO太慢，要更換更快的硬碟。

 

效能監控器- Performance Monitor

效能監控器是Windows內建的系統資源和效能監控工具. 效能監控器能夠量化地提供CPU使用率, 記憶體配置狀況, 異常派發情況, 線程調度頻率等資訊. ASP.NET能夠提供每秒鐘的請求數目, 請求回應時間等等. 效能監控器能夠監視一段時間內上述資源的利用情況, 提供平均值和峰值.

 

效能監控器有助於擷取關於效能的具體指標, 監視問題出現時系統資源的變化情況. 通過檢查效能監控器中一些重要計數器的變化情況, 往往能夠找到一些比較有用的線索. 比如比較ASP.NET每秒請求數目, 請求回應時間和CPU利用率是否有相同的變化曲線就能看出效能是否跟負載相關.

 

解決效能問題的時候, 往往會讓客戶添加下面一些計數器進行效能收集.

• Process object下的所有計數器
• Processor object下的所有計數器
• System object下的所有計數器
• Memory object下的所有計數器
• 如果客戶的程式時.NET程式, 還會添加以.NET開頭的object下的所有計數器.
• 如果客戶使用ASP.NET, 還會添加以ASP.NET開頭的object下的所有計數器.

分析效能日誌的時候, 重點觀察下面這些計數器.

 

Process object

=============

Process object中的計數器可以根據目標進程分析記憶體, CPU, 線程數目和handle數目. 選出問題的目標進程, 然後分析目標進程的下面一些計數器.

 

%Processor Time

-------------------

該計數器是該進程佔用CPU資源的指標. 即便進程繁忙的時候, CPU平均佔用率應該在80%以內. 如果超過該數值, 可以認為程式發生了高CPU的問題. 另外一種問題是CPU波動幅度大. 雖然平均佔用率不高, 但是上下跳動頻繁. 在某一個短時間段裡面, 會有連續高CPU的情況出現.

 

Handle Count

------------------

該計數器記錄了當前進程使用的kernel object handle數量. Kernel object是重要的系統資源. 當程式進入穩定運行狀態的時候, Handle Count數量也應該維持在一個穩定的區間. 如果發現Handle Count在整個程式周期內總體趨勢連續向上, 應該考慮程式是否有Handle Leak.

 

ID Process

------------------

該計數器記錄了目標進程的進程ID. 你可能覺得奇怪, ID有什麼好觀察的? 進程ID是用來觀察程式是否有重啟發生. 比如ASP.NET背景工作處理序可能會自動回收. 由於進程名都相同, 所以只有通過進程ID來判斷是否有重新啟動現象. 如果ID有變化, 那麼而看看程式是否發生崩潰或者Recycle.

 

Private Bytes

------------------

該計數器記錄了當前通過VirtualAlloc API進行的, Commit了的Memory數量. 無論是直接調用API申請的記憶體, Heap Manager申請的記憶體, 還是CLR的managed heap, 都算在裡面. 跟Handle Count一樣, 如果在整個程式周期內總體趨勢連續向上, 說明有Memory Leak.

 

Virtual Bytes

------------------

該計數器記錄了當前進程申請成功的使用者態總記憶體位址, 包括DLL/EXE佔用的地址和通過VirtualAlloc API進行的, Reserve了的記憶體位址數量, 所以該計數器應該總大於Private Bytes. 一般說來, Virtual Bytes與Private Bytes的變化大致一致. 由於記憶體分區的存在, Virtual Bytes與Private Bytes一般保持一個相對穩定的比例關係. 當Virtual Bytes與Private Bytes的比例大於2的時候, 程式往往有比較嚴重的記憶體位址分區.

 

Processor object

==============

Processor object記錄系統中晶片的負載情況. 由於普通程式並不可以綁定到某個具體的CPU上執行, 所以在多CPU機器上觀察Total Instance也就足夠了.

 

%Processor Time

----------------------

該計數器跟Process下的%Processor Time的意義一樣, 不過這裡記錄的不是針對具體的某一個進程, 而是整個系統. 通過把該計數器跟Process下的同名計數器一起比較, 就能看出系統的高CPU問題是否是由於單一的某個進程導致的.

 

System object

==============

System object記錄系統中一個整體的統計資訊. 所以不區分instance. 通過比較System object下的counter和其他counter的變化趨勢, 往往能看出一些線索.

 

Context Switch/ sec

--------------------

Context Switch標示了系統中整體線程的調度, 切換頻率. 線程切換是開銷比較大的操作. 頻繁的線程切換回導致大量CPU周期被浪費. 所以當看到高CPU的時候, 一定要與Context Switch一起比較. 如果兩者有相同的變化趨勢, 高CPU往往是由於contention(線路爭奪)導致的, 而不是死迴圈.

 

Exception Dispatches/ sec

-------------------

Exception Dispatches表示了系統中異常派發, 處理的頻繁程度. 跟線程切換一樣, 異常處理也需要大量的CPU開銷. 分析方法跟Context Swith雷同.

 

File Data Operations/ sec

-------------------

File Data Operations記錄了當前系統中磁碟檔案讀寫的頻繁程度. 通過觀察該計數器跟其他效能指標的變化趨勢, 能夠判斷磁碟檔案操作是否是效能瓶頸. 類似的計數器還有Network Interface, Bytes Total/ sec

 

Memory Object

=============

Memory object記錄了當前系統中整體記憶體的統計資訊.

 

Avaiable Mbytes 和 Committed Bytes

---------------------

Available Mbytes記錄了當前剩餘的實體記憶體數量. Committed Bytes記錄了所有進程commit的記憶體數量. 結合兩個計數器可以觀察到:

1. 兩者相加可以粗數量級估計系統總體可用記憶體的多少, 便於估計物理配置.
2. 當Available Mbytes少於100MB的時候, 說明系統總體記憶體緊張, 會影響到系統所有進程的效能. 應該考慮增加實體記憶體或檢查記憶體泄露.
3. 通過比較Process object中的Private Bytes和Virtual Bytes, 便於進一步確認是否有記憶體泄露, 判斷記憶體泄露是否是由某一單個進程導致的.

Free System Page Table Entries, Pool Paged Bytes 和 Pool Nonpaged Bytes

--------------------

這三個計數器可以衡量核心態空閑記憶體的數量. 特別是當使用/3GB開關後, 核心態記憶體位址被壓縮, 容易導致核心態記憶體不足, 繼而引發一些非常奇怪的問題.

 

.NET CLR Memory object

=============

.NET CLR Memory object記錄了CLR進程中跟CLR相關的記憶體資訊. 該類別下的所有計數器都很有趣, 意思也非常直接. 建議用一個例子程式進行測試和研究. 下面是兩個最常用的計數器.

 

Bytes in all heaps

----------------------

Bytes in all heaps 記錄了上次GC發生時所統計到的, 進程中不能被回收的所有CLR object佔用的記憶體空間. 該計數器不是即時的, 每次GC發生的時候, 該計數器才更新. 與同一進程的Process下的Private Bytes比較, 可以區分出managed heap和native memory的變化情況. 對於memory leak, 便於區分是managed heap的leak, 還是native memory 的leak.

 

%Time in GC

%Time in GC記錄了GC發生的頻繁程度. 一般來說15%以內算比較正常. 當超過20%時, 說明GC發生過於頻繁. 由於GC不僅帶來很高的CPU開銷, 而且還需要掛起目標進程的CLR線程, 所以高頻率GC是非常危險的. 通過跟CPU利用率和其他效能指標的比較, 往往能夠看出GC對效能的影響. 高頻率的GC往往因為:

1. 負載過高.
2. 不合理的架構, 對記憶體使用量率不高.
3. 記憶體泄露, 記憶體片段導致記憶體壓力.

ASP.NET的效能監控

============

如果目標程式時ASP.NET, 在ASP.NET開頭的object中, 下面這些計數器對於測量ASP.NET的效能非常有用. 由於不少計數器存在於多個object 類別中, 下面只列出具體的計數器名字, 而不去對應到具體的object.

 

Application Restarts

-------------------

Application Restarts記錄了ASP.NET Application Domain重啟的次數. 導致ASP.NET appDomain重啟的原因往往是虛擬目錄被修改. 比如修改了web.config檔案, 或者防毒程式對母你目錄進行了掃描. 通過該計數器可以觀察是否有異常的重啟現象.

 

Request Execution Time

-------------------

Request Execution Time記錄了請求的執行時間, 它是衡量ASP.NET效能的最直接參數. 通過該計數器的平均值來衡量效能是否合乎預期. 需要注意的地方是: 由於Windows並非即時系統, 所以不能用峰值來衡量整體效能. 比如當GC發生的時候, 請求執行時間肯定要超過GC的時間. 所以, 平均值才是有效標準.

 

Request Current

-------------------

Request Current記錄了當前正在處理的和等待處理的請求. 最理想的情況是Request Current等於CPU的數量, 這說明請求與硬體資源能並發處理的能力恰好吻合, 硬體投資正運行在最優狀態. 但是一般說來, 當負荷比較大的時候, Request Current也隨著增高. 如果Request Current在一段時間內有超過10的情況, 說明效能有問題. 注意觀察此時對應的CPU情況和其他的資源. 如果CPU不高, 很可能是是程式中有Blocking發生, 比如等待資料庫請求, 導致請求無法及時完成.

 

Request/ second

------------------

Request/ second計數器記錄了每秒鐘到達ASP.NET的請求數. 這是衡量ASP.NET負載的直接參數. 注意觀察Request/ second是否超過程式預期的輸送量. 如果Request/ second 有突發的波動, 注意看是否有拒絕服務的攻擊. 通過把Request/second, Request Current, Request Execution Time和系統資源一起比較, 往往能夠看出ASP.NET整體效能的變化和各個因素之間的影響.

 

Request in Application Queue

------------------

當ASP.NET沒有空餘的背景工作執行緒來處理新進入的請求的時候, 新的請求會被放到Application Queue中. 當Application Queue堆積的請求也超過設定數值的時候, ASP.NET直接返回503 Server Too Busy錯誤, 同時丟棄該請求. 所以正常情況下, Request Application Queue應該總為0, 否則說明已經有請求堆積, 效能問題嚴重.

 

摘自<Windows使用者態程式高效排錯>

 

Windows 效能監控器的基本指標（CPU,記憶體,硬碟參數）