工作线程问题：如何读取此故障转储，以及如何处理？

Question

我们的生产 SQL Server 昨天冻结了。必须杀死 Windows 进程才能让它重新启动。

Microsoft SQL Server 2016 (SP1-CU1) (KB3208177) - 13.0.4411.0 (X64)
Jan 6 2017 14:24:37  
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows Server 2012 R2 Standard 6.3 <X64>
(Build 9600: ) (Hypervisor)

事件查看器在崩溃时说：

分配给节点 0 上的进程的新查询在过去 300 秒内没有被工作线程接收。阻塞或长时间运行的查询会导致这种情况，并可能降低客户端响应时间。使用“最大工作线程”配置选项来增加允许的线程数，或优化当前运行的查询。SQL 进程利用率：0%%。系统空闲：99%%。

发现这篇文章（从 2010 年开始）提供了一些如何阅读故障转储的提示。我查看了来自我们服务器的故障转储，发现了数千个看起来像这样的块：

 2376  Id: 6bc.84c8 Suspend: 0 Teb: 00007ff7`f74d4000 Unfrozen
 # Child-SP          RetAddr           Call Site
00 000000b5`5938bcd8 00007fff`d22e6d8e ntdll!NtSignalAndWaitForSingleObject+0xa
01 000000b5`5938bce0 00007fff`c1944b99 KERNELBASE!SignalObjectAndWait+0xc8
02 000000b5`5938bd90 00007fff`c19414dc sqldk!SOS_Scheduler::Switch+0x106
03 000000b5`5938c080 00007fff`c4c5185f sqldk!SOS_Scheduler::SuspendNonPreemptive+0xd3
04 000000b5`5938c0c0 00007fff`c4debd67 sqlmin!EventInternal<SuspendQueueSLock>::Wait+0x1e7
05 000000b5`5938c110 00007fff`c4debb61 sqlmin!LockOwner::Sleep+0x49a
06 000000b5`5938c210 00007fff`c4c57f1c sqlmin!lck_lockInternal+0xfd3
07 000000b5`5938cab0 00007fff`c4c5ef3a sqlmin!GetLock+0x1d9
08 000000b5`5938cb80 00007fff`c4ecc841 sqlmin!BTreeRow::AcquireLock+0x212
09 000000b5`5938cc90 00007fff`c4c5f20b sqlmin!IndexRowScanner::AcquireNextRowLock+0xf6
0a 000000b5`5938ccd0 00007fff`c4c774fa sqlmin!IndexDataSetSession::GetNextRowValuesInternal+0x12e6
0b 000000b5`5938cf60 00007fff`c4cb9dc2 sqlmin!RowsetNewSS::FetchNextRow+0x1d9
0c 000000b5`5938d080 00007fff`c56090b1 sqlmin!CQScanTableScanNew::GetRow+0xfa
0d 000000b5`5938d0f0 00007fff`c4e9592c sqlmin!CQScanSpoolNew::LoadSpool+0x51
0e 000000b5`5938d120 00007fff`c4c7b741 sqlmin!CQScanSpoolNew::Open+0xf3
0f 000000b5`5938d170 00007fff`c4cb1185 sqlmin!CQScanNew::OpenHelper+0x41
10 000000b5`5938d1a0 00007fff`c4c7b741 sqlmin!CQScanTopNew::Open+0x15
11 000000b5`5938d1d0 00007fff`c4c7b741 sqlmin!CQScanNew::OpenHelper+0x41
12 000000b5`5938d200 00007fff`c4db682d sqlmin!CQScanNew::OpenHelper+0x41
13 000000b5`5938d230 00007fff`c4c7b741 sqlmin!CQScanUpdateNew::Open+0x190
14 000000b5`5938d280 00007fff`c4db682d sqlmin!CQScanNew::OpenHelper+0x41
15 000000b5`5938d2b0 00007fff`c560909f sqlmin!CQScanUpdateNew::Open+0x190
16 000000b5`5938d300 00007fff`c4e9592c sqlmin!CQScanSpoolNew::LoadSpool+0x3f
17 000000b5`5938d330 00007fff`c560cc61 sqlmin!CQScanSpoolNew::Open+0xf3
18 000000b5`5938d380 00007fff`c4db6fe0 sqlmin!CQScanSequenceNew::Open+0xf1
19 000000b5`5938d410 00007fff`c26b0da9 sqlmin!CQueryScan::UncacheQuery+0x40b
1a 000000b5`5938d480 00007fff`c26b0e74 sqllang!CXStmtQuery::SetupQueryScanAndExpression+0x421
1b 000000b5`5938d500 00007fff`c26b6a67 sqllang!CXStmtQuery::InitForExecute+0x34
1c 000000b5`5938d530 00007fff`c26df2e9 sqllang!CXStmtQuery::ErsqExecuteQuery+0x4dc
1d 000000b5`5938d6b0 00007fff`c26df0ac sqllang!CXStmtDML::XretDMLExecute+0x3a3
1e 000000b5`5938d790 00007fff`c26b19ea sqllang!CXStmtDML::XretExecute+0xb0
1f 000000b5`5938d7c0 00007fff`c26b2973 sqllang!CMsqlExecContext::ExecuteStmts<1,1>+0x40d

根据上面链接的文章，它似乎符合这种模式：

如果是阻塞问题并且如果大多数线程都在等待获取锁，您会发现堆栈的大部分类似于下面的堆栈。（我们尝试获取锁并等待，因为有人持有锁）

ntdll!ZwSignalAndWaitForSingleObject
kernel32!SignalObjectAndWait
sqlservr!SOS_Scheduler::SwitchContext
sqlservr!SOS_Scheduler::Suspend
sqlservr!SOS_Event::Wait
sqlservr!LockOwner::Sleep
sqlservr!lck_lockInternal
sqlservr!GetLock

好的，现在看来我们遇到了阻塞问题。怎么办？我们从哪里开始寻找造成这种混乱的根本原因？

以下是崩溃前的 SQL 日志：

ntdll!ZwSignalAndWaitForSingleObject
kernel32!SignalObjectAndWait
sqlservr!SOS_Scheduler::SwitchContext
sqlservr!SOS_Scheduler::Suspend
sqlservr!SOS_Event::Wait
sqlservr!LockOwner::Sleep
sqlservr!lck_lockInternal
sqlservr!GetLock

Answer 1

_{社区 Wiki 答案是根据对此问题和上一个问题的评论生成的。}

sp_BlitzErik：除了长时间运行的查询之外，还可能由于其他原因而发生线程池等待。连接数、并发查询数（特别是并行查询时）和后台任务数也会有所贡献，而这只是在 SQL 中。

启用远程 DAC，sp_WhoIsActive下次发生时运行。您可能必须使用@show_sleeping_spids才能查看连接池问题。

常见原因包括：用于工作负载的 CPU 太少、并行设置不正确、阻塞链过长。

Shanky：对于转储分析，您应该联系 MS 支持，因为正常阻塞不会导致堆栈转储。

死锁调度程序始终是 SQL Server 的错误，应向 Microsoft 报告。