speshow--自娱自乐

MSN:Jone_yin@live.cn

  博客园 :: 首页 :: 博问 :: 闪存 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::

 

当你作为DBA时,很多人会向你抱怨:“这个程序数据加载和蜗牛一样,你看看是不是服务器出问题了?”造成这个问题的原因有很多。可能是程序应用服务器问题,网络问题,程序实现方式问题,数据库服务器负荷过重。不管是哪个问题,数据库总是第一个被抱怨的。我们DBA的职责就是找出问题所在,并解决它们。

问题解决第一步,诊断分析:

 

SELECT 
parent_node_id                  AS Node_Id,
COUNT(*)                        AS [No.of CPU In the NUMA],
SUM(COUNT(*)) OVER()            AS [Total No. of CPU],
SUM(runnable_tasks_count )      AS [Runnable Task Count], 
SUM(pending_disk_io_count)                    AS [Pending disk I/O count],
SUM(work_queue_count)          AS  [Work queue count]
FROM sys.dm_os_schedulers WHERE status='VISIBLE ONLINE' GROUP BY parent_node_id

 

返回结果说明:

  • 如果返回的是一条记录,说明服务器不支持NUMA架构,否则记录数就是NUMA架构的节点数(NUMA:非均匀访存模型)。
  • Node_id:NUMA节点id。
  • No.of CPU in the NUMA:分配给NUMA节点的CPU数,或调度数( number of schedulers)。
  • Total No. of CPU:服务器上可用CPU总数。
  • Runnable Task Count:在可运行队列里,等待被重现调度的,用于分配任务(tasks)的工作者(workers)数。即,可运行队列里请求数。
  • Pending disk I/O count:等待被完成的等待IO数。每个调度都有一个等待IO清单,用于判断它们在上下文切换时是否完成。当请求被插入时,这个数字会增加。请求完成后,数字会减少。
  • Work queue count:等待队列里的任务数。这些任务等待工作者拿走。

我会把这个脚本的输出结果存到一张表,并设置为计划任务每10分钟运行一次,收集运行2天。这样我们对服务器的运行状况就有了基本的了解。在我测试的服务器上,当Runnable Task Count一直在10的时候,用户就是抱怨服务器慢!正常情况,每个节点的这个数字应该低于10。这就给了我们当前系统运行的大致情况。如果这一步的输出结果是正常的,我们就可以排除数据库服务器的问题了,响应慢的问题可能是我们不能控制的阻塞造成的,或者只是部分会话响应慢,而不是整个服务器慢。

这就是我们第1步的问题分析诊断方法,接下来的文章会具体解释后续该如何处理。

附图2张,帮助大家理解任务(tasks)、工作者(works)、调度(schedulers)之间的关系。

对于每个CPU,SQLSERVER都会有一个scheduler与之对应。在每个scheduler里,会有若干个worker,对应于每个线程。在客户端发过来请求之后,SQL会将其分解成一个或多个task。根据每个scheduler的繁忙程度,task会被分配到某个scheduler上。如果scheduler里有空闲的worker,task就会被分配到某个worker上。如果没有,scheduler会创建新的worker,供task使用。如果scheduler里的worker已经到了他的上限值,而他们都有task要运行,那么新的task只好进入等待worker的状态。 

 

 

注:此文章属WoodyTu原创,版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接!

 

posted on 2015-06-03 14:28  speshow  阅读(216)  评论(0编辑  收藏  举报