检测SqlServer服务器CPU是否瓶颈
初次写博文,分享个人心得,欢迎大虾小虾来拍砖。
系统自带的性能监视器
在开始命令框中输入perfmon按enter键即可打开性能监视器
可以通过监视 % Processor Time 的值察看cpu是否遇到瓶颈,此值最好不要超出80%
如果达到了比较高的值也并不一定就是CPU的问题,一般来说CPU是不会有什么问题的,也有可能是IO,内存,程序本身的问题,CPU只是表相而已
可以用数据收集器定时收集
下面的语句可以查询出耗时最长的SQL语句
select top 50 *, (s.total_worker_time / s.execution_count) as avgworkertime from sys.dm_exec_query_stats s
cross apply sys.dm_exec_sql_text(s.sql_handle)
order by avgworkertime desc
单位是微秒
SqlServer ProFile监视
选择TSQL_Duration模板监视SQL语句执行时长,可以选择保存为文件或者数据库,可以设置监视时长,监视的结果可以根据数据库引擎优化顾问进行优化
数据库引擎优化顾问可以优化SQL文件,sqlserverprofile监视的文件或保存的数据表
在查询过程当中,编译查询计划是最为耗CPU的过程,以下可以查询出生成查询计划最多的SQL语句
select top 50 * from sys.dm_exec_query_stats q
cross apply sys.dm_exec_sql_text(q.sql_handle) t
order by q.plan_generation_num desc
尽可能的去优化这些SQL语句,以充分利用查询计划,可以大大提高查询效率
下面的语句可以查询出优化的结果
select * from sys.dm_exec_query_optimizer_info
占用时间 总优化次数 每次优化单个语句(查询)所用的平均时间(秒)。
elapsed time 11937503 0.140496722220612
SQL Statistics对象提供计数器来监视编译和发送到SQL Server实例的请求类型。必须通过监视查询编译和重编译的数量结合接收到的批处理数量来找出高CPU消耗是否是由编译引起。
理想情况下,SQL Recompilations/sec和Batch Requests/sec的比率应该应该非常低,除非用户提交的是即席查询。
关键数据:
SQLServer:SQL Statistics->Batch Requests/sec
SQL Server: SQL Statistics: SQL Compilations/sec
SQL Server: SQL Statistics: SQL Recompilations/sec
SQL Trace
如果性能计数器显示非常大的重编译数量,重编译可能正在造成高CPU消耗。接下来需要需要利用SQL Profiler纪录的trace来找出当时被重新编译的存储
过程。SQL Server Profiler trace可以给出这些信息连同重编译的原因。可以使用事件来获取这些信息。
SP: Recompile / SQL: StmtRecompile. The SP:Recompile and the SQL:StmtRecompile事件类显示哪些存储过程和语句曾经被重新编译过。当编译一个存储过程时,为存储过程和每一个被编译的语句生成事件。然而,当一个存储过程被重新编译时,只有引起重新编译的语句才会被生成一个事件(不同于SQL Server 2000中的整体存储过程编译)。
SP:Recompile事件类中的重要的数据列如下所示:
◆Event Class
◆EventSubClass
◆ObjectID(表示包含这个语句的存储过程)
◆SPID
◆Start Time
◆SqlHandle
◆TextData
EventSubClass数据列对于确定重编译原因来说非常重要。一旦过程或者触发器被重新编译,SP:Recompile就会被触发,但是有可能被重编译的即席批处理不会引发这个事件。 在SQL Server 2005中,监视SQL:StmtRecompiles时非常有用的,任何类型的批处理,即席查询,存储过程或者触发器被重编译时,这个事件类都会被触发。
保存trace文件,使用下面的查询来查看所有的重编译事件。
Select spid,starttime,textdata,eventsubclass,objected,databaseid,
sqlhandle from fn_trace_gettable (‘filepath.trc’,1) where EventClass in(37,75,166)
EventClass 37是SP:Recompile, 75是CursorRecompile, 166是SQL:StmtRecompile.
也可以进一步对这些查询结果根据Sqlhandle和ObjectID列进行分组来查看是否有某个存储过程存在大量的重编译或者由于其他原因导致的重编译(如Set选项变化)。
Showplan XML For Query Compile. 这个事件类在Microsoft SQL Server编译或者重新编译SQL语句时发生。这个事件中有关于被编译或者重编译的语句的信息。这些信息包括查询计划和存在问题的过程的Object ID。如果发现SQL Compilations/sec计数器数值很高,应该监视这个事件类。通过这些信息可以发现哪些语句被频繁的重编译。可以使用这些信息改变那些语句的参数。这应该会降低重新编译的次数。
检测SqlServer服务器CPU是否瓶颈的更多相关文章
- 检测SqlServer服务器内存是否瓶颈
性能监视器临视以下数据: Memory->Available MBytes 可用的内存 windows系统不低于1G,如果可用内存不多,则系统要求sqlserver释放内存 Paging F ...
- 检测SqlServer服务器IO是否瓶颈
通过性能监视器监视 Avg. Disk Queue Length 小于2 Avg. Disk sec/Read , Avg. Disk sec/Write 小于10ms 可以用数据收集器定时收集 ...
- [转]检测SQLSERVER数据库CPU瓶颈及内存瓶颈
在任务管理器中看到sql server 2000进程的内存占用,而在sql server 2005中,不能在任务管理器中查看sql server 2005进程的内存占用,要用 以下语句查看sql se ...
- 检测SqlServer服务器性能
通过性能监视器监视 Avg. Disk Queue Length 小于2 Avg. Disk sec/Read , Avg. Disk sec/Write 小于10ms 可以用数据收集器定时收集 ...
- [Linux] - 服务器/VPS一键检测带宽、CPU、内存、负载、IO读写
一.SuperBench.sh VPS/服务器一键检测带宽.CPU.内存.负载.IO读写等的脚本: wget -qO- https://raw.githubusercontent.com/oooldk ...
- 一个表缺失索引发的CPU资源瓶颈案例
背景 近几日,公司的应用团队反应业务系统突然变慢了,之前是一直比较正常.后与业务部门沟通了解详情,得知最近生意比较好,同时也在做大的促销活动,使得业务数据处理的量出现较大的增长,最终系统在处理时出现瓶 ...
- SQLSERVER排查CPU占用高的情况
SQLSERVER排查CPU占用高的情况 今天中午,有朋友叫我帮他看一下数据库,操作系统是Windows2008R2 ,数据库是SQL2008R2 64位 64G内存,16核CPU 硬件配置还是比较高 ...
- sqlserver服务器常用的性能计数器
sqlserver服务器常用的性能计数器,在此标记. 性能对象 计数器 说明 Processor %Processor Time %Privileged Time 建议值:持续低于80 建议值:持续低 ...
- Oracle触发bug(cursor: mutex S),造成数据库服务器CPU接近100%
问题现象: 项目反馈系统反应非常缓慢,数据库服务器CPU接近100%! INSERT INTO GSPAudit1712(ID,TypeID,CategoryID,DateTime,UserID,Us ...
随机推荐
- 用Rufus来制作Windows10的U盘安装盘
博客搬到了fresky.github.io - Dawei XU,请各位看官挪步.最新的一篇是:用Rufus来制作Windows10的U盘安装盘.
- django控制admin的model显示列表
class goods(models.Model): name = models.CharField(max_length=300) price = models.IntegerField ...
- 正整数的n次方求和
引理: (Abel分部求和法) $$\sum_{k=1}^{n}a_{k}b_{k}=A_{n}b_{n}+\sum_{k=1}^{n-1}A_{k}(b_{k}-b_{k+1})$$其中$A_{k} ...
- 关于本人遇到的nodejs的一些错误信息
window xp.win7 32位下安装node.js mongodb驱动 1.cmd->npm install mongodb 2.新建一个环境变量NODE_PATH 3.把Nodejs目录 ...
- zookeeper 系列
ZooKeeper是Hadoop的正式子项目,它是一个针对大型分布式系统的可靠协调系统,提供的功能包括:配置维护.名字服务.分布式同步.组服务等.ZooKeeper的目标就是封装好复杂易出错的关键服务 ...
- Java中单例设计模式总结
两种单例常见的实现方式: 1:懒汉的设计模式,在第一次调用的时候才完成相关的初始化操作 懒汉式是典型的时间换空间,就是每次获取实例都会进行判断,看是否需要创建实例,浪费判断的时间.当然,如果一直没有人 ...
- Android 监听短信(同时监听广播和数据库)
暗扣,强烈谴责这种侵害用户利益的行为... 下面给大家介绍Android暗扣原理....... Android4.4以下的系统玩游戏就要小心了哈 暗扣方式之一:短信订购,即监听--------拦截- ...
- 2015南阳CCPC D - Pick The Sticks dp
D - Pick The Sticks Time Limit: 1 Sec Memory Limit: 256 MB 题目连接 无 Description The story happened lon ...
- 简化版可用于多线程的logger
logger 嘛要高效,要简单.废话不多话. GitHub 地址 https://github.com/goldli/logger 本文所说的logger使用System.Logger做为NameSp ...
- SVN 冲突文件快速解决方法
精简的美丽...... 现在几乎没有几个写代码的人不用snv来存储代码了吧! 但是,在实际操作中,多人对同一文件读写造成冲突是时有发生的事.这个时候解决的方法就是打开文件找出冲突的地方.如果冲突的部分 ...