性能監(jiān)視器是Windows自帶的系統(tǒng)資源和性能監(jiān)視工具. 性能監(jiān)視器能夠量化地提供CPU使用率, 內(nèi)存分配狀況, 異常派發(fā)情況, 線程調(diào)度頻率等信息. ASP.NET能夠提供每秒鐘的請(qǐng)求數(shù)目, 請(qǐng)求響應(yīng)時(shí)間等等. 性能監(jiān)視器能夠監(jiān)視一段時(shí)間內(nèi)上述資源的利用情況, 提供平均值和峰值。
性能監(jiān)視器有助于獲取關(guān)于性能的具體指標(biāo), 監(jiān)視問(wèn)題出現(xiàn)時(shí)系統(tǒng)資源的變化情況. 通過(guò)檢查性能監(jiān)視器中一些重要計(jì)數(shù)器的變化情況, 往往能夠找到一些比較有用的線索. 比如比較ASP.NET每秒請(qǐng)求數(shù)目, 請(qǐng)求響應(yīng)時(shí)間和CPU利用率是否有相同的變化曲線就能看出性能是否跟負(fù)載相關(guān)。
解決性能問(wèn)題的時(shí)候, 往往會(huì)讓客戶添加下面一些計(jì)數(shù)器進(jìn)行性能收集。
分析性能日志的時(shí)候, 重點(diǎn)觀察下面這些計(jì)數(shù)器.
=============
Process object中的計(jì)數(shù)器可以根據(jù)目標(biāo)進(jìn)程分析內(nèi)存, CPU, 線程數(shù)目和handle數(shù)目. 選出問(wèn)題的目標(biāo)進(jìn)程, 然后分析目標(biāo)進(jìn)程的下面一些計(jì)數(shù)器.
%Processor Time
-------------------
該計(jì)數(shù)器是該進(jìn)程占用CPU資源的指標(biāo). 即便進(jìn)程繁忙的時(shí)候, CPU平均占用率應(yīng)該在80%以內(nèi). 如果超過(guò)該數(shù)值, 可以認(rèn)為程序發(fā)生了高CPU的問(wèn)題. 另外一種問(wèn)題是CPU波動(dòng)幅度大. 雖然平均占用率不高, 但是上下跳動(dòng)頻繁. 在某一個(gè)短時(shí)間段里面, 會(huì)有連續(xù)高CPU的情況出現(xiàn).
Handle Count
------------------
該計(jì)數(shù)器記錄了當(dāng)前進(jìn)程使用的kernel object handle數(shù)量. Kernel object是重要的系統(tǒng)資源. 當(dāng)程序進(jìn)入穩(wěn)定運(yùn)行狀態(tài)的時(shí)候, Handle Count數(shù)量也應(yīng)該維持在一個(gè)穩(wěn)定的區(qū)間. 如果發(fā)現(xiàn)Handle Count在整個(gè)程序周期內(nèi)總體趨勢(shì)連續(xù)向上, 應(yīng)該考慮程序是否有Handle Leak.
ID Process
------------------
該計(jì)數(shù)器記錄了目標(biāo)進(jìn)程的進(jìn)程ID. 你可能覺(jué)得奇怪, ID有什么好觀察的? 進(jìn)程ID是用來(lái)觀察程序是否有重啟發(fā)生. 比如ASP.NET工作進(jìn)程可能會(huì)自動(dòng)回收. 由于進(jìn)程名都相同, 所以只有通過(guò)進(jìn)程ID來(lái)判斷是否有重新啟動(dòng)現(xiàn)象. 如果ID有變化, 那么而看看程序是否發(fā)生崩潰或者Recycle.
Private Bytes
------------------
該計(jì)數(shù)器記錄了當(dāng)前通過(guò)VirtualAlloc API進(jìn)行的, Commit了的Memory數(shù)量. 無(wú)論是直接調(diào)用API申請(qǐng)的內(nèi)存, Heap Manager申請(qǐng)的內(nèi)存, 還是CLR的managed heap, 都算在里面. 跟Handle Count一樣, 如果在整個(gè)程序周期內(nèi)總體趨勢(shì)連續(xù)向上, 說(shuō)明有Memory Leak.
Virtual Bytes
------------------
該計(jì)數(shù)器記錄了當(dāng)前進(jìn)程申請(qǐng)成功的用戶態(tài)總內(nèi)存地址, 包括DLL/EXE占用的地址和通過(guò)VirtualAlloc API進(jìn)行的, Reserve了的內(nèi)存地址數(shù)量, 所以該計(jì)數(shù)器應(yīng)該總大于Private Bytes. 一般說(shuō)來(lái), Virtual Bytes與Private Bytes的變化大致一致. 由于內(nèi)存分片的存在, Virtual Bytes與Private Bytes一般保持一個(gè)相對(duì)穩(wěn)定的比例關(guān)系. 當(dāng)Virtual Bytes與Private Bytes的比例大于2的時(shí)候, 程序往往有比較嚴(yán)重的內(nèi)存地址分片.
==============
Processor object記錄系統(tǒng)中芯片的負(fù)載情況. 由于普通程序并不可以綁定到某個(gè)具體的CPU上執(zhí)行, 所以在多CPU機(jī)器上觀察Total Instance也就足夠了.
%Processor Time
----------------------
該計(jì)數(shù)器跟Process下的%Processor Time的意義一樣, 不過(guò)這里記錄的不是針對(duì)具體的某一個(gè)進(jìn)程, 而是整個(gè)系統(tǒng). 通過(guò)把該計(jì)數(shù)器跟Process下的同名計(jì)數(shù)器一起比較, 就能看出系統(tǒng)的高CPU問(wèn)題是否是由于單一的某個(gè)進(jìn)程導(dǎo)致的.
==============
System object記錄系統(tǒng)中一個(gè)整體的統(tǒng)計(jì)信息. 所以不區(qū)分instance. 通過(guò)比較System object下的counter和其他counter的變化趨勢(shì), 往往能看出一些線索.
Context Switch/ sec
--------------------
Context Switch標(biāo)示了系統(tǒng)中整體線程的調(diào)度, 切換頻率. 線程切換是開銷比較大的操作. 頻繁的線程切換回導(dǎo)致大量CPU周期被浪費(fèi). 所以當(dāng)看到高CPU的時(shí)候, 一定要與Context Switch一起比較. 如果兩者有相同的變化趨勢(shì), 高CPU往往是由于contention(線路爭(zhēng)奪)導(dǎo)致的, 而不是死循環(huán).
Exception Dispatches/ sec
-------------------
Exception Dispatches表示了系統(tǒng)中異常派發(fā), 處理的頻繁程度. 跟線程切換一樣, 異常處理也需要大量的CPU開銷. 分析方法跟Context Swith雷同.
File Data Operations/ sec
-------------------
File Data Operations記錄了當(dāng)前系統(tǒng)中磁盤文件讀寫的頻繁程度. 通過(guò)觀察該計(jì)數(shù)器跟其他性能指針的變化趨勢(shì), 能夠判斷磁盤文件操作是否是性能瓶頸. 類似的計(jì)數(shù)器還有Network Interface, Bytes Total/ sec
=============
Memory object記錄了當(dāng)前系統(tǒng)中整體內(nèi)存的統(tǒng)計(jì)信息.
Avaiable Mbytes 和 Committed Bytes
---------------------
Available Mbytes記錄了當(dāng)前剩余的物理內(nèi)存數(shù)量. Committed Bytes記錄了所有進(jìn)程commit的內(nèi)存數(shù)量. 結(jié)合兩個(gè)計(jì)數(shù)器可以觀察到:
Free System Page Table Entries, Pool Paged Bytes 和 Pool Nonpaged Bytes
--------------------
這三個(gè)計(jì)數(shù)器可以衡量核心態(tài)空閑內(nèi)存的數(shù)量. 特別是當(dāng)使用/3GB開關(guān)后, 核心態(tài)內(nèi)存地址被壓縮, 容易導(dǎo)致核心態(tài)內(nèi)存不足, 繼而引發(fā)一些非常奇怪的問(wèn)題.
=============
.NET CLR Memory object記錄了CLR進(jìn)程中跟CLR相關(guān)的內(nèi)存信息. 該類別下的所有計(jì)數(shù)器都很有趣, 意思也非常直接. 建議用一個(gè)例子程序進(jìn)行測(cè)試和研究. 下面是兩個(gè)最常用的計(jì)數(shù)器.
Bytes in all heaps
----------------------
Bytes in all heaps 記錄了上次GC發(fā)生時(shí)所統(tǒng)計(jì)到的, 進(jìn)程中不能被回收的所有CLR object占用的內(nèi)存空間. 該計(jì)數(shù)器不是實(shí)時(shí)的, 每次GC發(fā)生的時(shí)候, 該計(jì)數(shù)器才更新. 與同一進(jìn)程的Process下的Private Bytes比較, 可以區(qū)分出managed heap和native memory的變化情況. 對(duì)于memory leak, 便于區(qū)分是managed heap的leak, 還是native memory 的leak.
%Time in GC
%Time in GC記錄了GC發(fā)生的頻繁程度. 一般來(lái)說(shuō)15%以內(nèi)算比較正常. 當(dāng)超過(guò)20%時(shí), 說(shuō)明GC發(fā)生過(guò)于頻繁. 由于GC不僅帶來(lái)很高的CPU開銷, 而且還需要掛起目標(biāo)進(jìn)程的CLR線程, 所以高頻率GC是非常危險(xiǎn)的. 通過(guò)跟CPU利用率和其他性能指標(biāo)的比較, 往往能夠看出GC對(duì)性能的影響. 高頻率的GC往往因?yàn)?
ASP.NET 支持兩組性能計(jì)數(shù)器：系統(tǒng)和應(yīng)用程序。前者在 ASP.NET 性能計(jì)數(shù)器對(duì)象中的 PerfMon 中公開；后者在 ASP.NET applications 性能對(duì)象中公開。ASP.NET 性能對(duì)象中的 State Server sessions 計(jì)數(shù)器（僅適用于在其中運(yùn)行狀態(tài)服務(wù)器的服務(wù)器計(jì)算機(jī)）和 ASP.NET Applications 性能對(duì)象中的 Sessions 計(jì)數(shù)器（僅適用于進(jìn)程中發(fā)生的用戶會(huì)話）之間存在很大的差異。
在監(jiān)視 ASP.NET Web 應(yīng)用程序的性能時(shí)，應(yīng)該始終跟蹤下表中列出的性能計(jì)數(shù)器。
性能對(duì)象 | 性能計(jì)數(shù)器 |
ASP.NET | Application Restarts |
ASP.NET | Requests Queued |
ASP.NET | Worker Process Restarts |
ASP.NET Applications | Errors Total |
ASP.NET Applications | Requests/Sec |
Processor | % CPU Utilization |
ASP.NET 支持以下 ASP.NET 系統(tǒng)性能計(jì)數(shù)器。它們匯集 Web 服務(wù)器計(jì)算機(jī)上所有 ASP.NET 應(yīng)用程序的信息，或者它們通常應(yīng)用于運(yùn)行相同應(yīng)用程序的 ASP.NET 服務(wù)器的系統(tǒng)。它們可能包含 Web 場(chǎng)和 Web 園。
