首页 > 数据库 > Sybase > 正文

sybase 性能诊断sp_sysmon_内核诊断

2019-09-08 23:34:46
字体:
来源:转载
供稿:网友

  本篇文章采摘自时代朝阳数据库(原晓通数据库)培训部 Sybase 技术资料库。

本篇文章描述了通过sp_sysmon对Adaptive Server系统运行情况有一个全面系统了解,有利于更好地熟悉系统性能,更为有效地进行系统管理,合理地利用和配置系统资源,达到系统性能调优的目的。

sp_sysmon可以从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”,性能模块名。

通过sp_sysmon,可了解当前系统在各方面的系统运行状况,性能出现什么问题和不平衡不协调之处,学会使用相应的参数和措施进行解决和调优,不断比较对照调整前后的性能状况,最终改善系统性能。

说明:1、该命令执行结果集的开头相同如下,各分块实验不再一一列示:

======================================================================

     Sybase Adaptive Server Enterprise System Performance Report

======================================================================

Server Version:        Adaptive Server Enterprise/11.9.2/1031/P/NT (IX86)/OS 3.

Server Name:/t   Server is Unnamed

Run Date:/t      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/t/t        1.8 %

   引擎繁忙程度应在80%-90%之间,如果长期在90%以上,应考虑增加引擎数来改善性能。因为此时内部管理进程无法向磁盘写入,则检查点需要将许多页写回磁盘,而检查点进程很可能将CPU的利用率提高到100%,导致响应时间明显增加。

 CPU Yields by Engine            per sec      per xact       count  % of total

 -------------------------  ------------  ------------  ----------  ----------

Engine 0/t/t/t  6.6/t   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/t  0.0/t   0.0/t   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/t   693.2/t  58.8      415939       n/a  

Checks Returning I/O/t    469.9/t  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/t    n/a/t   n/a     0.03020       n/a  

增加引擎在检查期间的等待时间可改善吞吐量,因为减少引擎检查I/O时间相应增加执行进程的时间。

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表

图片精选