今天，我们的生产 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 进行并行处理，并在那里耗尽所有工作线程。导致工作线程耗尽的原因有很多：
请参阅我在此处的回答，它将向您展示如何计算服务器实例的 MAXDOP 值。
此外，强烈建议您开始收集有关数据库服务器实例的等待统计信息。
可能有几个原因。最有可能的是你没有工人了。见
max_worker_threads。这种情况被称为“工人饥饿”。工作人员可以通过多种方式中的任何一种方式被窃取（其中任何一种方式都不会导致 CPU 使用率过高，顺便说一句），例如阻止许多请求或在 CLR 中做一些愚蠢的事情（例如 HTTP 请求）。您看到的症状是问题的受害者，而不是原因。我们不能在不知道原因的情况下推荐解决方案。您需要收集性能计数器、DMV 并检查错误日志以获取更多信息。