今天早上系统维护后,发现一个库的CPU奇怪(正常情况下CPU早10到20之间),现在已经在70到90之间了(当然问题,早就出现了,并不是今天早上的偶然事件,因为这个库没有安装监控,所以............)。
检查阻塞情况,排在前2名的是:
1.CXPACKET
2.SOS_SCHEDULER_YIELD
CXPACKET 出现非常高,90%情况是由于并行查询引起的(如果再结合PAGEIOLATCH_XX waits等待事件,可以推断是有可能是进行大表并行查询,使用了不正确的non-clustered或过时的statistics 引起的,导致错误的查询计划),但是这里没有出现PAGEIOLATCH_XX 。我在这里保守的调整了MAXDOP 参数:
EXEC sys.sp_configure N'show advanced options', N'1' RECONFIGURE WITH OVERRIDE
GO
EXEC sys.sp_configure N'max degree of parallelism', N'1'
GO
RECONFIGURE WITH OVERRIDE
GO
EXEC sys.sp_configure N'show advanced options', N'0' RECONFIGURE WITH OVERRIDE
GO
,
这时CPU并没有明显降低,然后通过以下语句拉出高消耗CPU的SQL语句:
select
highest_cpu_queries.*,q.dbid,
q.objectid, q.number, q.encrypted, q.[text]
from
(select top 50 qs.*
from sys.dm_exec_query_stats qs
order by qs.total_worker_time desc) as highest_cpu_queries
cross apply sys.dm_exec_sql_text(plan_handle) as q
order by highest_cpu_queries.total_worker_time desc
go
一查看,发现是开发人员写的SQL有问题。
这是一个很频繁调用的list存储过程,这个存储过程的SQL里面大量使用了系统函数(当然那个表的数据也有点多),导致CPU消耗很高,SQL部分语句如下:
WHERE ISNOTICED = 0 AND (ISNULL(notices, 0) < 6)
AND(@date BETWEEN DATEADD(s, 6, createtime) AND DATEADD(mi, 15, createtime))
ORDER BY CREATETIME desc
当然还有很多,我就不摘录了。和开发人员一起修改了SQL,问题得到解决。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/8183550/viewspace-705609/,如需转载,请注明出处,否则将追究法律责任。