程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> SyBase數據庫 >> SyBase綜合文章 >> sybase 性能診斷sp_sysmon

sybase 性能診斷sp_sysmon

編輯:SyBase綜合文章
文章描述了通過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) 括號後英文短詞是該模塊參數。
環境: 1、用戶數據庫中有練習所用數據表auths和article
2、數據表各有10萬行數據
3、用戶具有查詢、修改、刪除等基本的數據庫表操作權限 步驟:執行sp_sysmon “00:10:00”(server級系統存貯過程,不需要打開某個數據庫),或者執行如下格式的過程,查看具體操作批命令對應系統性能情況:
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 %
  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved