本系列属于 SQL Server性能优化案例分享 专题
部分内容借用《SQL Server 2012实施与管理实战指南》P592,如果SQL Server错误日志里面并没有17883/17884这类错误,但是SQL Server CPU很高,那一般就是工作负载太高导致的。意味着SQL Server并没有什么大问题,但是很辛苦地在完成用户发过来的请求。
由于CPU较于内存、阻塞、磁盘等资源瓶颈而言相对较后,所以SQL Server的CPU使用率一般不会太高,如果60~70%就已经算是很高了。那么一般集中使用CPU的资源有那些?
- 编译和重编译
- 排序和聚合计算:order by 、distinct、AVG、SUM、MAX、MIN等。
- 表关联,特别是选择了错误的JOIN算法。
一般要在SQL Server配置上能做手脚的根据个人经验,主要是Max Degree of Parallelism和Cost Threshold of Parallelism。
处理CPU高的常规思路
1. 确定CPU使用率到底多少,其中多少是SQL Server导致的
可以使用计数器,也可以使用代码做一个粗略的计算获取实例性能概要信息。计数器可以考虑:
- Processor: % Processor Time
- Processor: % Privileged Time (Kernel Mode)
- Processor: % User Time (User Mode)
- System: Processor queue length
- Context switches/sec
- Process: % Processor time
- Process: % Privileged time
- Process: % User time
2. 检查SQL Server错误日志是否有17883/17884之类的错误
健康的SQL Server其错误日志应该比较干净。3. 找出CPU 100%时,SQL Server 正在运行什么
这个其实有点难度,除非周期性发生。虽然有一系列的DMV可以使用,但是由于驻留内存的特性,可能会在动手之前已经重启服务器导致信息丢失。而开启sql trace又容易加大负担。这个时候,可以考虑使用扩展事件配合周期性运行查询DMV的语句并存储在实体表中的方式。后者使用类似Zabbix这类第三方监控软件