&>&SQLSERVER排查CPU占用高的情况
SQLSERVER排查CPU占用高的情况
上传大小：28KB
详细的介绍了关于SQLSERVER排查CPU占用高的排查及解决问题情况，对于开发人员有一定的帮助价值
综合评分：5
{%username%}回复{%com_username%}{%time%}\
/*点击出现回复框*/
$(".respond_btn").on("click", function (e) {
$(this).parents(".rightLi").children(".respond_box").show();
e.stopPropagation();
$(".cancel_res").on("click", function (e) {
$(this).parents(".res_b").siblings(".res_area").val("");
$(this).parents(".respond_box").hide();
e.stopPropagation();
/*删除评论*/
$(".del_comment_c").on("click", function (e) {
var id = $(e.target).attr("id");
$.getJSON('/index.php/comment/do_invalid/' + id,
function (data) {
if (data.succ == 1) {
$(e.target).parents(".conLi").remove();
alert(data.msg);
$(".res_btn").click(function (e) {
var parentWrap = $(this).parents(".respond_box"),
q = parentWrap.find(".form1").serializeArray(),
resStr = $.trim(parentWrap.find(".res_area_r").val());
console.log(q);
//var res_area_r = $.trim($(".res_area_r").val());
if (resStr == '') {
$(".res_text").css({color: "red"});
$.post("/index.php/comment/do_comment_reply/", q,
function (data) {
if (data.succ == 1) {
var $target,
evt = e || window.
$target = $(evt.target || evt.srcElement);
var $dd = $target.parents('dd');
var $wrapReply = $dd.find('.respond_box');
console.log($wrapReply);
//var mess = $(".res_area_r").val();
var mess = resS
var str = str.replace(/{%header%}/g, data.header)
.replace(/{%href%}/g, 'http://' + window.location.host + '/user/' + data.username)
.replace(/{%username%}/g, data.username)
.replace(/{%com_username%}/g, data.com_username)
.replace(/{%time%}/g, data.time)
.replace(/{%id%}/g, data.id)
.replace(/{%mess%}/g, mess);
$dd.after(str);
$(".respond_box").hide();
$(".res_area_r").val("");
$(".res_area").val("");
$wrapReply.hide();
alert(data.msg);
}, "json");
/*删除回复*/
$(".rightLi").on("click", '.del_comment_r', function (e) {
var id = $(e.target).attr("id");
$.getJSON('/index.php/comment/do_comment_del/' + id,
function (data) {
if (data.succ == 1) {
$(e.target).parent().parent().parent().parent().parent().remove();
$(e.target).parents('.res_list').remove()
alert(data.msg);
//填充回复
function KeyP(v) {
var parentWrap = $(v).parents(".respond_box");
parentWrap.find(".res_area_r").val($.trim(parentWrap.find(".res_area").val()));
评论共有1条
对应sql server数据库来说，索引、触发器、等都会对性能造成影响。文中说的较为简单。
VIP会员动态
CSDN下载频道资源及相关规则调整公告V11.10
下载频道用户反馈专区
下载频道积分规则调整V1710.18
spring mvc+mybatis+mysql+maven+bootstrap 整合实现增删查改简单实例.zip
资源所需积分/C币
当前拥有积分
当前拥有C币
输入下载码
为了良好体验，不建议使用迅雷下载
SQLSERVER排查CPU占用高的情况
会员到期时间：
剩余下载个数：
剩余积分：0
为了良好体验，不建议使用迅雷下载
积分不足！
资源所需积分/C币
当前拥有积分
您可以选择
程序员的必选
绿色安全资源
资源所需积分/C币
当前拥有积分
当前拥有C币
为了良好体验，不建议使用迅雷下载
资源所需积分/C币
当前拥有积分
当前拥有C币
为了良好体验，不建议使用迅雷下载
资源所需积分/C币
当前拥有积分
当前拥有C币
您的积分不足，将扣除 10 C币
为了良好体验，不建议使用迅雷下载
无法举报自己的资源
你当前的下载分为234。
你还不是VIP会员
开通VIP会员权限，免积分下载
你下载资源过于频繁，请输入验证码
您因违反CSDN下载频道规则而被锁定帐户，如有疑问，请联络:!
若举报审核通过，可返还被扣除的积分
被举报人：
举报的资源分：
请选择类型
资源无法下载 （ 404页面、下载失败、资源本身问题）
资源无法使用 （文件损坏、内容缺失、题文不符）
侵犯版权资源 （侵犯公司或个人版权）
虚假资源 （恶意欺诈、刷分资源）
含色情、危害国家安全内容
含广告、木马病毒资源
*详细原因：
SQLSERVER排查CPU占用高的情况记一次SQLServer服务器CPU飙升100%的处理
某集团一台sqlserver服务器，据系统管理员反应，经常会出现CPU飙到100%而且高居不下的情况，然后应用层会出现各种等待超时。
服务器配置：windows
+ 32GB内存 +6核CPU，业务量不算特别繁忙，按理CPU使用率不会很高。
首先确认CPU高是否确实是由SQLSERVER导致的，添加几个windows CPU计数器:Procesor:% Privileged
Time（kernel mode值），Procesor: %user time （user mode值），Procesor:
%processor time ,Process:Processor time(添加所有实例，查看sqlserver
cpu占用率)。结果%processor time 很高（正常平均应低于50%），且sqlserver使用率占用绝大部分。
&一般来说，sqlserver对
cpu的使用相对于内存、I/O等资源来说，应该算是较少的。CPU的使用主要是用于编译、重编译、sort、aggregation、表join（nested
match等）。可以通过profiler抓取一段trace，基本没有多少编译和重编译存在（profiler里cache
insert和cache miss基本没有），那么很有可能是某些sql语句导致CPU消耗很高。再通过profiler抓取一些CPU
time比较高的sql语句，有时候CPU使用率到达90%时，使用profiler会使服务器负载更高，我们可以用下面sql抓取一段时间内cpu消耗比较高的语句：
SELECT TOP 10
execution_count as [Number Of Executions],
total_worker_time/execution_count as [Average CPU Time],
total_elapsed_time/execution_count as [Average Elapsed Time],
SUBSTRING(text,statement_start_offset/2,
(CASE WHEN
statement_end_offset = -1
&THEN LEN(CONVERT(nvarchar(max),text)) *2
&ELSE statement_end_offset END -
statement_start_offset) /2)
sys.dm_exec_sql_text(sql_handle)
query_text
sys.dm_exec_query_stats
ORDER BY [Average
CPU Time] DESC;
抓取到的语句结构基本一致，在业务非繁忙期把sql单独拉出来测一下，看一下cpu时间和io情况：
cpu时间很高，实际数据获取不到32s，cpu时间占用91s(触发了并行运算)，同时光某一张表的扫描达到400W次，其余的扫描我在此没截图；
再看看执行计划
cost最大的是在11行的clustered
scan，结合抓取到的CPU高的sql语句来看，发现cost最大的消耗全部都是基于某个筛选条件 ——summary like
'%某某某%'，问题原因找到了，那么为什么会出现以及怎么解决就是后面要做的了。
server基于like的模糊查询很特别，像上述那种like'%%'，前后都有通配符的情况，不管该字段有没有索引，走的都是table
scan或clustered index
scan，效率非常低（该生产环境表数据量在1000W行左右，全表扫描性能消耗很大）！如果是只是后面通配符如 like
'abc%',且有合适索引是可以走index
seek的（实际生产环境会更复杂，有基于cost的算法有时也会做全表扫描）。解决办法只能从两个方面入手：1.创建合适的索引，更改模糊查询匹配为后匹配（经测试cpu时间会降低10-20倍）；2.创建全文索引，全文索引类似于搜索引擎功能，它不同于基于B+树或hash索引的普通索引，性能上优于模糊查询，不做详细介绍，下面是一个1万行小数据量利用模糊查询和全文索引的一个小测试，数据量越大性能差别越大：
模糊查询：
利用全文索引：
当然上述两种方式是比较理想的情况，比如说建立全文索引的表必须要有唯一键，否则全文索引也不可行；又比如应用层就是想用到前后置的模糊查询‘%***%’,那想做优化也无能为力。换个思路，从另一面也能达到同样的目的。
上述我们所说的几个昂贵的查询语句，都同时用到了并行查询，且在排查出这些情况的同时，发现系统等待事件上有大量的CXPACKET
CXPACKET等待产生机制：当为SQL查询创建一个并行操作时，会有多个线程去执行这个查询。每个查询处理不同的数据集或行集。因为某些原因，一个或多个线程滞后，而产生了CXPACKET等待状态。组织线程必须等待所有线程完成处理才能进行下一步。由于组织线程等待缓慢的线程完成处理所产生的等待，就叫CXPACKET等待。CXPACKET等待事件要辩证来看，并不是所有的CXPACKET等待类型都是不好的事情。
如果你在任何查询上禁止此种等待，那么查询也许会变慢，因为不能为它执行并行操作。一般来说：
在纯OLTP系统上，它的事务较短，查询也不长，但是通常很快速。设置“Maximum degree of
Parallelism”（MAXDOP）为1，禁用并行查询，降低数据库引擎开销；
OLAP或DataWarehouse:在纯OLAP系统上，因为查询执行时间一般较长，建议设置“Maximum degree of
Parallelism”（MAXDOP）为0，由SQL server自动配置最大并行度，
这样大多数查询将会利用并行处理，执行时间较长的查询也会受益于多处理器并发而提高性能。
OLAP&OLTP混合系统，这样的环境比较复杂，就像上面讲的那个案例，也是基于这种系统，我们必须找到“并行查询阀值”和“最大并行度”之间的平衡点。测试下来发现把并行查询阀值提升到18，且最大并行度设置为3，系统运行很好，既不影响运行速度又不会使CPU过高。基于这种设置，那么比较简单的查询不会启用并行查询，降低CPU开销，当预估cost大于18的比较复杂报表查询,那么会启用并行查询，提升查询速度，同时这意味着只会使用cpu的3个核（6核）来做并行运算，不会使cpu使用过高。这么一修改下来，cpu终于降下来了，没报表在跑的话基本在10%左右，有报表在跑也不会很高，在40%~50%左右徘徊。
EXEC sys.sp_configure N'show advanced options', N'1'
RECONFIGURE WITH OVERRIDE
EXEC sys.sp_configure N'cost threshold for parallelism', N'18'
EXEC sys.sp_configure N'max degree of parallelism', N'3'
RECONFIGURE WITH OVERRIDE
EXEC sys.sp_configure N'show advanced options', N'0'
RECONFIGURE WITH OVERRIDE
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。查看:6228|回复：10
我用的SQL Server 2008 R2 企业版，当分配所有4个CPU共64核时，系统CPU占用超过60%，前台工作不流畅。这时调整SQL分配的CPU，让SQL只占用2个CPU共32核时，系统CPU占用降低到10%~20%之间，前台客户端明显流畅了，百思不得其解。望高人指点！万分感谢！:L1 :handshake
本帖最后由 justfun001 于
12:31 编辑
另外内存多少？
Microsoft SQL Server MVP
助理工程师
看情况和环境，如果DBMS一切都智能了。。DBA们也该退出江湖了
SQL Server 082012 大型网站优化、ERP系统优化、规划/设计&&QQ:
感谢兄弟们鼎立支持，很有启发性！我调整些并发相关的选项运行几天看看效果，有结果回来总结下再结贴！
前天设定数据库选项，打开所有CPU给SQL Server使用，然后检查了一下
SELECT top 5 *
FROM sys.dm_os_wait_stats
order by wait_time_ms desc
CXPACKET 一项高居第一，于是将MaxDOP设定为16，CPU占用所改善。谁知昨天业务繁忙时段下面有客户端连接不上服务器。
再查微软资料：
--当您配置 MAXDOP 值时，请遵循以下准则：
--& & 对于使用八个以上的处理器的服务器使用以下配置： MAXDOP = 8。
--& & 服务器的有八个或更少的处理器，使用下列配置其中 N 等于处理器数： MAXDOP = 0 到 N。
--& & 对于具有 NUMA 配置的服务器，MAXDOP 不应超过分配给每个 NUMA 节点的 cpu 数。
--& & 超线程已启用的服务器的 MAXDOP 值不应超过物理处理器的数量。
怀疑和超线程有关系，再上网查了下我的服务器志强E7 4820 果然是超线程CPU，物理核是8个。根据微软MaxDOP第一条和第四条原则，调整MaxDOP到8，目前为止CPU占用不高，LAZYWRITER_SLEEP是第一个wait_stats，运行似乎还稳定。
散分结贴。
引用:原帖由 justfun001 于
16:46 发表
前天设定数据库选项，打开所有CPU给SQL Server使用，然后检查了一下
SELECT top 5 *
FROM sys.dm_os_wait_stats
order by wait_time_ms desc
CXPACKET 一项高居第一，于是将MaxDOP设定为16，CPU占用所改善。谁 ... 对于OLTP的数据库一般MAXDOP设置为1，如果CPU多的话可以酌情增加。我以前也遇到过数据库WAIT TYPE CXPACKET最多的问题，当时是将MAXDOP调整为1，之后数据库CPU下降了很多，性能还有提升（都是OLTP的交易，不需要并行计划）
Microsoft SQL Server MVP
引用:原帖由 lzf328 于
17:13 发表
对于OLTP的数据库一般MAXDOP设置为1，如果CPU多的话可以酌情增加。我以前也遇到过数据库WAIT TYPE CXPACKET最多的问题，当时是将MAXDOP调整为1，之后数据库CPU下降了很多，性能还有提升（都是OLTP的交易，不需要并行计划） ... 365*24的系统，既有事务性操作，也并存大量数据汇总查询操作，很难管理，MAXDOP设为1有点低。
以前官方就建议把超线程关掉
MCITP/MCSE/MCT/MVP&&SQL Server
那些年，我们一起追过的MS SQL Server
http://jimshu.blog.51cto.com
底层用的虚拟化吗
如果每个物理处理器的Context Switches/sec高于5000，官方强烈建议关闭系统上的超线程。
有关超线程的工作原理，请参考Intel官方网站：
MCITP/MCSE/MCT/MVP&&SQL Server
那些年，我们一起追过的MS SQL Server
http://jimshu.blog.51cto.com
如果是SQL Server 2008（不带R2），还要注意一个问题：
在X64的Windows Server 2008 R2操作系统，为了在一台机器上支持超过64个逻辑CPU，引入了Processor Group这个概念。Processor Group会把一些逻辑CPU编成一个组，但是一个组内的逻辑CPU总数不能超过64个。超过64个的话，要编入另外一个组。
例如，对于80个逻辑CPU，就会编成两个组。操作系统会在重启的时候，根据逻辑CPU之间的物理远近，自动进行编组，这样就出现了40-40分配、20-60分配等不同的编组。SQL Server 2008（不带R2）每次重新启动后，有可能被分配到其中一个Processor Group，而导致能检查到的CPU个数出现变化。
MCITP/MCSE/MCT/MVP&&SQL Server
那些年，我们一起追过的MS SQL Server
http://jimshu.blog.51cto.com404 Not Found
404 Not Found}