初涉SQL Server性能问题（1/4）：服务器概况

 

当你做为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原创，版权归做者和博客园共有，欢迎转载，但未经做者赞成必须保留此段声明，且在文章页面明显位置给出原文链接！