1、常見計數器算法
一、windows系統計數器數據庫
類別 | 計數器名稱 | 計數器描述 |
Memory | Available Mbytes | 可用物理內存數 |
Pages/sec | 代表因爲硬件頁面錯誤而從磁盤取出的頁面數,或因爲頁面錯誤而寫入磁盤以釋放工做集空間的面數 | |
Pages Read/sec | 頁的硬故障,Pages/sec的子集,爲了解析對內存的引用,必須讀取頁文件的次數。其閾值爲5,數值越低越好,大樹枝表示磁盤讀而不是緩存讀 | |
Page Faults/sec | 此值爲處理器中的頁面錯誤的計數。當進程引用特定的虛擬內存頁,該頁不在其主內存的工做集中,將出現頁面錯誤。若是某頁已經位於主內存中,或者它正在被共享該頁的其餘進程所使用,則頁面錯誤不會致使該頁從磁盤中讀取 | |
Cache Bytes | 文件系統緩存,默認狀況下爲50%的可用物理內存 | |
Process | %Processor Time | 被處理器消耗的處理器時間數量。若是專用於某種特定應用,則可用應用相關進程的%Processor Time進行衡量,此時可接受的上限通常不超過85% |
Page Faults/sec | 將進程產生的頁故障與系統產生的相比較,以判斷該進程對系統頁故障產生的影響 | |
Work Set | 處理線程最近使用的內存頁,反映每個進程使用的內存頁的數量。若是服務器有足夠的空閒內存,頁就會被留在工做集中,當自由內存少於一個特定的閾值,頁就會被清除出工做集 | |
Private Bytes | 此進程所分配的沒法與其餘進程共享的當前字節數量。若是系統性能隨着時間而下降,則此計數器能夠是內存泄露的最佳指示器 | |
Processor | %Processor Time | 若是該值持續超過95%,代表瓶頸是CPU,能夠考慮增長一個處理器或換一個更快的處理器 |
%User Time | 非內核操做耗費的CPU時間。通常來講,若是系統中使用了大量的算法或複雜的計算操做,該值會比較大 | |
%Pricileged Time | CPU內核時間是在特權模式下處理線程執行代碼所花時間的百分比 | |
%DPC Time | CPU消耗在網絡處理上的時間,此值越低越好 | |
Physical Disk | %Disk Time | 所選磁盤驅動器忙於爲讀或寫入請求提供服務所用時間的百分比 |
Average Disk Queue Length | 讀取和寫入請求(所選磁盤在實例間隔中列隊)的平均數。該全值應不超過磁盤數的1.5~2倍,要提升性能,可增長磁盤。(一個Raid Disk實際有多個磁盤) | |
DiskReads(Writes)/sec | 物理磁盤上每秒磁盤讀、寫的次數,二者相加應小於磁盤設備的最大容量 | |
Average Disk sec/Read | 以秒計算的在磁盤上讀取數據所需的平均時間 | |
Average Disk sec/Transfer | 以秒計算的在磁盤上寫入數據所需的平均時間 | |
Network Interface | Bytes Total/sec | 爲發送和接受字節的速率,包括幀字符在內。判斷網絡鏈接速度是不是瓶頸,能夠用該計數器的值和目前的寬帶比較 |
System | %Total Processor Time | 系統上全部處理器都忙於執行非空閒線程的平均時間百分比,反映了用於有用做業的時間比率。對單處理器系統來講,該值很容易理解;對於多服務器系統來講,該值體現了全部處理器的平均繁忙程度 |
File Data Operations/sec | 計算機對文件系統設備執行讀取和寫入操做的速率。本計數器的計數不包括文件控制操做 | |
Processor Queue Length | 線程單元中的處理隊列的即時長度。全部處理器都是用單一隊列(線程在該隊列中等待處理器進行循環)。此長度不包括當前正在執行的線程,通常狀況下,若是處理器隊列的長度一直超過服務器上可用處理器的總數量+1,則表示處理器可能堵塞 |
二、IIS應用服務器計數器windows
類別 | 計數器名稱 | 計數器描述 |
Processor | %Total Processor Time | 被處理器消耗的處理器時間數量,對於IIS應用服務器來講,該值通常不該超過85% |
Physical Disk | %Disk Time | 顯示磁盤進行讀/寫活動所花費的時間百分比 |
Memory | Available Bytes | 可用的剩餘物理內存量。IIS基本佔用2.5MB,每一個附加鏈接將在此基礎上佔用10KB左右 |
Pool Paged Bytes and Pool Nonpaged Bytes | 緩衝池,由應用程序和操做系統建立並使用的對象。若是池被填滿,可能發生內存泄露 | |
Pages/sec | 若是服務器沒有足夠的內存處理其工做負荷,此數值將一直很高 | |
Object | Threads | 線程是執行處理器指令的基本可執行實體,若是該值一直持續上升,請打開Process:Threads Count計數器並查看全部線程是由哪一個實例建立的 |
Process | Private Bytes Total | 顯示全部實例已經分配但沒法與其餘進程共享的當前字節數 |
1)Active Server Page計數器緩存
重點須要關注超時的請求數、腳本運行時期的錯誤、隊列中的請求數、請求等待時間、請求總數、失敗的請求總數和送出的總字節數。服務器
隊列中的請求數和請求等待時間直接反映應用服務器的處理能力,若是隊列中的請求數數值處於一個比較高的水平,同時請求等待時間是一個比較大的值,則應用服務器自己是瓶頸,須要解決。腳本運行時期的錯誤、請求總數、失敗的請求總數和送出的總字節數均可以與測試工具在測試過程當中得到的吞吐量、請求數等進行對比,從而肯定數據的可信度。網絡
2)Web Service計數器session
①Bytes Total/Sec:顯示Web服務器發送和接收的總字節數。低數值代表該IIS正在以較低的速度進行數據傳輸;ide
②Connection Refused:數值越低越好,高數值代表網絡適配器或處理器存在瓶頸;函數
③Not Found Errors:顯示因爲被請求文件沒法找到而沒法由服務器知足的請求數(http status=404)工具
3)dotNET計數器(略,查看官方文檔)
三、J2EE應用服務器計數器
類別 | 計數器名稱 | 計數器描述 |
JVM | Heap Size | JVM堆大小,該計數器的值是一個實時值 |
Heap Free | JVM可用堆大小,該計數器的值是一個實時值 | |
JDBC Connection Pool | Waiting For Connection Current Count | 等待的鏈接數量,若是該值持續較大,可能須要考慮增長應用服務器的JDBC鏈接池大小 |
Connections Total Count | 總的JDBC鏈接數 | |
Max Capacity | JDBC鏈接池的總容量。能夠經過該計數器和上兩個計數器值的比較,得到鏈接池設置是否合理的結論 | |
Active Connections Current Count | 當前活躍的JDBC鏈接數,分析該值能夠知道JDBC鏈接的利用率是否合理 | |
Execute Queue | Execute Thread Current Idle Count | 空閒的線程數量 |
Pending Request Oldest Time | 隊列請求的最久時間。該值能夠看到隊列有無明顯的擁塞狀況 | |
Serviced Request Total Count | 已處理的請求總數。該值能夠用來和性能測試工具測試後獲得的單擊數進行對比 | |
Pending Request Current Count | 掛起請求的數量 |
四、數據庫服務器計數器
類別 | 計數器名稱 | 計數器描述 |
System | Total Processor Time | 數據庫進程佔用的CPU時間。不一樣的數據庫有不一樣的名稱,例在Oracle中被稱爲cpu used by thisession |
User Connections | 當前用戶鏈接數。數據庫服務器通常都有用戶數連擊數的限制,應用不合理時,有可能出現鏈接數超過限制的狀況,致使一些異常的發生 | |
Memory | Cache Hit Ratio | 緩存命中率。當該值比較小,而數據庫比較繁忙時,可能須要調整緩存的大小 |
Total Server Memory(僅適用於SQL Server) | 進程當前使用的內存量。結合其餘計數器(ConnectionMemory、Lock Memory等)能夠很清楚知道Memory的使用狀況 | |
PGA Memory/UGA Memory(僅適用於Oracle) | Oracle數據庫進程的內存使用狀況 | |
Lock | Average Wait Time | 鎖平均等待時間 |
Lock Requesets/sec | 每秒的鎖請求數 | |
Number of Deadlocks/sec | 每秒產生的死鎖數量,當該值比較大時,須要查詢產生死鎖的緣由 | |
I/O | Outstanding Reads(Writes) | 被掛起的物理讀(寫),當該值比較大時,多是CPU、磁盤I/O產生了瓶頸,能夠經過服務器的CPU和I/O進一步分析緣由 |
Page Read/sec | 每秒頁面讀寫的次數 | |
Transactions/sec | 每秒產生的事務數量 |
2、分析方法(針對操做系統)
一、內存分析方法
1)查看Memory\Available Mbytes指標
該值是描述系統可用內存的直接指標,在對系統進行操做系統級別的內存分析時,首先經過該指標創建一個初步的印象,瞭解系統是否有足夠的內存可用。若是值比較小,系統可能出現內存方面的問題,須要進一步分析。
PS:在Unix/Linux系統中,對應的指標是Free(KB)。
2)注意Pages/sec、Pages Read/sec和Page Faults/sec的值
操做系統常常會利用磁盤交換的方式提升系統可用的內存量或內存的使用效率,這三個指標直接反映了操做系統進行磁盤交換的頻度。若是Pages/sec的計數持續高於幾百?極可能會有內存方面的問題產生,但值很大不必定代表內存有問題,多是運行使用內存映射文件的程序所致。Pages Faults/sec值表示每秒發生頁面失效的次數,頁面失效次數越多,說明操做系統向內存中讀取的次數越多。此時還須要查看Pages Read/sec,此值閾值爲5,若是計數值超過5,則能夠判斷存在內存方面的問題。
PS:在Unix/Linux系統中,對應的指標是(page)si和(page)so。
3)根據Physical Disk計數器的值分析性能瓶頸
若是Pages Read/sec很低,同時%Disk Time和Average Disk Queue Length的值很高,則可能有磁盤瓶頸。可是若是隊列長度增長的同時Pages Read/sec並未下降,則是因爲內存不足。
PS:在Unix/Linux系統中,對應的指標是Read(Writes)per sec、Percent of time the disk is busy和Average number of transactions waiting for service。
二、處理器分析方法
1)查看System\%Total Processor Time性能計數器的計數值
此值體現服務器總體的處理器利用率。對多處理系統而言,體現的是全部CPU的平均利用率。若是該值持續超過90%,則說明整個系統面臨着處理器方面的瓶頸,能夠增長處理器來提升性能。在某些多CPU系統中,該數據自己並不大,可是CPU之間的負載狀態很不均衡,也能夠視爲系統產生了處理器方面的瓶頸。
2)查看每一個CPU的Processor\%Processor Time、Processor\%User Time和Processor\%Privileged Time
若是Processor\%User Time值較大,能夠考慮是否能經過算法優化等方法優化該值,若是服務器是數據庫,Processor\%User Time值打的緣由極可能是數據庫的排序或是函數操做消耗了過多的CPU時間,此時能夠考慮對數據庫系統進行優化。
3)研究系統處理器瓶頸
查看System\Processor Queue Length計數器的值,當大於CPU總量+1時,說明產生了處理器堵塞,在處理器的%Process Time值很高時通常都伴隨着處理器堵塞。反之則否則,此時必須查找處理器堵塞的緣由。
%DPC Time是另外一個須要關注的,該計數值越低越好。在多處理器系統中,若是該值大於50%且Processor\%Processor Time值比較高,則考慮加一個網卡來提升性能。
三、磁盤I/O分析方法
1)計算每磁盤的I/O數
每磁盤的I/O數可用來與磁盤的I/O能力進行對比,若是通過計算獲得的每磁盤的I/O數超過了磁盤標稱的I/O能力,則說明肯定存在磁盤的性能瓶頸。
每磁盤的I/O的計算方法 | |
Raid類型 | 計算方法 |
Raid0 | (Reads+Writes)/Number of Disks |
Raid1 | (Read+2*Writes)/2 |
Raid5 | (Read+4*Writes)/Number of Disks |
Raid10 | (Read+2*Writes)/Number of Disks |
2)與Processor\Privileged Time組合進行分析
若是在Physical Disk計數器中,只有%Disk Time值較大,其餘值適中,則硬盤可能會是瓶頸。若幾個值都比較大,且數值持續超過80%,則多是內存泄露。
3)根據Disk sec/Transfer進行分析
通常來講,定義Transfer數值小於15ms爲優秀,15~30ms之間爲良好,30~60ms之間能夠接受,超過60ms則須要考慮更換硬盤或者硬盤的Raid方式了。
四、進程分析方法
1)查看進程的%Processor Time值
該值反映進程消耗的處理器時間。不一樣進程進行對比,能夠輕易看出具體哪一個進程在測試過程當中消耗了最多的處理器時間,從而據此針對應用進行優化。
2)查看每一個進程產生的頁面失效
Process\Page Failures/sec與Memory\Page Failures/sec的比值,判斷哪一個進程產生了最多的頁面失效,該進程要麼是須要大量內存的進程,要麼是很是活躍的進程,能夠對其進行重點分析。
3)瞭解進程的Process\Private Bytes
該值指進程所分配的沒法與其餘進程共享的當前字節數量,主要用來判斷進程在性能測試過程當中有無內存泄露。例如一個在IIS上的Web應用,若是測試過程當中,進程的Private Bytes計數值不斷增長或是測試中止一段時間後,該值仍然持續在高水平,則說明應用存在內存泄露。
PS:在Unix/Linux系統中,對應的指標是Resident Size。
五、網絡分析方法
通常的公司都有專門的網絡管理人員,網絡分析是門技術活,此處僅描述Network Interface\Bytes Total/sec的值。Network Interface\Bytes Total/sec爲發送和接收字節的速率(包括幀字符),能夠經過該計數器的值和目前網絡的帶寬進行比較來判斷網絡鏈接速度是不是瓶頸。
PS:在Unix/Linux系統中,能夠參照Unix/Linux系統提供的snmp服務接口進行網絡分析。