当你作为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的状态。