LR圖文分析（精品）

1、具體實(shí)例教你如何做loadrunner結(jié)果分析作者11修改日期11簡單描述1姜全堯1 07. 07. 10i增加對監(jiān)視參數(shù)的解釋，修改部分描述11. 前呂:roadrunner最重要也是最難理解的地方-測試結(jié)果的分析.其余的錄制和 加壓測試等設(shè)置對于我們來講通過幾次操作就可以輕松掌握了.針對results analysis我用圖片加文字做了一個(gè)例子，希望通過例子能給 大家更多的幫助.這個(gè)例子主要講述的是多個(gè)用戶同時(shí)接管任務(wù)，測試系統(tǒng)的響應(yīng)能力，確定系 統(tǒng)瓶頸所在客戶要求響應(yīng)時(shí)間是1個(gè)人接管的時(shí)間在5s內(nèi).2. 系統(tǒng)資源：2. 1硬件環(huán)境：cpu：奔四2. 8e硬盤：100g網(wǎng)絡(luò)環(huán)境:100mb

2、ps2.2軟件環(huán)境：操作系 統(tǒng)：英文windowsxp服務(wù) 器:tomcat服務(wù)瀏覽器: ie6.0系統(tǒng)結(jié)構(gòu)：b/s結(jié)構(gòu)3. 添加監(jiān)視資源下面要講述的例子添加了我們平常測試中最常用到的一些資源 參數(shù).另外有些特殊的資源暫時(shí)在這里不做講解了 我會在以后相繼補(bǔ)充進(jìn)來。mercury loadrunner analysis 中最常用的 5 種資源.1. vuser2. transactions3. web resources4. web page breakdown5. system resources在analysis 'i1選擇“add graphw或"new graph”就可

3、以看到這幾個(gè)資源了. 還有其他沒有數(shù)據(jù)的資源,我們沒有讓它顯示.如果想查看更多的資源，可以將左下角的display only graphs containing data 置為不選然后選中相應(yīng)的點(diǎn)“open graph"即可.打開analysis首先可以看的是summary report.這里顯示了測試的分析摘要. 應(yīng)冇盡冇但是我們并不需要每個(gè)都要仔細(xì)去看下面介紹一下部分的含義： duration（持續(xù)時(shí)間）:了解該測試過程持續(xù)時(shí)間測試人員木身要對這個(gè)時(shí)期內(nèi)系 統(tǒng)一共做了多少的事有大致的熟悉了解.以確定下次增加更多的任務(wù)條件下測試 的持續(xù)時(shí)間。statistics summary （

4、統(tǒng)計(jì)摘要）:只是大概了解一下測試數(shù)據(jù)，對我們具體分析 沒有太大的作用.transaction summary（事務(wù)摘要）：了解平均響應(yīng)時(shí)間average單位為秒. 其余的看不看都可以.都不是很重要.4. 分析集合點(diǎn)在錄制腳本小通常我們會使用到集合點(diǎn)，那么既然我們用到了集合 1*7們刺t需要窈道vuser是在什么時(shí)候集合在這個(gè)點(diǎn)上，乂是怎樣的一個(gè)被釋放的過程.這 個(gè)吋候就需耍觀察vuser-rendezvous圖.summary report j run nmgvusers | vuser summary rendezvous j tran section summary average tra

5、nsaction response time http responses pe( »sj8sn> paseaacrjo8qlunn圖1可以看到大概在3分50的地方30個(gè)用戶才全部集中到start集合點(diǎn)，持續(xù) 了 3分多，在7分30的位置開始釋放用戶，9分30還有18個(gè)用戶，11分 10還冇5個(gè)用戶，整個(gè)過程持續(xù)了 12分.arysis2 lial* <newgraph>surrmaiy repoit rumngvus<s vuser summary rerdezvoust ransachon summaryweb page breakdownhile per

6、 seoond twouggul p占并 downtoad tme breakdown rendezvcus average trmdciion respome time rendezvoits average transaction response timesasn> paseaacrjo jaqenn3028262422201801:0002 0003:0004:0005:0006:0007:0008:0009:0010:0011:0012:009080706050 一 i a 1 average response t_m8 (seconds)elapsed scenario ti

7、me mm:ss匕 如“ yuscr_cncltransoction o vuscrm_jwnsaction legerd | gs力 detels! usei nol« | giaph data raw datacolor | ®aph00j rendezvouse)h aveiagetra elj scei measuremert!ebon tsn? actioni gghmrt . | gghlave . gumak . i gfaphlme. i gghlsld .丨45.792113.98230706109.25542659_ ia. 1average tra.

8、1刃artvuz_end_t fansadion vsec rit t rancaction1900 001tt 004300.001121380.0012上面圖2是集合點(diǎn)與平均事務(wù)響應(yīng)吋間的比較圖.注:在打開analysis之后系統(tǒng)lr默認(rèn)這兩個(gè)曲線是不在同一張圖中的這就 需要自行設(shè)置了具體步驟如下：點(diǎn)擊圖上.右鍵選擇 merge graphs.然后在 select graph to merge with 中選擇即將用來進(jìn)行比較的graph.圖3:/jk'f/ 17v/z°/set filtdrill doer/grownup by.ctrl+tctrl+l- 瓦set g

9、ranularity.ctrl+gview neasurement irenasview cursorctrl+u圖view raw datashow transaction breakdown treemergegraphs.ctrkm1 1令圖2中較深顏色的是平均響應(yīng)時(shí)間，淺色的為集合點(diǎn)，當(dāng)vuser在集合點(diǎn)持續(xù) 了 1分后平均響應(yīng)時(shí)間呈現(xiàn)最大值,可見用戶的并發(fā)對系統(tǒng)的性能是一個(gè)很大 的考驗(yàn).接下來看一下與事務(wù)有關(guān)的參數(shù)分析.下看一張圖.page download tffne breakdown rendezvous - average transacbon response time a

10、verage transaction response time - running vuserso vuser-end.transaction 4 vuser jnit.transaction run3028262422201816141210864204這張圖包扌舌 average transaction response time 和 running vuser 兩個(gè)數(shù) 據(jù)圖.從圖中可以看到vuser_init_transaction（系統(tǒng)登錄）對系統(tǒng)無任何的影響，vuser 達(dá)到15個(gè)的時(shí)候平均事務(wù)響應(yīng)時(shí)間才有明顯的升高，也就是說系統(tǒng)達(dá)到最優(yōu)性能 的吋候允許14個(gè)用戶同吋處理事務(wù),vu

11、ser達(dá)到30后1分，系統(tǒng)響應(yīng)時(shí)間 最大，那么這個(gè)最大響應(yīng)時(shí)間是要推遲1分鐘才出現(xiàn)的，在系統(tǒng)穩(wěn)定之后事務(wù) 響應(yīng)時(shí)間開始下降說明這個(gè)時(shí)候有些用戶已經(jīng)執(zhí)行完了操作同時(shí)也可以看出要想將事務(wù)響應(yīng) 時(shí)間控制在10s內(nèi).vuser數(shù)量最多不能超過2個(gè).看來是很難滿足用戶的需求了. 做一件事冇時(shí)候上級會問你這件事辦得怎么樣了你會說做完一半了那么這個(gè)一半的事情你花了多少時(shí)間呢?所以我們耍想知道在給定時(shí)間的范圍內(nèi)完成事 務(wù)的百分比就要靠下面這個(gè)圖(transaction response time (percentile)sadion response time (percentile)transaction

12、response time (percentile)260-240-(spuooas) asuodsai ueloesuejl220200-180-160-140-120-100-80-60-40-so70405060percent of transactions201010(9020-vuser init tr&ns&ction v* action jtransaction- vuser endtransaction 圖中畫圈的地方表示10%的事務(wù)的響應(yīng)時(shí)間是在80s左右.80s對丁用戶來說不 是一個(gè)很小的數(shù)字，而且只冇10%的事務(wù)，汗你覺得這個(gè)系統(tǒng)性能會好么！實(shí)際工作中遇到

13、的事情不是每一件事都能夠在很短的時(shí)間內(nèi)完成的，對于 那 些需要吋間的事情我們就要分配適當(dāng)?shù)膮奸g處理，吋間分配的不均勻就會出 現(xiàn)冇 些事情消耗的時(shí)間長一些，冇些事情消耗的短一些，但我們自己清楚.lr 同樣也為我們提供了這樣的功能，使我們可以了解大部分的事務(wù)響應(yīng)時(shí)間是 多少？以確定這個(gè)系統(tǒng)我們述耍付出多少的代價(jià)來提高它.transaction response time (distribution)-事務(wù)響應(yīng)時(shí)間(分布)顯示在方案中 執(zhí)行事務(wù)所用吋間的分布.如果定義了可以接受的最小和最大事務(wù)性能時(shí)間，可以 通過此圖確定服務(wù)器性能是否在可接受范圍內(nèi).average tensaction respon

14、se time running vusers | transactioper secondtransaction re$pon$e time (distribubon)transaction response time (distribution)suo-oesuejl jo -laqenn323028262422201816141210864203041 spj2411im020406080100120140160180200220240260transaction response time (rounded down to the nearest second) actionransac

15、tion vuser-end_transaction vusernrt-tr&nsaction j|很明顯大多數(shù)事務(wù)的響應(yīng)時(shí)間在60-140s.在我測試過的項(xiàng)目中多數(shù)客戶所能 接受的最大響應(yīng)時(shí)間也耍在20s左右.140s的時(shí)間！很少有人會去花這么多的時(shí) 間去等待頁而的出現(xiàn)吧！通過觀察以上的數(shù)據(jù)表我們不難看到此系統(tǒng)在這種環(huán)境下并不理想世間事 有果就有因，那么是什么原因?qū)е碌孟到y(tǒng)性能這樣差呢?讓我們一步-步的分析.系 統(tǒng)性能不好的原因多方面，我們先從應(yīng)用程序看.冇的時(shí)候我不得不承認(rèn) lr的功能真的很強(qiáng)大，這也是我喜歡它的原因.先看一張頁面細(xì)分圖.transactions per secon

16、dtiansaclion response time (dislrbubon) hh per secondhh pei second -awags tranoi re： aweb page- |jt web page breakdowndss.dpage dowrioad time biekdown (over tir hhpei secondthiouglpjtpags dowrioadtme breakdown rendezvous - avefage t ransacicn respo average transaction response tme rirtfar«cbon

17、response tirre (dbtiibukn) hh per second | hii$ pec seccnd average tw$aciion response tiw web page breskdow | < £web page breakdownc 30 a 20100i peo-umoo01:co020003:0004:0005:0006:0007:00 c®(boft 001010011:001200elapsed scenario time mm:ss 19216. /checktimenotice (main url) actionjransa

18、cton -> 192.16. /checktimenctice (main url) 19216. 5:8888a4serta$ks (main url) adtanjranseiction > 192 16 5:8888a4erta$k$ (main url) 19216. ertnsksjkgin do (man urljadion.transacbon > 192.16. erta$k$.logn.do (main url)o 192168. 8teorta$tdo(mahlrl)actonjransacton-> 192.168.erateontask.do(

19、manurl)select page to 丁break down:'d ocurbad licm brukdoun cwnpomm erwfcdoas (over tmt) c dounbtd brukdoun (ovr tmi) timt to am buffer brtikdoun (ovr unx) web page一個(gè)應(yīng)用程序是由很多個(gè)組件組成的，整個(gè)系統(tǒng)性能不好那我們就把它徹底的 剖 析一下圖片中顯示了整個(gè)測試過程中涉及到的所有web頁breakdown中顯示的是每個(gè)頁面的下載時(shí)間點(diǎn)選左下角 web page breakdown 展開，可以看到每個(gè)頁中包括的css樣式表,j

20、s腳本,jsp頁面等所有的屬性.在 select page to breakdown 中選擇頁面.見圖.i bty1滬哇1ddsspage dowdoad time breakdown (ovei tit 入 hil$ pei secondt hr outputpage dowdoad tme bteakdo/nrendezvous average tramactcn respo aveiage t (anaction reepome time - rur t ransadions per secorrft ransaciion response t me (dirtudon)hils pei

21、 secondhik pei second avec冷 trarwaction reweb page bef 切n<lli >h > web page breakdowni j vuser_init_t rarwacbon-鳥 action_t ramacbon4 q l.16.5:8888/userta2ks(nwinurl| /* x2) 192.16.ecteks/logn.do irriarn url) 4192.168. f30542d545c3d5 (rnain url)* i?) 192.168.ruekid-240(rrnurl)* 巧 192.16.7che

22、cktmel4obc6 (mah url|* f) 192.168. ticecor/rmcfo (man url)* f) 192.168. erat«xit«k. do (man url)、$ vusclend.transoebon<l-p§8s)h«$ pet seoond -average tian$acbon re$pon$e t meweb page breakdownweb page breakdown0.50.403020.101:0002:0003:0004:0005:0006:0007:0008:0009:0010:0011:0

23、0elapsed scenano time mm:ss丁0"9 0 477 0 517 0.641 0.501 085希鬻訂 8888/u$ecx& (man url) (actionrensacton)二 dounload ten® breakdzag component bgakdcon (oir«r ikr) dovrtk»d tkn« breakdoun (five 7lm»)tkne to flret buffer &naakdo«n (ov«r hrr«t)cocrponenl

24、192 168 0 1 35 8888/usatdsks19216. 5:8888/u?crt«k$ cwsrcsomion hcomccbondownload t me (seconds)0.148componcrt see |kb|0 234q4570.175ssl hondshofeng bjftp a»jthcrtc«twn fir si buffer receive ciiert error在select page to breakdown中 選 擇http:/192. 168. 0. 135:8888/usertasks后，在 下方看到屈于它的兩個(gè)組件

25、,第 一彳亍中 connection 和 first buffer 占拯了整個(gè)的時(shí) 間，那么它的消耗時(shí)間點(diǎn)就在這里，我們11 q做1卑決問題就要從這里下手.i1加耒1廣顯示使用最近的dns服務(wù)器將dns名稱解析為ip j 址所需的吋間?！癲ns查找”度量是指示dns解析問題或dns服務(wù)器問題的一 個(gè)很好的指示器。曰二匕右1仝土匕審 iidt66hr夂驅(qū)z打first buffer立初始連接所需的時(shí)間。連接度量是一個(gè)很 好的網(wǎng)絡(luò)問題指示器。此夕卜，它述可表明服 務(wù)器是否對請求作出響應(yīng)。顯示從初始 http 請求（通常為 get）到成功收回來自 web 服務(wù)器的ssl handshaking第一次

26、緩沖時(shí)為止所經(jīng)過的時(shí)間。第一 次緩沖度量是很好的web服務(wù)器延遲 和網(wǎng)絡(luò)滯后指示器。注意：由于緩沖區(qū)大小最大為8k,因此1 receive弟一/久綾種ii'j冋口jfj藝也軌足元丿j乂兀奈級 所需的時(shí)間。顯示建立ssl連接（包括客戶端belle 日卩夂典“l(fā)ie 皮門寺蟲zeo血生日仕|ftp authentication輸、服務(wù)器證書傳輸和其他部分可選階 段）所用的時(shí)間。自此點(diǎn)z后，客戶端與ssl握手度量僅適用于https通信。 顯示從服務(wù)器收到最后一個(gè)字節(jié)并完成下 載2前經(jīng)過的時(shí)間?！敖邮铡倍攘渴呛芎玫木W(wǎng)絡(luò)質(zhì)量指示器（查看用來計(jì)算接收速率的時(shí)間/大小比率）。顯示驗(yàn)證客戶端所用的時(shí)間

27、。如果使用ftp,則服務(wù)器在開始處理客戶端命令z 前，必須驗(yàn)證該客戶端?！癴tp驗(yàn)證”度量僅適用于ftp協(xié)議通信。i clienti1顯示因?yàn)g覽器思考時(shí)間或其他與客戶端有關(guān)的延遲而使i1客戶機(jī)上的請求發(fā)生延遲時(shí)，所經(jīng)過的平均時(shí)間。|i m errori顯示從發(fā)出http請求到返回錯(cuò)誤消息(僅限于|ihttp 錯(cuò)誤)這期間經(jīng)過的平吻時(shí)間。1也有可能你的程序屮client的時(shí)間最長或者其他的，這些就要根據(jù)你口己的測 試結(jié)果來分析了下面我們來看一下cpu,內(nèi)存硬盤的瓶頸分析方法： 首先我們要監(jiān)視cpu,內(nèi)存硬盤的資源情況得到以下的參數(shù)提供分析的依據(jù). %processor time(processo

28、r_total):器消耗的處理器時(shí)間數(shù)量.如果服務(wù)器專用于 sql server可接受的最大上限是80% -85 %.也就是常見的cpu使用率.%uscr time (processor total):表示耗費(fèi)cpu的數(shù)據(jù)庫操作，如排序，執(zhí)彳亍 aggregate functions等。如果該值很高，可考慮增加索引，盡量使用簡單的表 聯(lián)接，水平分割大表格等方法來降低該值。%dpc time(processor_total):越低越好。在多處理器系統(tǒng)中，如果這個(gè) 值大于50%并且processor:% processor time非常高，加入一個(gè)網(wǎng)卡可能會提高性能，提供的網(wǎng)絡(luò) 經(jīng)不飽和。%dis

29、k time(physicaldisk_total):指所選磁盤駆動器忙于為讀或?qū)懭胝埱筇峁?服務(wù)所用的時(shí)間的百分比。如果三個(gè)計(jì)數(shù)器都比較大，那么硬盤不是瓶頸。如果 只有%disk time比較大,另 外兩個(gè)都比較適中,硬盤可能會是瓶頸。在記錄該計(jì) 數(shù)器之/前，請?jiān)趙indows 2000的命令彳亍窗口中運(yùn)行diskperf -yd。若數(shù)值持 續(xù)超過80%,則可能是內(nèi)存泄漏。availiable bytes (memory):用物理內(nèi)存數(shù). 如果available mbytes的值很小(4 mb或更小)則說明計(jì)算機(jī)上總的內(nèi)存可能不足，或某程序沒有釋放內(nèi)存。 context switch/sec

30、(system):(實(shí)例化inetinfo 和dl ihost 進(jìn)程) 如果 你決定要增加線程字節(jié)池的大小，你應(yīng)該監(jiān)視這三個(gè)計(jì)數(shù)器(包括上面的一 個(gè))增加線程數(shù)可能會增加上下文切換次數(shù)，這樣性能不會上升反而會下降。如 果十個(gè)實(shí)例的上下文切換值非常高，就應(yīng)該減小線程字節(jié)池的大小。%disk reads/sec (physicaldisk total):每秒讀硬盤字節(jié)數(shù).%disk write/sec(physicaldisk_total):每秒寫硬盤字節(jié)數(shù).page faults/sec:進(jìn)程產(chǎn)生的貞故障與系統(tǒng)產(chǎn)生的相比較，以判斷這個(gè)進(jìn)程對系 統(tǒng)頁故障產(chǎn)生的影響。pages per second

31、:每秒鐘檢索的頁數(shù)。該數(shù)字應(yīng)少丁每秒一頁working set:理線程最近使用的內(nèi)存頁，反映了每一個(gè)進(jìn)程使用的內(nèi)存頁的數(shù) 量。如果服務(wù)器有足夠的空閑內(nèi)存，頁就會被留在工作集屮，當(dāng)自由內(nèi)存少于一 個(gè)特定的閾值時(shí)，頁就會被清除出工作集。avg. disk queue length:讀取和寫入請求(為所選磁盤在實(shí)例間隔中列隊(duì)的)的平 均數(shù)。該值應(yīng)不 超過磁盤數(shù)的152倍。要捉高性能，可增加磁盤。注意：一個(gè) raid disk實(shí)休有多個(gè)磁盤。average disk read/write queue length: 指讀 取(寫入)請求(列隊(duì))的平均數(shù)disk reads/(writes)/s:理磁盤

32、上每秒鐘磁盤讀、寫的次數(shù)。兩者相加,應(yīng)小于磁 盤設(shè)備最大容量。average disk sec/read:以秒計(jì)算的在此盤上讀取數(shù)據(jù)的所需平均時(shí)間。average disk sec/transfer:指以秒計(jì)算的在此盤上寫入數(shù)據(jù)的所需平均時(shí)間。 bytes total/sec:為發(fā)送和接收字節(jié)的速率，包括幀字符在內(nèi)。判斷網(wǎng)絡(luò)連接速度 是否是瓶頸，可以用該計(jì)數(shù)器的值和目前網(wǎng)絡(luò)的帶寬比較page read/sec:®秒發(fā)出的物理數(shù)據(jù)庫頁讀取數(shù)。這一統(tǒng)計(jì)信息顯示的是在所有 數(shù)據(jù)庫間的物理頁讀取總數(shù)。由于物理i/o的開銷大，可以通過使用更大的 數(shù)據(jù)高速緩存、智能索引、更高效的查詢或者改變數(shù)據(jù)

33、庫設(shè)計(jì)等方法，使開銷減到最小。page write/sec:（寫的頁/秒）每秒執(zhí)行的物理數(shù)據(jù)庫寫的頁數(shù)。1.判斷應(yīng)用程序的問題如果系統(tǒng)由于應(yīng)用程序代碼效率低下或者系統(tǒng)結(jié)構(gòu)設(shè) 計(jì)右缺陷而導(dǎo)致大量的上下文切換（context switches/sec顯示的上下文切換次數(shù)太高）那么就會占用大量的系統(tǒng) 資源，如果系統(tǒng)的吞吐量降低并且cpu的使用率很高，并且此現(xiàn)象發(fā)生吋切換水 平在15000以上，那么意味著上 下文切換次數(shù)過高.hits per second throughput transaction summary average transacbon response time ! windows

34、 resources windows resources - throughpim j windows resources throughput6s>esn aenosaor959<85807s7065605550454035302520151050<>o%pnocessor'tio oooo%00:0000:1000:2000:3000:4000:5001:00q111001:20elapsed seenario time mm:ss：；會廠片廠*廠rt；01:3001:4001:5002:00r360.000 ? 340.000?320.000?300.00

35、0? 280,000 ? 260.000?240,000 b? 220.000?200,00080.000 ?h60.000 w ? 140.000 8 h20,000 a.00,000 ?80,000 ?60.000 ?40.000 ? 20.0000210從圖的整體看.context switches/sec變化不大，throughout曲線的斜率較高， 并且此時(shí)的context switchcs/scc已經(jīng)超過了 15000.程序述是需要進(jìn)一步優(yōu)化.2.判斷cpl瓶頸如果processor queue length顯示的隊(duì)列長度保持不變0=2）個(gè)并且處理器的利 用率%processor

36、time超過90%,那么很可能存在處理器瓶頸.如果發(fā)現(xiàn)processor queue length顯示的隊(duì)列長度超過2,而處理器的利用率卻一直很低，或許更應(yīng) 該去解決處理器阻塞問題,這里處理器一般不是瓶頸.o o<00:0000:1000:2000:3000:4000:5001:0001:1001:2001:3001:4001:5002:0002:10elapsed seenario time mm:sshis per second （ throughput transaction summary avete transaction response time ! windows res

37、ources windows resources - throughput< ?windows resources throughput9590858075706560555045403530252015105coprocessor time平均值大于95, processor queue length大于2.可以確定cpu瓶 頸.此吋的cpu已經(jīng)不能滿足程序需耍.急需擴(kuò)展.3.判斷內(nèi)存泄露問題內(nèi)存問題主要檢查應(yīng)用程序是否存在內(nèi)存泄漏，如果發(fā)生了 內(nèi)存泄漏,processprivatc bytes計(jì)數(shù)器和proccssworking set計(jì)數(shù)器的值 往往會升高，同時(shí)avaiable b

38、ytes的值會降低.內(nèi)存泄漏應(yīng)該通過一個(gè)長時(shí)間的，用來研究分析所有內(nèi)存都耗盡時(shí)，應(yīng)用程序反應(yīng)情況的測 試來檢驗(yàn).hits per second | throughput transaction summary : average transaction response time | whdows resources windows resources throughput°windows resources throughputme00 3001:4001:5002:00 02:10757065605550454035302520 abesn aenosaq:00 2000:400

39、0:5001:0001 1001:2001:30elapsed scenario time mm:ss圖中可以看到該程序并不存在內(nèi)存泄露的問題.內(nèi)存泄露問題經(jīng)常出現(xiàn)在服務(wù)長 時(shí)間運(yùn)轉(zhuǎn)的時(shí)候，由于部分程序?qū)?nèi)存沒有釋放，而將內(nèi)存慢慢耗盡也是提醒 大家對系統(tǒng)穩(wěn)定性測試的關(guān)注.附件：cpu信息:processor % processor time 獲得處理器使用情況。也可以選擇監(jiān)視 processor' % user time 和 % privileged time 以獲得詳 細(xì)信息。server work queues queue length計(jì)數(shù)器會顯示出處理器瓶頸。隊(duì)列長度持續(xù) 大于4

40、則表示可能出現(xiàn)處理器擁塞。system processor queue length 用于瓶頸檢測通過使用 process' % processor time 和 process' working setprocess % processor time過程的所有線程在每個(gè)處理器上的處理器 時(shí)間總和。硬盤信息：physical disk % disk timephysical disk avg. disk queue length例如，包括 page reads/scc 和 % disk time 及 avg. disk queue lengtho如呆頁而讀取操作 速率很低，同時(shí) disk time 和 avg. disk queue length的值很高,則可能有磁盤瓶徑。但 是，如果隊(duì)列長度增加的同時(shí) 頁面讀取速率并未降低，則內(nèi)存不足。physical disk % disk timephysical disk avg. disk queue length例如，包括 page reads/scc 和 % disk time 及 avg. disk queue le