sybase 性能诊断sp_sysmon[转]

ehxz

免费乐捐，感谢支持

　　文章描述了通过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 %
-----------------------------------------------------------------------------

woshiwanglijia

好，谢谢！

quanjin

dddddddddddddd