对SQLSERVER进行性能监控

在上一篇文章《SQLSERVER性能监控级别步骤》里说到性能监控的步骤中有一步涉及到建立性能基线，但是没有说到有哪些计数器

可以用来进行监控的，这篇文章结合《企业级平台管理实践》的书本说一下监控SQLSERVER有哪些计数器可以用到的

3、建立性能基线
?
?当确定了性能监控中所涉及的资源、负载和目标后，开始进行监控，并建立性能基线与当前服务器性能进行比较。
?
性能基线是一个保证系统正常操作性能范围值，达到或超过这个范围，系统性能可能会显著下降。
?
应该对接近或超过性能基线的数字做进一步调查找出原因监控的周期是一段时间，而不是一两天。
?
其中应该包括数据库活动的峰值时间和非峰值时间，数据查询和批处理命令的响应时间、数据库备份和还原所需时间
?
建立服务器性能基线后，将基线统计与当前服务器性能进行比较。对高于或远低于基线的数字需要做进一步调查。
?
他们可能表明有需要调整或重新配置的区域。例如，执行一组查询的时间增加，检查这些查询以确定能否重新编写他们，
?
或者是否添加统计信息或索引

介绍：

性能监视器 Performance Monitor

性能监视器是Windows的一个工具，在系统管理工具组里。默认里面就有很多Windows层面的性能计数器，可以监视系统的运行。

直接运行"perfmon"，也可以打开他。这里以 WindowsXP/2003/2008的性能监视器为例。

Windows2008R2和Windows7的性能监视器界面有了比较大的变化，功能也有扩展，更加好用。同时也完全向前兼容。

后面谈到的功能都有包括

SQLSERVER自己开发了一些扩展的性能计数器。在安装SQLSERVER的时候，会注册到Windows里。

这样， Windows的性能监视器就能看到一些以“SQL”打头的计数器了。SQLSERVER在运行时，会统计这些计数器的值。

在性能监视器里能够看到：

默认性能监视器是用来实时检测系统的，在窗口里，用不同颜色的线条表示不同的计数器值。

当窗口画满以后，会从头覆盖前面的内容。所以默认只能看到最近一小段时间的值。

但是在现实的问题分析中，实时监测还是比较少的。更常见的场景是需要在问题发生之前，就要开启性能计数器的收集，

收集一段时间之后，或者问题重现之后，再离线地分析问题的现象和原因。

那么日志怎样收集呢？

通常可以使用下面这些步骤：

（1）在性能监视器左边的窗口，展开性能 日志和警告子树，点击“计数器日志” 在右边的窗口里，右键点击，

选择“新 日志设置”，他会弹出一个对话框，让你为新的日志记录配置命名。这里我们取名为Test，日志默认保存路径是

%systemdrive%PerfLogsAdminTest

（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:UsersAdministratorDesktopSQLSERVER内存使用-》 保存并关闭-》选中刚才创建的数据收集器-》启动-》变成

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

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!