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用戶態程序高效排錯>