效能監視器- Performance Monitor

【原文：http://www.cnblogs.com/awpatp/archive/2009/12/07/1618504.html】

效能監視器是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使用者態程式高效排錯>