需要了解并行查询执行错误

Question

今天，我们的生产 sql 服务器的性能下降了。在发生这种情况时，我们记录了几个"The query processor could not start the necessary thread resources for parallel query execution"错误。我所做的阅读表明，这与执行复杂查询时要使用的 CPU 数量有关。但是，当我在停电期间检查我们的CPU Utilization was only at 7%. 还有什么其他的东西可以指代我还没有遇到过吗？这是性能下降的可能罪魁祸首还是我在追逐红鲱鱼？

我的 sp_configure 值如下：

name                                minimum maximum config_value run_value
cost threshold for parallelism      0       32767   5            5

Answer 1

几个月前，我遇到了类似的情况，其中 MAXDOP 设置是默认设置，并且一个失控的查询耗尽了所有的工作线程。

正如 Remus 指出的那样，这称为工作线程饥饿。

发生这种情况时，将在您的服务器上创建内存转储。

如果您使用的是 2008R2+SP1 及更高版本，那么sys.dm_server_memory_dumps还会为您提供转储文件位置。

现在回到问题：

每个 NUMA 节点有 1 个调度程序监视器线程，并且由于您有 2 个 NUMA 节点，因此将有 2 个调度程序监视器线程负责每 60 秒对该特定 NUMA 节点的所有调度程序进行健康检查，同时确保调度程序卡住或不是。

每次从调度程序工作队列中提取新的工作请求时，工作进程计数器都会增加。因此，如果调度程序将工作请求排入队列并且在 60 秒内没有处理工作请求之一，则调度程序被认为卡住了。

由于失控查询或广泛的并行性，出现工作线程开始耗尽的情况，因为所有线程都被单个失控查询或过度长时间阻塞占用，除非该违规进程被杀死，否则无法完成任何工作。

最好的办法是首先调整您的最大并行度设置。默认值0 意味着 SQL Server 可以使用所有可用的 CPU 进行并行处理，从而耗尽所有工作线程。

导致工作线程耗尽的原因有很多：

• 大量长阻塞链导致 SQL Server 耗尽工作线程
• 广泛的并行性也会导致工作线程耗尽
• 广泛等待任何类型的“锁”——自旋锁、闩锁。孤立的自旋锁就是一个例子。

请参阅我在此处的回答，它将向您展示如何计算服务器实例的 MAXDOP 值。

此外，强烈建议您开始收集有关您的数据库服务器实例的等待统计信息。

Answer 2

可能有几个原因。最有可能的是你没有工人了。见max_worker_threads。这种情况被称为“工人饥饿”。可以通过多种方式中的任何一种来窃取工作人员（任何一种方式都不会导致高 CPU 利用率，顺便说一句），例如在 CLR 中阻止许多请求或做一些愚蠢的事情（例如 HTTP 请求）。

您看到的症状是问题的受害者，而不是原因。我们无法在不知道原因的情况下推荐解决方案。您需要收集性能计数器、DMV 并查看 ERRORLOG 以获取更多信息。