我们生产 SQL Server 上的主要性能问题，我将如何解决这个问题？

Question

这个问题基本上是这个问题的后续问题：
SQL Server 2016 的奇怪的性能问题

我们现在使用这个系统提高了效率。虽然自从我上一篇文章以来，另一个应用程序数据库被添加到这个 SQL Server 中。

这些是系统统计信息：

• 128 GB RAM（SQL Server 的最大内存为 110 GB）
• 4 核 @2.6 GHz
• 10 GBit 网络连接
• 所有存储均基于 SSD
• 程序文件、日志文件、数据库文件和 tempdb 位于服务器的不同分区上
• 视窗服务器 2012 R2
• VMware 版本 HPE-ESXi-6.0.0-Update3-iso-600.9.7.0.17
• VMware Tools 版本 10.0.9，内部版本 3917699
• Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64) 2016 年 10 月 28 日 18:17:30 版权所有 (c) Windows Server 2012 R2 Standard 6.3（内部版本 9600）上的 Microsoft Corporation 标准版（64 位）： （管理程序）

我们的系统现在存在重大的性能问题。非常高的 CPU 使用率和线程数：

等待活动监视器的统计数据（我知道它不是很可靠）

sp_blitzfirst 的结果：

sp_configure 的结果：

高级服务器设置（不幸的是只有德语）

MAXDOP 设置由我更改。

我知道这可能不是 SQL Server 本身的问题。它可能是虚拟化（vmware）、网络相关（我已经测试过）或应用程序本身的问题。我只是想进一步确定它。

高 ASYNC_NETWORK_IO 会导致 sqlserver 进程的高线程数吗？我想它会产生很多工人，因为线程无法关闭。那正确吗？

我会提供您需要的任何其他信息。在此先感谢您的支持！

编辑：

的结果 sp_Blitz @OutputType = ‘markdown’, @CheckServerInfo = 1

优先级 1：备份：

• 备份到数据库所在的同一驱动器 - 过去两周在驱动器 E:\ 上完成了 5 次备份，数据库文件也存在于此。如果该阵列出现故障，这表示严重的风险。

优先级 1：可靠性：

• 最后一次良好的 DBCC CHECKDB 超过 2 周

  • babtec_prod - 最后一次成功的 CHECKDB：2017-08-20 00:01:01.513

  • D3PR - 最后一次成功的 CHECKDB：从不。

  • DEMO77 - 最后一次成功的 CHECKDB：2016-02-23 20:31:38.590

  • FINP - 最后一次成功的 CHECKDB：2017-04-23 22:01:19.133

  • GridVis_EnMs - 最后一次成功的 CHECKDB：2017-05-18 22:10:48.120

  • master - 最后一次成功的 CHECKDB：从不。

  • 模型

  • 数据库

  • PROD77 - 最后一次成功的 CHECKDB：2016-02-23 21:33:24.343

优先级 10：性能：

• 查询存储已禁用 - 尚未在此数据库上启用新的 SQL Server 2016 查询存储功能。

  • babtec_prod

  • D3PR

  • 演示77

  • 芬兰金融业者联合会

  • GridVis_EnMs

优先级 50：DBCC 事件：

• DBCC DROPCLEANBUFFERS - 用户 schorsch 在 2017 年 9 月 21 日上午 11:57 到 2017 年 9 月 21 日上午 11:57 之间运行了 1 次 DBCC DROPCLEANBUFFERS。如果这是一个生产盒，请知道发生这种情况时您正在清除内存中的所有数据。什么样的怪物会这样做？

• DBCC SHRINK% - 用户 schorsch 在 2017 年 9 月 21 日晚上 11:51 到 Okt 4 2017 上午 9:02 之间运行了 6 次文件收缩。那么，呃，他们是试图修复腐败，还是导致腐败？

• 总体事件 - 2017 年 9 月 19 日下午 1:40 至 Okt 4 2017 下午 3:20 之间发生了 287 个 DBCC 事件。这不包括 CHECKDB 和其他通常是良性的 DBCC 事件。

优先级 50：性能：

• 文件增长缓慢 PROD77 - 2 次增长每次超过 15 秒。考虑将文件自动增长设置为较小的增量。

优先级 50：可靠性：

• 页面验证不是最佳的 babtec_prod - 数据库 [babtec_prod] 有用于页面验证的 TORN_PAGE_DETECTION。SQL Server 可能更难识别存储损坏并从中恢复。考虑使用 CHECKSUM 代替。

优先级 100：性能：

• 一个查询的多个计划 - 计划缓存中的单个查询有 3576 个计划 - 这意味着我们可能存在参数化问题。

优先级 110：性能：

• 没有聚集索引的活动表

  • babtec_prod - [babtec_prod] 数据库有堆 - 没有聚集索引的表 - 正在被主动查询。

  • D3PR - [D3PR] 数据库有堆 - 没有聚集索引的表 - 正在被主动查询。

  • DEMO77 - [DEMO77] 数据库有堆 - 没有聚集索引的表 - 正在被主动查询。

  • FINP - [FINP] 数据库有堆 - 没有聚集索引的表 - 正在被主动查询。

  • GridVis_EnMs - [GridVis_EnMs] 数据库有堆 - 没有聚集索引的表 - 正在被主动查询。

  • PROD77 - [PROD77] 数据库有堆 - 没有聚集索引的表 - 正在被主动查询。

优先级 150：性能：

• 外键不受信任

  • babtec_prod - [babtec_prod] 数据库的外键可能已禁用、数据已更改，然后再次启用该键。仅启用键不足以让优化器使用此键 - 我们必须使用 WITH CHECK CHECK CONSTRAINT 参数更改表。

  • D3PR - [D3PR] 数据库的外键可能已禁用、数据已更改，然后再次启用该键。仅启用键不足以让优化器使用此键 - 我们必须使用 WITH CHECK CHECK CONSTRAINT 参数更改表。

• 没有聚集索引的非活动表

  • D3PR - [D3PR] 数据库有堆 - 没有聚集索引的表 - 自上次重新启动以来没有被查询。这些可能是不小心留下的备份表。

  • GridVis_EnMs - [GridVis_EnMs] 数据库有堆 - 没有聚集索引的表 - 自上次重启以来没有被查询。这些可能是不小心留下的备份表。

• 表上的触发器 babtec_prod - [babtec_prod] 数据库有 26 个触发器。

优先级 170：文件配置：

• C盘系统数据库

  • master - master 数据库在 C 驱动器上有一个文件。将系统数据库放在 C 驱动器上可能会在空间不足时导致服务器崩溃。

  • 模型 - 模型数据库在 C 驱动器上有一个文件。将系统数据库放在 C 驱动器上可能会在空间不足时导致服务器崩溃。

  • msdb - msdb 数据库在 C 驱动器上有一个文件。将系统数据库放在 C 驱动器上可能会在空间不足时导致服务器崩溃。

优先级 170：可靠性：

• 最大文件大小集

  • D3PR - [D3PR] 数据库文件 d3_data_01 的最大文件大小设置为 61440MB。如果空间不足，即使可能有可用的驱动器空间，数据库也会停止工作。

  • D3PR - [D3PR] 数据库文件 d3_data_idx_01 的最大文件大小设置为 61440MB。如果空间不足，即使可能有可用的驱动器空间，数据库也会停止工作。

  • D3PR - [D3PR] 数据库文件 d3_firm_01 的最大文件大小设置为 61440MB。如果空间不足，即使可能有可用的驱动器空间，数据库也会停止工作。

  • D3PR - [D3PR] 数据库文件 d3_firm_idx_01 的最大文件大小设置为 61440MB。如果空间不足，即使可能有可用的驱动器空间，数据库也会停止工作。

  • D3PR - [D3PR] 数据库文件 d3_log_01 的最大文件大小设置为 61440MB。如果空间不足，即使可能有可用的驱动器空间，数据库也会停止工作。

  • D3PR - [D3PR] 数据库文件 d3_phys_01 的最大文件大小设置为 61440MB。如果空间不足，即使可能有可用的驱动器空间，数据库也会停止工作。

  • D3PR - [D3PR] 数据库文件 d3_phys_idx_01 的最大文件大小设置为 61440MB。如果空间不足，即使可能有可用的驱动器空间，数据库也会停止工作。

  • D3PR - [D3PR] 数据库文件 d3_sys_01 的最大文件大小设置为 20480MB。如果空间不足，即使可能有可用的驱动器空间，数据库也会停止工作。

  • D3PR - [D3PR] 数据库文件 d3_usr_01 的最大文件大小设置为 20480MB。如果空间不足，即使可能有可用的驱动器空间，数据库也会停止工作。

  • D3PR - [D3PR] 数据库文件 d3_wort_01 的最大文件大小设置为 20480MB。如果空间不足，即使可能有可用的驱动器空间，数据库也会停止工作。

  • D3PR - [D3PR] 数据库文件 d3_wort_idx_01 的最大文件大小设置为 20480MB。如果空间不足，即使可能有可用的驱动器空间，数据库也会停止工作。

优先级 200：信息性：

• 备份压缩默认关闭 - 最近发生了未压缩的完整备份，并且未在服务器级别打开备份压缩。备份压缩包含在 SQL Server 2008R2 及更新版本中，即使在标准版中也是如此。我们建议默认打开备份压缩，以便临时备份得到压缩。

• 排序规则是 Latin1_General_CS_AS FINP - 用户数据库和 tempdb 之间的排序规则差异会导致冲突，尤其是在比较字符串值时

• 排序规则是 SQL_Latin1_General_CP1_CI_AS - 用户数据库和 tempdb 之间的排序规则差异会导致冲突，尤其是在比较字符串值时

  • 演示77

  • PROD77

• 已配置链接服务器 - BWIN2\INFOR 已配置为链接服务器。在与 sa 连接时检查其安全配置，因为任何查询它的用户都将获得管理员级别的权限。

优先级 200：监控：

• 没有失败的代理工作电子邮件

  • 作业 syspolicy_purge_history 尚未设置为在失败时通知操作员。

  • 作业 upd_durchpreis_monatl 尚未设置为在失败时通知操作员。

  • 作业 upd_fertmengen_woche 尚未设置为在失败时通知操作员。

  • 作业 upd_liegezeit_monatl 尚未设置为在失败时通知操作员。

  • 作业 upd_vertreter_diff 尚未设置为在失败时通知操作员。

  • 作业 UPDATE_CONNECT_IK 尚未设置为在失败时通知操作员。

  • 作业 Wartung.Cleanup 尚未设置为在失败时通知操作员。

  • 作业 Wartung.DBCC Check DB 尚未设置以在失败时通知操作员。

  • Wartung.Index neu erstellen 作业尚未设置为在失败时通知操作员。

  • Wartung.Statistiken aktualisieren 作业尚未设置为在失败时通知操作员。

  • 作业 Wartung.Transactionlog Backup 尚未设置为在失败时通知操作员。

  • 作业 Wartung.Vollbackup SystemDB 尚未设置为在失败时通知操作员。

  • 作业 Wartung.Vollbackup UserDB 尚未设置为在失败时通知操作员。

• 无损坏警报 - SQL Server 代理不存在针对错误 823、824 和 825 的警报。这三个错误可以为您提供有关早期硬件故障的通知。启用它们可以防止你很多心碎。

• 没有针对严重性 19-25 的警报 - 严重性级别 19 到 25 不存在 SQL Server 代理警报。这些是一些非常严重的 SQL Server 错误。知道这些正在发生可能会让您更快地从错误中恢复。

• 未配置所有警报 - 未配置所有 SQL Server 代理警报。这是一种免费、简单的方法，可以在监控系统发现损坏、作业失败或重大中断之前获得通知。

优先级 200：非默认服务器配置：

• Agent XPs - 此 sp_configure 选项已更改。它的默认值为 0，并且已设置为 1。

• 数据库邮件 XPs - 此 sp_configure 选项已更改。它的默认值为 0，并且已设置为 1。

• 默认全文语言 - 此 sp_configure 选项已更改。其默认值为 1033，已设置为 1031。

• 默认语言 - 此 sp_configure 选项已更改。它的默认值为 0，并且已设置为 1。

• 文件流访问级别 - 此 sp_configure 选项已更改。它的默认值为 0，并且已设置为 1。

• 最大并行度 - 此 sp_configure 选项已更改。其默认值为 0，已设置为 4。

• 最大服务器内存 (MB) - 此 sp_configure 选项已更改。其默认值为 2147483647，已设置为 115000。

• min server memory (MB) - 此 sp_configure 选项已更改。其默认值为 0，已设置为 10000。

• 远程管理连接 - 此 sp_configure 选项已更改。它的默认值为 0，并且已设置为 1。

优先级 200：性能：

• 并行性的成本阈值 - 设置为 5，其默认值。更改此 sp_configure 设置可能会减少 CXPACKET 等待。

• 发生快照备份 - 过去两周发生了 9 次类似快照的备份，表明 IO 可能会冻结。

优先级 210：非默认数据库配置：

• Read Committed Snapshot Isolation Enabled - 此数据库设置不是默认设置。

  • D3PR

  • 芬兰金融业者联合会

• 启用递归触发器 - 此数据库设置不是默认设置。

  • 演示77

  • PROD77

• 启用快照隔离 FINP - 此数据库设置不是默认设置。

优先级 240：等待统计：

• 1 - ASYNC_NETWORK_IO - 225.9 小时的等待，每小时平均 143.5 分钟的等待时间，0.2% 的信号等待，2146022 个等待任务，378.9 毫秒的平均等待时间。

• 2 - CXPACKET - 43.1 小时的等待，每小时平均 27.4 分钟的等待时间，1.5% 的信号等待，32608391 个等待任务，4.8 毫秒的平均等待时间。

优先级 250：信息性：

• SQL Server 在 NT 服务帐户下运行

  • 我作为 NT Service\MSSQL$INFOR 运行。我希望我有一个 Active Directory 服务帐户。

  • 我作为 NT Service\SQLAgent$INFOR 运行。我希望我有一个 Active Directory 服务帐户。

优先级 250：服务器信息：

• 默认跟踪内容 - 默认跟踪保存 2017 年 9 月 3 日晚上 8:34 到 Okt 5 2017 下午 12:50 之间 760 小时的数据。默认跟踪文件位于：C:\Program Files\Microsoft SQL Server\MSSQL13.INFOR\MSSQL\Log

• 驱动器 C 空间 - C 驱动器上有 21308.00MB 可用空间

• 驱动器 D 空间 - D 驱动器上有 280008.00MB 可用空间
• 驱动器 E 空间 - E 驱动器上有 281618.00MB 可用空间

• 驱动器 F 空间 - F 驱动器上有 60193.00MB 可用空间

• 硬件 - 逻辑处理器：4。物理内存：128GB。

• 硬件 - NUMA 配置 - 节点：0 状态：ONLINE 在线调度程序：4 离线调度程序：0 处理器组：0 内存节点：0 内存 VAS 保留 GB：281

• 服务器上次重启 - Okt 1 2017 2:21PM

• 服务器名称 - BWINPDB\INFOR

• 服务

  • 服务：SQL Server (INFOR) 在服务帐户 NT Service\MSSQL$INFOR 下运行。上次启动时间：Okt 1 2017 2:22PM。启动类型：自动，当前正在运行。

  • 服务：SQL Server-Agent (INFOR) 在服务帐户 NT Service\SQLAgent$INFOR 下运行。上次启动时间：未显示。启动类型：自动，当前正在运行。

• SQL Server 上次重启 - Okt 1 2017 2:22PM

• SQL Server 服务 - 版本：13.0.4001.0。补丁级别：SP1。版本：标准版（64 位）。AlwaysOn 已启用：0。AlwaysOn 管理器状态：2

• 虚拟服务器 - 类型：（HYPERVISOR）

• Windows 版本 - 您正在运行一个非常现代的 Windows 版本：Server 2012R2 时代，版本 6.3

优先级 254：运行日期：

• 船长的日志：确定某事某事...

编辑：

我已经研究了有关使用 vmware 设置 sql server 的最佳实践指南，并且我们已经根据本文进行了大部分设置。但是，未激活超线程并且 NUMA 在 vmware 主机上未激活。虽然 SQL Server 设置为 NUMA。

编辑：

在将并行度的阈值设置为 50 后，我发出了 RECONFIGURE，我的 MAXDOP 设置也未配置。

我还检查了我们的 vmware 管理员，似乎我被误导了。我们的 CPU 设置为 2.6GHz，而不是 4.6GHz。我已经更正了上面的信息。

编辑：

我们尝试根据这个vmwarekb和guide设置一些网络相关的。我们还向 VM 添加了 4 个内核。CPU 使用率保持不变。

Answer 1

正如您上次问这个问题时所讨论的，您最需要等待的是 ASYNC_NETWORK_IO。SQL Server 正在等待管道另一端的机器消化下一行查询结果。

我从 sp_Blitz 的等待统计结果中得到了这个信息（感谢你把它粘贴进来）：

1 - ASYNC_NETWORK_IO - 225.9 小时的等待，每小时平均 143.5 分钟的等待时间，0.2% 的信号等待，2146022 个等待任务，378.9 毫秒的平均等待时间。

不要停止对 CPU 线程进行故障排除 - 这无关紧要。专注于您的主要等待类型以及会导致该等待类型的事情。

要进一步解决此问题，请运行sp_WhoIsActive或sp_BlitzFirst（免责声明：我是其作者之一）——这两者都将列出当前正在运行的查询。查看等待信息列，找到等待 ASYNC_NETWORK_IO 的查询，并查看它们正在运行的应用程序和服务器。

从那里，您可以尝试：

• 检查这些应用程序服务器是否功率不足（例如它们是否在 CPU 上达到极限，或分页到磁盘）并调整它们
• 与应用程序开发人员合作，查看他们是否正在对结果进行逐行处理（例如，对于从 SQL Server 返回的每一行，应用程序都会关闭并在请求下一行结果之前进行一些处理）
• 与应用程序开发人员合作以选择更少的数据（例如，如果他们不需要所有数据，则选择更少的行或更少的列 - 有时您会在人们不小心执行 SELECT * 并带回比他们需要的更多的数据时看到这一点，或者他们要求当他们只真正需要前 1000 行时的所有行）

使用 sp_WhoIsActive 进行更新- 在您发布的 sp_WhoIsActive 屏幕截图中，您有几个查询正在等待 ASYNC_NETWORK_IO。对于那些，请参阅上述说明。

在查询的其余部分中，查看 sp_WhoIsActive 的“状态”列 - 其中大多数是“睡眠”。这意味着它们根本不工作——它们在等待管道另一端的应用程序发送下一个命令。他们打开了事务（请参阅“open_tran_count”列），但 SQL Server 无法加速休眠事务。这些查询已经打开了四十多分钟（sp_WhoIsActive 中的第一列。他们只是不再做任何事情。你必须让这些人提交他们的事务并关闭他们的连接。这不是性能调整问题。

我们在这里看到的一切都指向一个我们正在等待应用程序的场景。

Answer 2

回答我自己的问题。ASYNC_NETWORK_IO 实际上并不是真正的问题。我们通过遵循延迟敏感工作负载指南解决了性能问题：

vSphere 虚拟机中延迟敏感型工作负载性能调整的最佳实践

我在这里用黄色标记了我们应用于系统的设置：

我认为影响最大的设置是numa 配置和将延迟敏感度设置为高。这两者都需要为虚拟机显式分配/保留物理 CPU 核心和 RAM。

我们还向虚拟机添加了更多核心，现在需要将 SQL Server 许可证从标准升级到企业。