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

今天，我们的生产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

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

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

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

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

现在回到问题所在：

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

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

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

最好的选择是首先调整“ 最大并行度”设置。默认值0 表示SQL Server可以使用所有可用的CPU进行并行处理，并在此耗尽所有工作线程。

有很多原因可能导致工作线程用尽：

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

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

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

可能有几个原因。最有可能的是您没有工作人员。请参阅max_worker_threads。这种情况称为“工人空勤”。可以通过多种方式中的任何一种来窃取工作程序（任何一种都不会导致较高的CPU利用率，btw），例如阻塞了许多请求或在CLR中做愚蠢的事情（例如HTTP请求）。

您看到的症状是问题的受害者，而不是原因。我们不建议不知道原因的解决方案。您需要收集性能计数器，DMV并检查ERRORLOG以获取更多信息。