小编Ale*_*sul的帖子

为什么 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 个 vcores。
• 没有过度供应。
• 其他较小的 4-8 核 VM 位于同一位置，但不会占用 CPU

我们观察到导致拒绝服务的工作线程激增。将工作线程归因于 AG 是我们的假设，因为只有那些工作线程才能跨越限制。

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

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

是否有关于在具有 1000 多个数据库和 10TB 存储空间的服务器上将 SQL Server 2014 升级到 SQL Server 2016 需要多长时间的统计数据？安装后续 2016 服务包需要多长时间？有没有办法通过配置来优化这些安装时间？

目标是最小化维护窗口

更新：让我澄清一个问题。所有生产更新都将在 QA 环境中进行测试，问题不在于这一切。我问的是您已知的优化升级持续时间的选项。我将通过测量我环境中的升级时间来自己搜索这些选项，但如果有“以前的艺术” - 请分享。