對SQLSERVER進行性能監控

對SQLSERVER進行性能監控

在上一篇文章《SQLSERVER性能監控級別步驟》裏說到性能監控的步驟中有一步涉及到創建性能基線，可是沒有說到有哪些計數器

能夠用來進行監控的，這篇文章結合《企業級平臺管理實踐》的書本說一下監控SQLSERVER有哪些計數器能夠用到的

三、創建性能基線
 
 當肯定了性能監控中所涉及的資源、負載和目標後，開始進行監控，並創建性能基線與當前服務器性能進行比較。
 
性能基線是一個保證系統正常操做性能範圍值，達到或超過這個範圍，系統性能可能會顯著降低。
 
應該對接近或超過性能基線的數字作進一步調查找出緣由監控的週期是一段時間，而不是一兩天。
 
其中應該包括數據庫活動的峯值時間和非峯值時間，數據查詢和批處理命令的響應時間、數據庫備份和還原所需時間
 
創建服務器性能基線後，將基線統計與當前服務器性能進行比較。對高於或遠低於基線的數字須要作進一步調查。
 
他們可能代表有須要調整或從新配置的區域。例如，執行一組查詢的時間增長，檢查這些查詢以肯定可否從新編寫他們，
 
或者是否添加統計信息或索引

介紹：

性能監視器 Performance Monitor

性能監視器是Windows的一個工具，在系統管理工具組裏。默認裏面就有不少Windows層面的性能計數器，能夠監視系統的運行。

直接運行"perfmon"，也能夠打開他。這裏以 WindowsXP/2003/2008的性能監視器爲例。

Windows2008R2和Windows7的性能監視器界面有了比較大的變化，功能也有擴展，更加好用。同時也徹底向前兼容。

後面談到的功能都有包括

SQLSERVER本身開發了一些擴展的性能計數器。在安裝SQLSERVER的時候，會註冊到Windows裏。

這樣， Windows的性能監視器就能看到一些以「SQL」打頭的計數器了。SQLSERVER在運行時，會統計這些計數器的值。

在性能監視器裏可以看到：

默認性能監視器是用來實時檢測系統的，在窗口裏，用不一樣顏色的線條表示不一樣的計數器值。

當窗口畫滿之後，會從頭覆蓋前面的內容。因此默認只能看到最近一小段時間的值。

可是在現實的問題分析中，實時監測仍是比較少的。更常見的場景是須要在問題發生以前，就要開啓性能計數器的收集，

收集一段時間以後，或者問題重現以後，再離線地分析問題的現象和緣由。

那麼日誌怎樣收集呢？

一般可使用下面這些步驟：

（1）在性能監視器左邊的窗口，展開性能 日誌和警告子樹，點擊「計數器日誌」 在右邊的窗口裏，右鍵點擊，

選擇「新 日誌設置」，他會彈出一個對話框，讓你爲新的日誌記錄配置命名。這裏咱們取名爲Test，日誌默認保存路徑是

%systemdrive%\PerfLogs\Admin\Test

（2）在接着彈出的對話框裏，就能夠配置DBA要蒐集的信息要求了。首先要選擇蒐集哪些計數器，以及他們的取樣時間間隔sample data every，

默認是15秒取一次，這個間隔可以知足大部分需求。

有說法講在蒐集和磁盤相關的性能日誌時，間隔要設置短一點，最好是3到5秒。若是設置30秒以上，可能信息就不完整了。

因此15秒是大部分狀況下比較好的選擇

（3）選擇添加對象，就能夠選擇要收集的性能監視器對象。對於非在線分析，問題可能還不清楚，很難肯定哪些性能計數器有用，哪些沒有用。

因此在這裏，必定要多選一些。通常的SQL問題，能夠選擇下面這些對象

在memory,process,physicaldisk,processor,system對象下的全部計數器，以及他們的全部instance

全部以SQLSERVER：開頭的性能監視對象

若是要監視CPU類問題，最好還包含thread下面的全部計數器，以及他全部的instance

有些DBA會擔憂，抓這麼多計數器會不會影響性能。

應該說根據經驗，性能監視器對系統總體性能的影響幾乎感受不到。因此能夠比較放心大膽地多收一些計數器。

基本工做原理是在.NET編譯出的IL代碼裏放入鉤子用來記錄時間，而後經過直觀的界面顯示出哪部分代碼耗能最大。

只是間隔可能仍是選15秒比較安全

 

（4）設置文件的位置和最大大小 ，另外一個重要配置，是日誌文件存放在哪裏，保存格式，以及最大大小。

日誌文件的後綴是blg的二進制文件，須要使用性能監視器才能打開這個文件

若是性能日誌文件大小超過1GB，可能有些機器打開會很慢。因此必定要注意其最大值能夠設爲200MB。

若是一個200MB的文件寫滿，性能監視器會自動建立一個新的。文件格式能夠選二進制文件

日誌蒐集固然能夠手動開始和終止。可是若是問題會發生在半夜，最好能讓系統自動開啓，自動關閉。性能監視器也能夠幫DBA作到這一點

當獲得一個性能日誌後，能夠在性能監視器裏選擇 查看 日誌 數據

在數據源裏添加日誌文件

而後點擊數據選項卡，就能看到在原來那臺服務器上收集的性能計數器了

這時候再點擊「源」選項卡，能看見性能日誌文件所包含的那段時間。拉動滾動條，能夠把時間段縮短到DBA最關心的那段時間

對收集到的日誌，DBA能夠進行分析

 

---------------------------------------華麗的分割線----------------------------------------------------------------------

一些性能監視器計數器
相關計數器

性能對象                                                 計數器
SQLSERVER:BUFFER MANAGER:    buffer cache hit ratio,lazy writes/sec ,procedure cache pages,total pages
SQLSERVER：Cache Manager:    cache hit ratio,cache object counts,cache pages ,cache use counts/sec
SQLSERVER:MEMORY MANAGER:    sql cache memory(kb)
SQLSERVER:SQL STATISTICS:    auto-param attmpts/sec,batch request/sec,failed auto-params/sec,safe autoparam/sec, sql compilations/sec,

sql re-compilations/sec,unsafe auto-params/sec

------------------------------------華麗的分割線--------------------------------------------------------

與內存有關的計數器

Windows與SQLSERVER系統使用內存狀況和合理配置SQLSERVER內存 

性能監視器  perfmon --添加-》可用計數器-》Memory-》添加available MBytes和pages/sec

數據收集器集-》用戶定義-》新建-》數據收集器集-》名稱：SQLSERVER內存使用-》手動建立-》性能計數器-》 添加下面的性能計數器-》

時間間隔15秒-》保存路徑：C:\Users\Administrator\Desktop\SQLSERVER內存使用-》 保存並關閉-》選中剛纔建立的數據收集器-》啓動-》變成

datacollector01   -》在用戶定義下面 SQLSERVER內存使用 右鍵-》中止或者在空白的地方-》右鍵-》中止

能夠右鍵-》在用戶定義下面 SQLSERVER內存使用-》屬性-》更改數據收集器保存路徑

 計數器

committed bytes:整個Windows系統，包括Windows自身以及全部用戶進程使用的內存總數

commit limit:整個Windows系統可以申請的最大內存數，其值等於物理內存加上文件緩存大小

available MBytes（重要）:如今系統空閒的物理內存數。這個指標可以直接反映出Windows層面上有沒有內存壓力跑在Windows2000上會把空閒內存用完知道剩下4MB~10MB。跑在Windows2003或以上就會留給Windows多一點的物理內存

page file :%usage  page file:% peak usage ：反應緩存文件使用量的多少，使用越多緩存，性能越差

pages /sec:每秒鐘須要從磁盤上讀取或寫入的頁面數目

soft page fault通常不會帶來性能影響，所以通常不太關心

一個良好的系統，他要處理的數據應該比較長期地保存在物理內存裏。若是頻繁換頁/換入換出勢必影響性能，pages/sec不能長時間保持在一個比較高的值

對於一臺SQL服務器，若是available MBytes長期小於10MB，說明物理內存不太夠pages/sec 物理內存不足也會作成頻繁換頁/換入換出 pages/sec不能長時間保持在一個比較高的值

Windows系統自身內存使用狀況

一個32位Windows系統，正常內存使用大概幾百MB --64位Windows系統大概1GB~2GB

--若是發生內存泄漏（通常由硬件驅動形成），Windows會用到幾個GB甚至十幾GB，反過來擠壓應用的內存

 

memory :cache bytes --系統的working set，也就是系統使用的物理內存數目，包括高速緩存，頁交換區，可調頁的ntoskrnl.exe 和驅動程序代碼，

以及系統映射視圖

cache bytes計數器是下面幾個計數器的和：

system cache resident bytes,system driver resident bytes ,system code resident bytes ,pool paged resident bytes

system cache resident bytes:系統高速緩存消耗的物理內存。高速緩存的主要功能是提升文件讀寫的速度

pool paged resident bytes：頁交互區消耗的物理內存

system driver resident bytes：可調頁的設備驅動程序代碼消耗的物理內存

system code resident bytes：ntoskrnl.exe中可調頁代碼消耗的內存

system pool 內存池  若是兩個重要的內存池內存出現泄漏，或者空間用盡，Windows會出現奇怪不正常的行爲， 進而影響SQL穩定運行。

因此須要檢查這兩個內存池

pool nonpaged bytes 非換頁內存池

pool paged resident bytes 換頁內存池

 

單個process使用狀況

常見場景：available MBytes看出服務器的內存基本用盡，可是從cache bytes看Windows本身沒有使用多少。

如今要開始分析應用程序的內存使用了

在選擇對象的實例裏面要每一個進程都要添加進計數器裏面，不要選擇_Total SQL的進程是sqlservr

%processor time:是目標進程消耗的CPU資源數，包括用戶態和核心態的時間

page faults/sec:是目標進程上發生的page faults的數目

handle count：目標進程handle(指向object指針)數目句柄數。若是進程內部有對象總是建立，不及時回收，就會發生handle leak

thread count:目標進程的線程數目。若是進程總是建立新線程，不釋放老線程，就會發生thread leak

pool paged bytes:是目標進程所使用的paged pool大小

pool nonpaged bytes:是目標進程所使用的non-paged pool大小

working set:某個進程的地址空間，存放在物理內存的那一部分

virtual bytes:某個進程所申請的虛擬地址空間大小，包括reserved memory 和committed memory

private bytes:某個進程提交了的地址空間commited memory中，非共享部分

假設有processA 和processB,他們的虛擬地址空間都分紅兩部分，核心態和用戶態 --核心態是由Windows控制，全部進程共享。

processA --committed memory :1,2,3,4,7 --reserved memory:8 --shared memory:經過特殊API申請的內存，processA和processB都可以訪問

物理內存physical memory：1，3，4，d，7，9，b，c 緩存文件page file：2，y

系統核心態內存 system working set=x

檢查計數器主要找到如下：

使用內存最多的進程

內存使用量在不斷增加的進程

出現問題的那個時間段，內存使用數量發生過突變（增或降）的進程

這些能夠經過working set  private bytes獲得初步答案

 -------------------------------------------------華麗的分割線-------------------------------------------------------

上面這些都是《SQLSERVER企業級平臺管理實踐》讀書筆記整理出來的一些經常使用SQLSERVER性能計數器，你們作性能基線的時候

均可以用來作參考

 

若有不對的地方，歡迎你們拍磚o(∩_∩)o