sp_sysmon效能診斷結果分析(zt)

文章描述了通過sp_sysmon對Adaptive Server系統執行情況有一個全面系統瞭解，有利於更好地熟悉系統效能，更為有效地進行系統管理，合理地利用和配置系統資源，達到系統效能調優的目的。
從18個方面瞭解在用系統效能狀況，並在適當的時候利用環境引數進行效能調優：

1、核心管理（kernal）
2、應用管理（appmgmt）
3、資料快取管理（dcache）
4、ESP管理（esp）
5、索引管理（indexmgmt）
6、鎖管理（locks）
7、記憶體管理（memory）
8、後設資料快取記憶體管理（mdcache）
9、任務管理（taskmgmt）
10、監視器訪問SQL的執行（monaccess）
11、網路I/O管理（netio）
12、並行查詢管理（parallel）
13、過程快取管理（pcache）
14、恢復管理（recovery）
15、事務管理（xactmgmt）
16、事務概要（xactsum）
17、磁碟I/O管理（diskio）
18、工作程式管理（wpm）

括號後英文短詞是該模組引數。
步驟：執行sp_sysmon “00:10:00”（server級系統存貯過程，不需要開啟某個資料庫），或者執行如下格式的過程，檢視具體操作批命令對應系統效能情況：（10分鐘系統檢視）
sp_sysmon begin_sample
SQL語句或者存貯過程
sp_sysmon commit_sample
本實驗採用 sp_sysmon “hh:mm:ss”,效能模組名。
可瞭解當前系統在各方面的系統執行狀況，效能出現什麼問題和不平衡不協調之處，學會使用相應的引數和措施進行解決和調優，不斷比較對照調整前後的效能狀況，最終改善系統效能。
說明：1、該命令執行結果集的開頭相同如下：

======================================================================
Sybase Adaptive Server Enterprise System Performance Report
======================================================================
Server Version: Adaptive Server Enterprise/11.9.2/1031/P/NT (IX86)/OS 3.
Server Name: Server is Unnamed
Run Date: May 28, 2001
Statistics Cleared at: 15:57:27
Statistics Sampled at: 16:07:28
Sample Interval: 00:10:00

2、執行結果集的每列資訊提示：

per sec ： 取樣期間每秒的平均值
per xact： 取樣期間每提交一個事務的平均值
count ： 取樣期間每秒的總計值
% of total： 佔總數的百分比，根據不同情況各有不同

3、結果集對應給出效能情況描述、分析以及可調性說明
4、只給出部分模組的監視結果（可能有刪節），用sp_sysmon “hh:mm:ss”可看全部詳細情況。
單元一：監視核心利用情況
命令列：sp_sysmon “00:10:00”,kernal
結果：

Kernel Utilization （核心利用）

------------------
Engine Busy Utilization
Engine 0 1.8 %
引擎繁忙程度應在80%-90%之間，如果長期在90%以上，應考慮增加引擎數來改善效能。因為此時內部管理程式無法向磁碟寫入，則檢查點需要將許多頁寫回磁碟，而檢查點程式很可能將CPU的利用率提高到100%，導致響應時間明顯增加。
CPU Yields by Engine per sec per xact count % of total
------------------------- ------------ ------------ ---------- ----------
Engine 0 6.6 0.6 3949 100.0 %
引擎放棄CPU次數：% of total=1個引擎放棄次數/所有引擎放棄次數，如果顯示引擎利用率較低，可通過放棄數判斷是否真實反映引擎的停止情況。增加“runnable process search count”（引擎放棄CPU給OS之前一個引擎迴圈查詢可執行任務的次數）引數可增加CPU的駐留時間，而如果想減少引擎在空閒時檢查I/O的時間，可減少該引數的值。
Network Checks
Total Network I/O Checks 0.0 0.0 0 n/a
引擎傳送或接收網路包的次數。引擎空閒時頻繁檢查網路包，如果該值很低而“CPU Yields by Engine”的值高，表明引擎可能被頻繁放棄。
可能包括阻塞和非阻塞兩種檢查方式。非阻塞方式不管有無I/O等待都對網路進行I/O檢查。如果引擎已被放棄並正執行阻塞網路檢查，則在網路包到達以後仍保持一段睡眠時間（潛伏期）。此時增加“runnable process search count”（預設2000）引數可減少潛伏期，保持引擎有較長的迴圈檢查時間，而不是過早被放棄。
Disk I/O Checks磁碟I/O檢查情況：
Total Disk I/O Checks 693.2 58.8 415939 n/a
Checks Returning I/O 469.9 39.9 281921 67.8 %
引擎對I/O情況的有效檢查（I/O完成次數），如過高或過低，用“i/o polling process count”（Server的排程程式在檢查磁碟I/O或網路I/O之前可執行的最大程式數）引數增加或減少檢查頻率。通常說增加該值可增加有大量磁碟或網路I/O的應用的吞吐量，反之，減少該值有可改善其響應時間。
Avg Disk I/Os Returned n/a n/a 0.03020 n/a

增加引擎在檢查期間的等待時間可改善吞吐量，因為減少引擎檢查I/O時間相應增加執行程式的時間。

單元二：監視並行查詢管理
命令列：sp_sysmon “00:10:00”,parallel
結果： 報告並行查詢次數、執行期間調整了多少工作程式，以及在merge和sort操作時加鎖情況。

Parallel Query Management
-------------------------
Parallel Query Usage per sec per xact count % of total
------------------------- --------- --------- ------- ----------
Total Parallel Queries 0.1 8.0 16 n/a
優化器自動確定是否並行操作，以及為此使用多少工作程式。
WP Adjustments Made
Due to WP Limit 0.0 0.0 0 0.0 %
會話級的限制受“set parallel_degree” or “set scan_parallel_degree”引數控制。
Due to No WPs 0.0 0.0 0 0.0 %
缺乏可用的工作程式導致申請工作程式數減少。可適當增加“number of worker processes”
Merge Lock Requests per sec per xact count % of total
報告並行merge操作的鎖請求數，很快授予鎖的數目，下面3種型別鎖的等待情況：
------------------------- --------- --------- ------- ----------
Network Buffer Merge Locks
Granted with no wait 4.9 438.5 877 56.2 %
Granted after wait 3.7 334.5 669 42.9 %
Result Buffer Merge Locks
Granted with no wait 0.0 0.0 0 0.0 %
Granted after wait 0.0 0.0 0 0.0 %
Work Table Merge Locks
Granted with no wait 0.1 7.0 14 0.9 %
Granted after wait 0.0 0.0 0 0.0 %
------------------------- --------- --------- -------
Total # of Requests 8.7 780.0 1560
Sort Buffer Waits per sec per xact count % of total
------------------------- --------- --------- ------- ----------
Total # of Waits 0.00.0 0 n/a
並行排序所用“排序緩衝區等待”鎖。如果等待數較高，可考慮加大“number of sort buffers”的值。
======================================================================

單元三：監視執行SQL的訪問情況
命令列：sp_sysmon “00:10:00”,monaccess
結果：

Monitor Access to Executing SQL（監視執行SQL的訪問情況）

-------------------------------
per sec per xact count % of total
------------ ------------ ---------- ----------
Waits on Execution Plans 0.0 0.00 n/a
每個試圖使用sp_showplan但必須等待獲得訪問查詢計劃的讀資格，報告等待次數。
Number of SQL Text Overflows 0.0 0.0 0 n/a
SQL批文字超過文字緩衝區大小的溢位次數。
Maximum SQL Text Requested n/a n/a 0 n/a
(since beginning of sample)
“max SQL text monitored”（預設為0）引數指定分配給每個連線使用者的記憶體量，用以儲存SQL文字到記憶體，供sever監視器共享。推薦值為1024。
======================================================================
單元四：事務概要
命令列：sp_sysmon “00:10:00”,xactsum
結果：

Transaction Profile（事務概要）

報告提交的事務數，要儘量減少多資料庫事務的提交（一個事務對多資料庫的訪問）
Transaction Summary per sec per xact count % of total
------------------------- ------------ ------------ ---------- ----------
Committed Xacts 11.8 n/a 7073 n/a
Transaction Detailper sec per xactcount% of total
------------------------- ------------ ------------ ---------- ----------
Inserts
APL Heap Table 13.6 1.2 8189 100.0 %
如果大量堆表資料插入，結合檢視鎖的堆表最後一頁鎖情況，是否引起嚴重的鎖爭奪，隨之調整相應的資料表，避免因為鎖資源爭奪引起效能降低。
APL Clustered Table 0.0 0.0 0 0.0 %
對全頁鎖的表插入資料行，注意可能引起的頁分裂。
Data Only Lock Table 0.0 0.0 0 0.0 %
------------------------- ------------ ------------ ---------- ----------
Total Rows Inserted 13.6 1.2 8189 100.0 %

單元五：事務管理
命令列：sp_sysmon “00:10:00”,xactmgmt
結果：

Transaction Management（事務管理）

----------------------
　　使用者日誌cache（每個使用者對應一個）降低了寫入事務日誌的次數，如果是多處理器系統還減少了事務日誌當前頁的爭奪，因而提高了效能。可配置環境引數“user log cache size”（預設最低2048位元組），太小導致使用者日誌常滿並頻繁寫入事務日誌，太大則每個連線使用者都擴大，又造成記憶體浪費。原則是配置不超過事務完成寫入事務日誌的長度。
ULC Flushes to Xact Log per sec per xact count % of total
各種型別導致寫入事務日誌的次數
------------------------- ------------ ------------ ---------- ----------
by Full ULC 0.0 0.0 0 0.0 %
如果% of total的值超過20%，考慮增加環境引數“user log cache size”的值。
by End Transaction 11.8 1.0 7095 95.5 %
以顯式或隱式的rollback或commit標誌事務結束。值大表示有很多短小事務。
by Change of Database 0.0 0.0 12 0.2 %
如果值大，考慮減低ULC中大於2K的緩衝池，降低或去除大塊I/O池。
by System Log Record 0.5 0.0 321 4.3 %
其% of total值大於20%並且ULC長度大於2048，考慮降低ULC的長度。
by Other 0.0 0.0 0 0.0 %
------------------------- ------------ ------------ ----------

Total ULC Flushes 12.4 1.1 7428

單元六：索引管理
命令列：sp_sysmon “00:10:00”,indexmgmt
結果：

Index Management（索引管理）
索引可以加速資料檢索，但同時又降低了更新的效能。

----------------
Nonclustered Maintenance per sec per xact count % of total
非聚簇索引維護情況：報告因為插入、刪除、修改、頁分裂等造成的索引維護次數。
------------------------- ------------ ------------ ---------- ----------
Ins/Upd Requiring Maint 0.0 0.0 0 n/a
影響索引的插入和修改的運算元，需要維護非聚簇索引。對於插入，有多少非聚簇索引，就需要增加多少索引維護的開銷；對於修改，則只對相關的索引進行維護。
# of NC Ndx Maint 0.0 0.0 0 n/a
因為插入和修改需要對多少非聚簇索引進行維護。
Deletes Requiring Maint 0.0 0.0 0 n/a
# of NC Ndx Maint 0.0 0.0 0 n/a
影響索引的刪除操作次數，以及需要維護的非聚簇索引數。
RID Upd from Clust Split 0.0 0.0 0 n/a
在APL（全頁鎖）的聚簇索引表發生頁分裂次數，相應需要進行索引維護。
# of NC Ndx Maint 0.0 0.0 0 n/a
頁分裂後對應的索引維護次數。
Upd/Del DOL Req Maint0.0 0.0 0 n/a
DOL表發生影響索引的修改刪除操作次數。
# of DOL Ndx Maint 0.0 0.0 0 n/a
對應索引維護次數。
Page Splits 0.0 0.0 0 n/a
包括資料頁、聚簇索引頁和非聚簇索引頁因為插入新行沒有足夠空間單元導致頁分裂。頁分裂造成修改索引頁、修改頁指標、增加鎖資源爭奪等從而降低效能。
如果頁分裂度高（次數多），而又是對全頁加鎖表進行插入操作，並且表有組合鍵的聚簇索引，這時可通過改變那些索引的頁分裂點來減少頁分裂，即是說組合鍵的第一個鍵表中在用，第二個鍵列值按升序排列；也可考慮用fillfactor的合適配置來降低在聚簇索引的APL表的資料頁以及非聚簇索引的葉子資料頁上的頁分裂。
建議對錶插入行按照升序插入方式，這樣發生頁分裂點也是在插入行點而不是在頁中間，這樣能夠提高效能。通過dbcc tune (ascinserts, 1, "表名")設定插入方式，0反之。
如果索引維護量大，會因為維護需要額外的程式、額外的I/O、額外的索引頁鎖從而影響效能。可以通過對比不同操作次數與導致的維護次數，如果維護次數很多，還發生頁分裂、retries等現象，嚴重時可考慮不用索引。
單元七：鎖管理
命令列：sp_sysmon “00:10:00”,locks
結果：

Lock Management（鎖管理）
報告鎖、死鎖、鎖提升和鎖爭奪的情況

---------------
Lock Summary（鎖概述） per sec per xact count % of total
------------------------- ------------ ------------ ---------- ----------
Total Lock Requests 26.1 2.2 15676 n/a
總共的鎖請求
Avg Lock Contention 0.0 0.0 0 0.0 %
平均鎖爭奪
Deadlock Percentage 0.0 0.0 0 0.0 %
死鎖出現的比例
Lock Hashtable Lookups 26.1 2.2 15677 n/a
對hash表的表、頁、行鎖的查詢次數。
Avg Hash Chain Length n/a n/a 0.00038 n/a
Hash鏈平均長度：取樣期間每個hash桶的平均加鎖數目。如果每個hash鏈超過4個鎖，可用引數“lock hashtable size”調整擴大加鎖hash表的大小，尤其是大型bcp可配置更大。
Lock Detail per sec per xactcount % of total
------------------------- ------------ ------------ ---------- ----------
對於各種型別的鎖細節，重點檢視其立即授予和等待情況。
Last Page Locks on Heaps 堆表最後頁鎖
Granted 13.6 1.2 8189 100.0 %
Waited 0.0 0.0 0 0.0 %
------------------------- ------------ ------------ ---------- ----------
Total Last Pg Locks 13.6 1.2 8189 100.0 %
如果堆表最後一頁鎖的爭奪激烈（尤其是熱物件的等待時間過長），考慮建立聚簇索引，或者表分割槽來解決鎖資源爭奪問題。
Deadlocks by Lock Type per sec per xact count % of total
------------------------- ------------ ------------ ---------- ----------
Total Deadlocks 0.0 0.00 n/a
死鎖出現次數。當很多事務同時訪問同一個資料庫時，會加劇鎖資源爭奪，嚴重時事務之間會發生死鎖。可用sp_object_stats查明死鎖位置。該過程報告資源爭奪最激烈的10張表、一個資料庫中資源爭奪的表和單個表的爭奪情況。語法為sp_object_stats interval [, top_n
[, dbname [, objname [, rpt_option ]]]]，檢視鎖爭奪情況只需設定interval為“hh:mm:ss”。如果顯示每種鎖的爭奪程度超過15%，應該改變加鎖方式，比如表的全頁鎖改成資料頁鎖，資料頁鎖改成資料行鎖等。
Deadlock Detection 死鎖檢測
Deadlock Searches 0.0 0.0 0 n/a
死鎖檢測次數。死鎖檢測將特花費時間，如果檢測次數過多，用引數“deadlock checking period”（預設500ms）調節死鎖檢測週期。
Lock Promotions 鎖提升
Total Lock Promotions 0.0 0.0 0 n/a
鎖提升指排它頁鎖到排它表鎖、共享頁鎖到共享表鎖、排它行鎖到排它表鎖、共享行鎖到共享表鎖、共享next_key鎖到共享表鎖。檢視鎖提升是否加劇了鎖爭奪或死鎖發生，如果鎖爭奪激烈並且鎖提升頻繁，考慮調整鎖的隔離級別，對全頁鎖表，需要2級也可強制為3級。
Lock Timeouts by Lock Type per sec per xact count % of total
------------------------- ------------ ------------ ---------- ----------
Total Timeouts 0.0 0.0 0 n/a

單元八：資料cache管理
命令列：sp_sysmon “00:10:00”,dcache
結果：

Data Cache Management（資料cache管理）

---------------------
　　報告資料cache的自旋鎖爭奪、cache應用、cache擊中錯失、配置緩衝池的翻轉、清洗快取（包括髒頁）、預取的請求與拒絕、讀髒頁請求等情況。
Cache Statistics Summary (All Caches)
-------------------------------------
per sec per xactcount % of total
------------ ------------ ---------- ----------
Cache Search Summary cache的擊中和錯失次數
Total Cache Hits 18.6 1.6 11171 89.9 %
Total Cache Misses2.1 0.2 1251 10.1 %
------------------------- ------------ ------------ ----------
Total Cache Searches 20.7 1.8 12422
Cache Turnover
Buffers Grabbed 0.2 0.0 102 n/a
快取掠奪。Count表示cache快取塊鏈中從LRU末端取走的快取塊次數。
Buffers Grabbed Dirty 0.0 0.0 0 0.0 %
髒頁掠奪。在從LRU末端取走髒頁時必須等待將髒頁寫回磁碟。如果其值非零，可找出是什麼cache受到影響，這事關cache的擊中效能問題。
Cache Strategy Summary cache策略（對所有的cache）
Cached (LRU) Buffers 19.8 1.7 11880 100.0 %
報告有多少cache中的快取塊放置到MRU/LRU鏈的頭部。
Discarded (MRU) Buffers 0.0 0.0 0 0.0 %
報告多少快取塊採用了獲取-丟棄策略，快取塊用過以後被放到快取塊鏈的刷洗標記處。
Large I/O Usage
0.0 0.0 0 n/a
大塊I/O請求使用次數，這裡沒有設定大塊I/O，故均為0值，也沒有其授權或拒絕使用情況。
Large I/O Effectiveness
大塊I/O的使用效果，百分比值低表示很少的頁被帶入cache供查詢使用，可進一步檢視單個cache的使用情況。
Pages by Lrg I/O Cached 0.0 0.0 0 n/a
通過涉及的頁數衡量效能是否有益。低的百分比值意味著表的存貯結構很碎，或是不恰當的cache配置策略。
Asynchronous Prefetch Activity
0.0 0.0 0 n/a
非同步預取情況可結合磁碟I/O管理檢視。可看引數“global async prefetch limit”。
Other Asynchronous Prefetch Statistics
APFs Used 0.0 0.0 0 n/a
非同步預取合格的頁數。
APF Waits for I/O 0.0 0.0 0 n/a
程式等待非同步預取完成的次數。表示查詢需要的頁沒有儘早地完成非同步預取，這樣程式處於等待狀態。出現一定的百分比是合理的：查詢的首次非同步預取請求通常需要等待；每次的順序掃描移動到新的分配單元時發出預取請求，查詢必須等待第一次的I/O結束；每次非聚簇索引掃描找到合適的行集，也會發出對頁的預取請求，也要等待第一次的頁返回。
APF Discards 0.0 0.0 0 n/a
報告已經被非同步預取讀入但在使用之前就被放棄的頁數。如果其值高，建議增加緩衝池的尺寸單位（比如從2K增加4K、8K、16K的緩衝池）以改善效能，或者表示預取進入cache的很多頁並不為查詢所需要。
Dirty Read Behavior
Page Requests 0.0 0.0 0 n/a
隔離級為0的髒讀請求的頁數。
-------------------------------------------------------------------------------
Cache: default data cache 預設資料cache的情況：
per sec per xact count % of total
------------------------- ------------ ------------ ---------- ----------
Spinlock Contentionn/a n/a n/a 0.0 %
自旋鎖只對SMP環境有用。當一個使用者任務對cache的修改完成之前，其它任務將不能訪問該cache而只有等待。雖然自旋鎖駐留時間短，但對於高事務率的多處理器系統的效能依然有不好影響，如果自旋鎖比例超過10%，應考慮建立命名cache或者是增加cache分片。
Utilization n/a n/a n/a 100.0 %
下面是cache檢查的具體情況：
Cache Searches
Cache Hits 18.6 1.6 11171 89.9 %
Found in Wash 1.1 0.1 677 6.1 %
Cache Misses 2.1 0.2 1251 10.1 %
------------------------- ------------ ------------ ----------
Total Cache Searches 20.7 1.8 12422
Pool Turnover
2 Kb Pool
LRU Buffer Grab 0.2 0.0 102 100.0 %
Grabbed Dirty 0.0 0.0 0 0.0 %
------------------------- ------------ ------------ ----------
Total Cache Turnover 0.2 0.0 102
Buffer Wash Behavior
Statistics Not Available - No Buffers Entered Wash Section Yet
Cache Strategy
Cached (LRU) Buffers 19.8 1.7 11880 100.0 %
Discarded (MRU) Buffers 0.0 0.0 0 0.0 %
Large I/O Usage
Total Large I/O Requests 0.0 0.0 0 n/a
Large I/O Detail
No Large Pool(s) In This Cache
Dirty Read Behavior
Page Requests 0.0 0.0 0 n/a

單元九：記憶體管理
命令列：sp_sysmon “00:10:00”,memory
結果：
Memory Management（記憶體管理）
per secper xactcount % of total
--------------------------- ------------ ------------ ---------- ----------
Pages Allocated 0.0 0.0 13 n/a
Pages Released 0.0 0.0 13 n/a

記憶體中分配一個新頁的次數（相當於分配新頁數），以及釋放記憶體的頁數。

單元十：磁碟I/O管理
命令列：sp_sysmon “00:10:00”,diskio
結果：

Disk I/O Management（磁碟I/O管理）

-------------------報告server總體磁碟I/O行為，包括讀、寫和邏輯裝置上的semaphore爭奪。
Max Outstanding I/Os per sec per xact count % of total
最大顯著I/O數：server總體開銷的最大I/O數，分別通過server和引擎表示。
------------------------- ------------ ------------ ---------- ----------
Server n/a n/a 10 n/a
Engine 0 n/a n/a 10 n/a
I/Os Delayed by
系統遇到I/O延遲問題，類似於I/O被server或作業系統限制阻塞一樣。多數作業系統都有一個引數限制非同步I/O數。可用sp_configure檢視引數“allow sql server async i/o”。
Disk I/O Structures n/a n/a 0 n/a
達到磁碟I/O結構極限從而被延遲的I/O數。當server超過了可用磁碟I/O的控制塊數，I/O就會被延遲，因為server在開始一個I/O請求時需要通過任務來得到一個磁碟I/O控制塊。如果其值非零，通過設定增加引數值“disk i/o structures”（預設256）來增加磁碟I/O控制塊數，如果作業系統允許儘可能設定大一些，以使用光磁碟I/O結構的機會降到最小。
Server Config Limit n/a n/a 0 n/a
用引數“max async i/os per server”（預設2147483647）進行調整server一次所用非同步磁碟I/O請求數。
Engine Config Limit n/a n/a 0 n/a
引擎配置最大非同步磁碟I/O請求數限制，用引數“max async i/os per engine”檢視和調整。
Operating System Limit n/a n/a 0 n/a
作業系統的限制數檢視作業系統文件。
Device Activity Detail
----------------------
Device:
master.dat
master per sec per xact count % of total
------------------------- ------------ ------------ ---------- ----------
Reads
APF 0.0 0.0 0 0.0 %
Non-APF 0.2 0.0 102 78.5 %
Writes 0.0 0.0 28 21.5 %
------------------------- ------------ ------------ ---------- ----------
Total I/Os 0.2 0.0 130 1.5 %
Device Semaphore Granted 0.2 0.0 130 100.0 %
Device Semaphore Waited 0.0 0.0 0 0.0 %
-----------------------------------------------------------------------------

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/756652/viewspace-242418/，如需轉載，請註明出處，否則將追究法律責任。