HADR高工作线程使用率

为什么HADR池中的可用性组的工作线程数会大大增加，而不是每个副本“ 通常有3–10个共享线程 ”的最低使用量？

在一种情况下，我们观察到300个线程的使用情况，其中包含3个可用性组和10个数据库。SQL Server 2014 SP1。

我们的潜在客户包括辅助副本上的备份，主副本上的高活动性，辅助副本上的报告。

AG位于VMware的数据中心中。总共16个调度程序，通常的工作线程在200个范围内。服务器上的max_dop为2。

• 3个AG，10个DB，每个4个副本-主，2个只读，1个不可读。
• 1个辅助同步，2个异步
• 大型多主机群集上的32个物理核心上有16个vcore。
• 没有多余的准备。
• 其他较小的VM 4-8内核位于同一位置，但不会按CPU

我们观察到工作线程数量激增，导致拒绝服务。我们假设工作线程归因于AG，因为只有那些工作线程才能超过限制。

在上下文中阅读的来自SQL Server Premier现场工程师博客的以下链接没有给我完整的答案：

• 监视SQL Server 2012 AlwaysOn可用性组工作线程消耗
• 我的实际工作线程是否超出了sp_configure“最大工作线程”值？

由于您的DC位于VM上，因此我怀疑您的磁盘性能不佳。磁盘性能不佳会导致辅助节点上的日志写入时间变慢，从而导致从辅助副本返回到主副本的确认速度变慢（耗尽工作线程）。

辅助副本上的磁盘延迟可能会导致HADR Sync Commit进程增加，从而导致主数据库在等待辅助数据库确认事务时保持开放线程。

请检查死锁调度程序的错误日志，并从PerfMon收集一些IO指标，以查看磁盘延迟和磁盘队列长度。