Windows IIS SQLServer性能測(cè)試有關(guān)計(jì)數(shù)器監(jiān)視及相應(yīng)的分析方法@-2023修改整理

千里之行，始于足下讓知識(shí)帶有溫度。第第2頁(yè)/共2頁(yè)精品文檔推薦WindowsIISSQLServer性能測(cè)試有關(guān)計(jì)數(shù)器監(jiān)視及相應(yīng)的分析方法@有關(guān)windows資源計(jì)數(shù)器：

相應(yīng)的分析辦法：

一、內(nèi)存

1、查看AvailableMBytes(memory)。

可用物理內(nèi)存數(shù)。普通要保留10%的可用內(nèi)存。最低不能pagereads/sec;

pageReads/sec:閾值為>5.越小越好,大數(shù)值表示磁盤(pán)讀而不是緩存讀；

Page/sec：指為解析硬頁(yè)錯(cuò)誤從磁盤(pán)讀取或?qū)懭氪疟P(pán)的頁(yè)數(shù)(是PagesInput/sec和PagesOutput/sec的總和)。其值推舉00-20假如服務(wù)器沒(méi)有足夠的內(nèi)存處理其工作負(fù)荷，此數(shù)值將向來(lái)很高。假如大于80，表示有問(wèn)題(太多的讀寫(xiě)數(shù)據(jù)操作要拜訪磁盤(pán)，可考慮增強(qiáng)內(nèi)存或優(yōu)化讀寫(xiě)數(shù)據(jù)的算法)，假如值比較低，說(shuō)明Web服務(wù)器響應(yīng)哀求比較快，否則可能是服務(wù)器系統(tǒng)內(nèi)存短缺引起（也可能是緩存太大，導(dǎo)致系統(tǒng)內(nèi)存太少）。

3、查看PoolNonpagedBytes（Memory）計(jì)數(shù)器的值。

PoolNonpagedBytes指在非分頁(yè)池中的字節(jié)數(shù)，非分頁(yè)池是指系統(tǒng)內(nèi)存(操作系統(tǒng)使用的物理內(nèi)存)中可供對(duì)象(指那些在不處于使用時(shí)不行以寫(xiě)入磁盤(pán)上而且只要分派過(guò)就必需保留在物理內(nèi)存中的對(duì)象)使用的一個(gè)區(qū)域。緩慢增長(zhǎng)表示存在內(nèi)存泄漏問(wèn)題。

二、處理器

1、%processortime（processor）、%usertime（processor）、%privilegedtime（processor）

%ProcessorTime指處理器執(zhí)行非閑置線程時(shí)光的百分比;通俗一點(diǎn)講就是CPU使用率。這是監(jiān)視處理器活動(dòng)的主要指示器。它通過(guò)在每個(gè)范例間隔中衡量處理器用于執(zhí)行閑置處理線程的時(shí)光，并且用100%減去該值得出。(每臺(tái)處理器有一個(gè)閑置線程，該線程在沒(méi)有其它線程可以運(yùn)行時(shí)消耗周期)?？蓪⑵湟暈榉独g隔用于做實(shí)用工作的百分比。

正常值thread#（thread）,contextswitches/sec（system）。

假如打算增強(qiáng)線程緩沖池的大小，便應(yīng)當(dāng)監(jiān)視這里列出的三個(gè)計(jì)數(shù)器。增強(qiáng)線程數(shù)目可能會(huì)增強(qiáng)內(nèi)容切換的數(shù)目，因而造成性能不增反降。

每一個(gè)哀求有10個(gè)或以上內(nèi)容切換就已經(jīng)是相當(dāng)高的數(shù)字了；假如浮現(xiàn)這些數(shù)字，請(qǐng)考慮降低線程緩沖池大小。想通過(guò)測(cè)量銜接及哀求來(lái)得出線程及整體性能之間的平衡點(diǎn)是不簡(jiǎn)單

的。每次當(dāng)您調(diào)節(jié)線程時(shí)，請(qǐng)接著監(jiān)視整體性能，以檢查性能是增進(jìn)還是降低。若要判定是否應(yīng)當(dāng)調(diào)節(jié)線程計(jì)數(shù)，請(qǐng)將進(jìn)程中的每一個(gè)線程數(shù)目和處理器時(shí)光拿來(lái)和總處理器時(shí)光作比較。假如線程持續(xù)勞碌，但并沒(méi)有使用所有的處理器時(shí)光，則建立更多線程對(duì)性能會(huì)有協(xié)助。不過(guò)，假如全部線程都很忙，而且處理器已快臨近最大容量，則最好將載量分配給更多服務(wù)器，而不要增強(qiáng)線程的數(shù)目。請(qǐng)參閱本文中〈附錄1︰性能設(shè)置〉的aspthreadgateenabled及aspprocessorthreadmaxmetabase屬性。

6、maximumconnections（webservice）及totalconnectionattempts（webservice）。

有關(guān)最大銜接數(shù)。假如您正在計(jì)算機(jī)上執(zhí)行的其他服務(wù)也使用網(wǎng)絡(luò)銜接，則應(yīng)監(jiān)視「webservice:maximumconnections」及「webservice:totalconnectionattempts」計(jì)數(shù)器，以檢查您的web服務(wù)器是否能夠盡可能地使用它需要的銜接數(shù)目。請(qǐng)記得將這些數(shù)字與內(nèi)存及處理器使用量作比較，如此才干確定銜接就是問(wèn)題，而不是其它組件有問(wèn)題。

……

其它關(guān)于IIS的調(diào)優(yōu)設(shè)置—

1、選用“HTTP壓縮”，壓縮文件、壓縮靜態(tài)文件。

2、connectiontimeout-這個(gè)屬性會(huì)指定服務(wù)器在中斷一條非使用中的銜接之前，將等待的秒數(shù)。默認(rèn)值是900(15分鐘)。由于開(kāi)啟的銜接會(huì)降低性能，所以請(qǐng)考慮降低此值，并監(jiān)視您的服務(wù)器在轉(zhuǎn)變之后會(huì)有什么效果。

與程序設(shè)計(jì)、編碼有關(guān)系的性能調(diào)節(jié)：

1、cgirequests/sec（webservice）及isapiextensionrequests/sec（webservcie）。

會(huì)報(bào)告您的服務(wù)器是以哪個(gè)速度處理cgi及isapi應(yīng)用程序哀求。

假如這些值在負(fù)載增強(qiáng)時(shí)降低，則可能必需哀求應(yīng)用程序開(kāi)發(fā)人員重新檢查他們的程序代碼。

2、ApplicationRestarts、WorkerProcessRestarts（A）。

ApplicationRestarts—應(yīng)用程序重新啟動(dòng)的次數(shù).Web服務(wù)器的生存期中應(yīng)用程序重新啟動(dòng)的次數(shù)。應(yīng)用程序重新啟動(dòng)的次數(shù)隨每次發(fā)生Application_OnEnd大事增強(qiáng)。因?yàn)閃eb.config文件的更改、存儲(chǔ)在應(yīng)用程序\bin名目中的程序集的更改或者Web窗體頁(yè)的過(guò)多更改，均可能導(dǎo)致發(fā)生應(yīng)用程序重新啟動(dòng)。此計(jì)數(shù)器的意外增長(zhǎng)可能意味著無(wú)法預(yù)料的問(wèn)題正導(dǎo)致您的Web應(yīng)用程序關(guān)閉。在這種狀況下，應(yīng)盡快舉行調(diào)查。

WorkerProcessRestarts—輔助進(jìn)程重新啟動(dòng)的次數(shù)。服務(wù)器計(jì)算機(jī)上輔助進(jìn)程重新啟動(dòng)的次數(shù)。假如輔助進(jìn)程意外地失敗或者被故意地回收，則能夠被重新啟動(dòng)。假如該計(jì)數(shù)器的值意外增強(qiáng)，應(yīng)盡快舉行調(diào)查。

注重:每次重新啟動(dòng)Internet信息服務(wù)(IIS)主機(jī)時(shí)都會(huì)重置該值。

3、看ErrorsTotal（AApplication）計(jì)數(shù)器的值。

錯(cuò)誤總數(shù)。執(zhí)行HTTP哀求過(guò)程中發(fā)生的錯(cuò)誤總數(shù)。包括全部分析器錯(cuò)誤、編譯錯(cuò)誤或運(yùn)行時(shí)錯(cuò)誤。此計(jì)數(shù)器為ErrorsDuringCompilation、ErrorsDuringPreprocessing和ErrorsDuringExecution計(jì)數(shù)器的總和。正常運(yùn)行的Web服務(wù)器不應(yīng)發(fā)生錯(cuò)誤。假如ASP.NETWeb應(yīng)用程序中發(fā)生錯(cuò)誤，它們可能會(huì)歪曲任何吞吐量結(jié)果，由于錯(cuò)誤恢復(fù)的代碼路徑與本來(lái)的徹低不一樣。在性能測(cè)試前應(yīng)調(diào)查并修復(fù)應(yīng)用程序中的全部錯(cuò)誤。

4、看ContextSwitches/sec（System）、%processortime（processor）計(jì)數(shù)器的值。

ContextSwitches/sec計(jì)數(shù)器測(cè)量Web服務(wù)器計(jì)算機(jī)中的全部CPU切換線程上下文的速率。此計(jì)數(shù)器的高數(shù)值通常說(shuō)明存在高的鎖爭(zhēng)用，或是線程在用戶模式與內(nèi)核模式之間有大量切換?？赡苄枰褂貌蓸臃治銎骱推渌ぞ哌M(jìn)一步討論。

假如系統(tǒng)的吞吐量降低并且CPU的使用率很高，并且此現(xiàn)象發(fā)生時(shí)切換水平在15000以上，那么意味著上下文切換次數(shù)過(guò)高。

5、查看CacheTotalTurnoverRate（AApplication）計(jì)數(shù)器的值。

CacheTotalTurnoverRate高周轉(zhuǎn)率可能說(shuō)明存在問(wèn)題?？赡芫売桑壕彺嬷杏泻?jiǎn)單重新計(jì)算和很少使用的項(xiàng)或給緩存的項(xiàng)分配的有效期太短。

6、查看PoolNonpagedBytes（Memory）計(jì)數(shù)器的值。

PoolNonpagedBytes指在非分頁(yè)池中的字節(jié)數(shù)，非分頁(yè)池是指系統(tǒng)內(nèi)存(操作系統(tǒng)使用的物理內(nèi)存)中可供對(duì)象(指那些在不處于使用時(shí)不行以寫(xiě)入磁盤(pán)上而且只要分派過(guò)就必需保留在物理內(nèi)存中的對(duì)象)使用的一個(gè)區(qū)域。緩慢增長(zhǎng)表示存在內(nèi)存泄漏問(wèn)題。

……

SQLSERVER數(shù)據(jù)庫(kù)服務(wù)器計(jì)數(shù)器：

相應(yīng)的分析辦法：

有關(guān)參數(shù)調(diào)節(jié)：

1、首先看AvailableKbytes計(jì)數(shù)器的值。

若可用內(nèi)存不多（小于50兆），說(shuō)明有其它應(yīng)用程序搶占內(nèi)存，此時(shí)可以考慮增大SQLSERVER的使用內(nèi)存，看是否可以提升性能。

增大有關(guān)SQLSERVER使用內(nèi)存辦法：

a.通過(guò)調(diào)節(jié)屬性，保留適量的可用內(nèi)存，調(diào)節(jié)“SQLServer內(nèi)存的最大值、最小值”，

可以增大最小可用內(nèi)存。

b.增大“最小查詢內(nèi)存”；

c.假如物理內(nèi)存大于4G，可以考慮啟用AWE。

2、查看CommittedBytes計(jì)數(shù)器的值（使用的內(nèi)存總數(shù)）

若大于物理內(nèi)存，則可采納1的辦法解決。

3、查看pagefilebytes:total(process)

若超過(guò)2倍的物理內(nèi)存。解決辦法同1。

4、查看AvailableKbytes、所有頁(yè)、目標(biāo)頁(yè)計(jì)數(shù)器的值。

AvailableKbytes較小，且所有頁(yè)已經(jīng)臨近目標(biāo)頁(yè)的值，則可以考慮將Bufferpool（sqlserver可用的內(nèi)存）縮小，釋放一些內(nèi)存。通過(guò)設(shè)置最小服務(wù)器內(nèi)存和最大服務(wù)器內(nèi)存。

5、看緩存命中率、頁(yè)寫(xiě)入/秒、頁(yè)讀出(SQLSever|緩沖管理器)計(jì)數(shù)器的值。

Buffercatchhitratio計(jì)數(shù)器的值應(yīng)當(dāng)穩(wěn)定的保持較高的數(shù)值，同時(shí)PageReads/sec、PageWrites/sec計(jì)數(shù)器的值應(yīng)當(dāng)很低。

假如Buffercatchhitratio計(jì)數(shù)器的值較低，且PageReads/sec、PageWrites/sec計(jì)數(shù)

器的值較高?？梢缘贸鼍彺婷新瘦^低，可以考慮增強(qiáng)Bufferpool，增強(qiáng)內(nèi)存用于數(shù)據(jù)高速緩存。

6、查看ThreadCount（sqlservr）:process計(jì)數(shù)器的值。

SQLSERVER默認(rèn)的最大工作線程為255，若該計(jì)數(shù)器的值小于255，可以考慮將SQLSERVER的最大工作線程改為一個(gè)較小的值，有可能提高性能。

7、查看UserConnections（SQLServerGeneralStatistics）計(jì)數(shù)器的值。

因?yàn)槊總€(gè)用戶銜接都消耗一些內(nèi)存，配置的用戶銜接數(shù)過(guò)高會(huì)影響吞吐量。將用戶銜接數(shù)設(shè)置為預(yù)期的最大并發(fā)用戶數(shù)。

8、調(diào)節(jié)虛擬內(nèi)存的大小。

由于虛擬內(nèi)存使用時(shí)，是耗物理內(nèi)存的。普通大小設(shè)置位物理內(nèi)存的2.5~4倍。

9、增強(qiáng)纖程

并行可以提高執(zhí)行效率，但是也可能引起CPU高利用率。

解決方法之一：利用增強(qiáng)纖程或者增強(qiáng)CPU。

可以更新，安裝一些相應(yīng)的補(bǔ)丁，增強(qiáng)并行的操作能力。

……

有關(guān)程序設(shè)計(jì)、代碼編寫(xiě)：

1、查看AverageWaitTime(ms)、LockRequests/sec、NumberofDeadlocks/sec（SQLServer|Locks）計(jì)數(shù)器的值。

若LockRequests/sec數(shù)值較大，會(huì)引起上下文切換增強(qiáng)，

若LockRequests/sec、NumberofDeadlocks/sec的值較大，可以得出軟件系統(tǒng)存在死鎖及長(zhǎng)時(shí)光鎖等待狀況，可以考慮修改有關(guān)鎖的程序。

2、查看ContextSwitches/sec（System）、%processortime（processor）計(jì)數(shù)器的值。

ContextSwitches/sec計(jì)數(shù)器測(cè)量Web服務(wù)器計(jì)算機(jī)中的全部CPU切換線程上下文的速率。此計(jì)數(shù)器的高數(shù)值通常說(shuō)明存在高的鎖爭(zhēng)用，或是線程在用戶模式與內(nèi)核模式之間有大量切換?？赡苄枰褂貌蓸臃治銎骱推渌ぞ哌M(jìn)一步討論。

假如系統(tǒng)的吞吐量降低并且CPU的使用率很高，并且此現(xiàn)象發(fā)生時(shí)切換水平在15000以上，那么意味著上下文切換次數(shù)過(guò)高。

3、查看BatchRequests/sec、SQLCompilations/sec、SQLRe-Compilations/sec(SQLSever|SQLStatistics)計(jì)數(shù)器的值。

BatchRequests/sec數(shù)值較低，且SQLCompilations/sec、SQLRe-C