Windows下使用性能監(jiān)視器監(jiān)控SqlServer的常見指標(biāo)
上邊文章中提到win的性能監(jiān)視器是監(jiān)控數(shù)據(jù)庫性能必備的工具,接下來我就給大家介紹一些常見的監(jiān)控指標(biāo),其實無非就是磁盤,cpu,內(nèi)存等硬件的運行指標(biāo)還有數(shù)據(jù)庫自身的像鎖啊、用戶連接數(shù)啊、還有就是根據(jù)自身業(yè)務(wù)決定的需要注意的參數(shù)指標(biāo)。
1.SQL Server Buffer: Buffer Cache Hit Ratio
這是一個很重要查看內(nèi)存是否不足的參數(shù)。SQL Server Buffer中的計數(shù)器Buffer Cache Hit Ratio用來指出SQLServer從緩存中而不是磁盤中獲得數(shù)據(jù)的頻率。sqlserver會將某些查詢過的數(shù)據(jù)緩存在內(nèi)存中用于以后再次查詢使用。當(dāng)一個查詢A進(jìn)來了以后數(shù)據(jù)庫會編譯這個sql看看需要哪些數(shù)據(jù),然后執(zhí)行計劃首先去內(nèi)存中找看是否有這次查詢所需要的數(shù)據(jù),如果這個同樣的sql剛才已經(jīng)執(zhí)行過了或者該表的數(shù)據(jù)已經(jīng)緩存在內(nèi)存中,但是卻沒有在內(nèi)存中找到數(shù)據(jù),那就有可能是因為內(nèi)存不足引起內(nèi)存擠壓將緩存數(shù)據(jù)寫回硬盤或者釋放掉來提供數(shù)據(jù)庫其他請求來使用。一般來說oltp的系統(tǒng),這個值最起碼也應(yīng)該在90%以上,理想值是99%。如果這個值低于90%,那建議你應(yīng)該添加內(nèi)存了。
2.Memory: Pages/sec
這個也是監(jiān)控內(nèi)存是否不足的一個比較重要的參數(shù)。這個計數(shù)器記錄的是每秒鐘內(nèi)存和磁盤之間交換的頁面數(shù)。頻繁的交換頁面就會消耗更多的io,這會影響到服務(wù)器的性能。打個比方,超市有一個貨架上邊擺滿了新進(jìn)的各種商品a、b、c,當(dāng)你去超市想買a的時候直接去貨架就能拿到a,方便的很,當(dāng)顧客進(jìn)超市逛一圈以后跟你說我怎么沒有發(fā)現(xiàn)舊商品d呢,我就想買這個d,然后工作人員就會去倉庫把商品d拿出來擺放到貨架上供下次顧客來買。但是貨架擺滿了怎么辦呢,只能將時間長沒有人問津的a下架放到倉庫然后空出來地方擺放d,但是下次另一個顧客來了又有想要購買a的意向,工作人員就得再次把a拿出來替換掉貨架上的d。其實內(nèi)存就是這個貨架,硬盤就是倉庫。因為貨架太小了,導(dǎo)致只能頻繁的更換貨架上的商品來提供正常的運營,想減少反復(fù)來回搬運產(chǎn)生的io開銷,只能換個更大的貨架來滿足需求。
如果服務(wù)器上只跑的sqlserver,那這個指標(biāo)的理想范圍應(yīng)該是0-20之間,偶爾超過20的話影響不大,如果這個值頻繁的超過20,那說明你的這臺服務(wù)器可能需要加內(nèi)存了。
當(dāng)然這個指標(biāo)要配合著上一個指標(biāo)Buffer Cache Hit Ratio來看,如果上一個指標(biāo)緩沖命中一直在99%或者更高,而這個期間內(nèi)你的頁交換一直在20以上,那意味著不僅僅是內(nèi)存不足,而且其他的程序占用了系統(tǒng)內(nèi)存。
3.Memory: Available Bytes
另一個監(jiān)控內(nèi)存情況的計數(shù)器就是這個。這個值最少最少也得大于5M,因為sqlserver需要始終維持5-10m的自由內(nèi)存用于分配,當(dāng)這個值低于5m的時候,那sqlserver可能會因為缺少內(nèi)存而產(chǎn)生性能瓶頸。
4.Physical Disk: % Disk Time
這個計數(shù)器記錄的是磁盤的繁忙程度(是整個磁盤陣列或者物理磁盤的繁忙程度)。理論上這個值應(yīng)該低于55%,如果持續(xù)的高于55%,那說明這臺服務(wù)器上可能有io瓶頸。
如果只是偶爾的出現(xiàn)幾次,那不必?fù)?dān)心,但是可以對應(yīng)的找到這個時間點,數(shù)據(jù)庫正在干嘛執(zhí)行了哪些語句,對應(yīng)的優(yōu)化一下。
5.Physical Disk: Avg. Disk Queue Length
這是一個比較重要的查看磁盤io情況的指標(biāo)。理論上每個物理磁盤的值不應(yīng)該超過2。當(dāng)然這個值是需要計算的,比如用4塊物理盤做了個raid10,此時在一個監(jiān)控周期內(nèi)磁盤隊列的均值是10,那每塊磁盤的隊列值就是10/4=2.5,那么就可以說這個磁盤陣列存在i/o瓶頸了。這個跟之前的disktime指標(biāo)一樣,偶爾出現(xiàn)不必?fù)?dān)心,如果長時間出現(xiàn),那就得著手考慮解決磁盤的io性能問題了。
6.Processor: % Processor Time
這是監(jiān)控cpu情況的一個指標(biāo)(類似于disk time)。這個是觀察cpu利用率的一個關(guān)鍵參數(shù)。如果Processor Time計數(shù)器的值持續(xù)超過80%,說明cpu存在瓶頸問題。如果只是偶爾出現(xiàn),那說明可能是這個時間點有個特別消耗cpu的查詢,可以在下一次這個時間點來臨的時候嘗試抓一下sql并且優(yōu)化它。如果在某一個時間點以后cpu一直飆高,常見的情況就是:1.突然間的高并發(fā)2.索引重整3.突然一個經(jīng)常使用的數(shù)據(jù)量特別大的索引失效了4.死鎖5.其他好多好多。先找到問題所在,在處理掉它。
7.System: Processor Queue Length
這個指標(biāo)類似于disk queue length,也是算單個cpu的。單個cpu不能超過2,比如你是2u的機器,那這個值不應(yīng)該超過4,如果在一個監(jiān)控周期內(nèi)持續(xù)性的超過4,那就可能出現(xiàn)cpu瓶頸了。
基本上常用的就是這么多,還有好多可以配合你檢測sqlserver性能的計數(shù)器,有興趣的可以自己百度下?!?br />
- 查找sqlserver查詢死鎖源頭的方法 sqlserver死鎖監(jiān)控
- SQL Server 監(jiān)控磁盤IO錯誤,msdb.dbo.suspect_pages
- SQL Server中使用Trigger監(jiān)控存儲過程更改腳本實例
- 利用SQL Server數(shù)據(jù)庫郵件服務(wù)實現(xiàn)監(jiān)控和預(yù)警
- Sql Server 死鎖的監(jiān)控分析解決思路
- Zabbix監(jiān)控SQL Server服務(wù)狀態(tài)的方法詳解
- 通過Python實現(xiàn)對SQL Server 數(shù)據(jù)文件大小的監(jiān)控告警功能
- zabbix監(jiān)控sqlserver的過程詳解
- SQL Server服務(wù)器監(jiān)控
相關(guān)文章
SQL Server中實現(xiàn)二進(jìn)制與字符類型之間的數(shù)據(jù)轉(zhuǎn)換
在SQL Server 數(shù)據(jù)庫中,如何實現(xiàn)二進(jìn)制數(shù)據(jù)與字符串?dāng)?shù)據(jù)之間的直接轉(zhuǎn)換2012-11-11使用SqlBulkCopy時應(yīng)注意Sqlserver表中使用缺省值的列
今天,想將以前做的一個程序增加點功能,原本就使用SqlBulkCopy批量、定時的從目錄中的txt文件導(dǎo)入數(shù)據(jù)到Sqlserver中。以前一直都使用正常,但是不知怎的就老是出現(xiàn)一個錯誤2012-07-07SQL?Server下7種“數(shù)據(jù)分頁”方案全網(wǎng)最新最全
這篇文章主要介紹了SQL?Server下7種“數(shù)據(jù)分頁”方案,全網(wǎng)最全,本文下面重點闡述上述【第二種】方案在SQL?Server上的使用(其它種類數(shù)據(jù)庫由于Sql語句略有差異,所以需要調(diào)整,但方案也類似),需要的朋友可以參考下2023-01-01win2008 r2 安裝sql server 2005/2008 無法連接服務(wù)器解決方法
在與 SQL Server 建立連接時出現(xiàn)與網(wǎng)絡(luò)相關(guān)的或特定于實例的錯誤。未找到或無法訪問服務(wù)器。請驗證實例名稱是否正確并且 SQL Server 已配置為允許遠(yuǎn)程連接2015-01-01