升级到更好的存储后检查点期间的等待时间增加

Question

当我们从旧的全闪存阵列迁移到新的全闪存阵列（不同但成熟的供应商）时，我们开始看到检查点期间 SQL Sentry 中的等待增加。

版本：SQL Server 2012 Sp4

在我们的旧存储上，我们的等待时间约为 2k，在检查点期间“峰值”达到 2500，而新存储的峰值通常为 10k，峰值接近 50k。Sentry 将我们更多地指向PAGEIOLATCHwatis。做我们自己的分析，这似乎是PAGEIOLATCH and PAGELATCH等待的组合。使用 Perfmon，我们通常可以说我们检查点的页面越多，我们得到的等待就越多，但我们在检查点期间只刷新了大约 125 mb。我们的工作量主要是写入（主要是插入/更新）。

存储供应商已向我们证明，在这些检查点事件期间，光纤通道直连阵列的响应时间不到 1 毫秒。HBA 还会确认阵列的编号。我们也不认为这是 HBA 队列问题，因为队列深度从未超过 8。我们还尝试了更新的 HBA，更改 ZIO、执行限制和队列深度设置无济于事。我们还将服务器的内存从 500 GB 增加到 1 TB，没有任何变化。在检查点过程中，我们确实看到 2 - 4 个独立内核（共 16 个）飙升至 100%，但整体 CPU 约为 20%。BIOS 也设置为高性能。有趣的是，我们确实看到 CPU 通常处于 C2 睡眠状态，即使我们已经禁用了它，所以我们仍在研究为什么睡眠状态会超过 C1。

我们可以看到几乎所有的等待都在数据页上，偶尔会有 DCM 页面类型的 PFS。等待在用户数据库中，而不是 tempdb。我们还看到等待跨越多个数据页，一些 SPID 在同一页上等待。数据库设计确实有几个插入热点，但旧存储采用了相同的设计。

运行这个查询的循环 100 次，我们能够捕捉到有多少 SPID 在磁盘与内存上等待

SELECT
    [owt].[wait_type], count(*) as waitcount
FROM sys.dm_os_waiting_tasks [owt]
WHERE [owt].[wait_type] LIKE 'PAGE%'
group by [owt].[wait_type]
order by 1
GO 100

“不错”的事情是我们可以轻松地在我们的性能环境中重现该问题，该环境具有相同的模型阵列和类似的服务器规格。我很感激任何关于在哪里查看或如何缩小问题范围的想法。现在，我们的下一个测试包括： 具有更新主板和更多 CPU 的新服务器；禁用 SIOS 数据管理器（即使旧存储已使用此功能）；不同的 HBA 品牌。

exec sp_Blitz @outputtype = 'markdown'

优先级 5：可靠性： - 危险的第三方模块 - Sophos Limited - Sophos 缓冲区溢出保护 - SOPHOS~2.DLL - 安装了疑似危险的第三方模块。

优先级 200：信息性： - 集群节点 - 这是集群中的一个节点。- TraceFlag On - 全局启用跟踪标志 1117。- 全局启用跟踪标志 1118。- 全局启用跟踪标志 3226。

优先级 200：许可： - 正在使用的企业版功能 * xxxxx - [xxxxxx] 数据库正在使用压缩。如果将此数据库还原到标准版服务器上，则在 2016 SP1 之前的版本上还原将失败。* xxxxx - [xxxxxx] 数据库正在使用分区。如果将此数据库还原到标准版服务器上，则在 2016 SP1 之前的版本上还原将失败。

优先级 240：等待统计： - 未检测到重要等待 - 该服务器可能只是闲置，或者最近有人可能清除了等待统计。

优先级 250：服务器信息： - 硬件 - 逻辑处理器：16。物理内存：512G​​B。- 硬件 - NUMA 配置 - 节点：0 状态：ONLINE 在线调度程序：8 离线调度程序：0 处理器组：0 内存节点：0 内存 VAS 保留 GB：1177 - 节点：1 状态：ONLINE 在线调度程序：8 离线调度程序：0 处理器组：0 内存节点：1 内存 VAS 保留 GB：0 - 电源计划 - 您的服务器具有 3.50GHz CPU，并处于高性能电源模式 - 服务器上次重启 - 2018 年 7 月 4 日凌晨 4:56 - SQL Server 上次重启 - 7 月 5 日2018 年 5:11AM - SQL Server 服务 - 版本：11.0.7462.6。补丁级别：SP4。版本：企业版（64 位）。启用的可用性组：1. 可用性组管理器状态：1 - 虚拟服务器 - 类型：（HYPERVISOR） - Windows 版本 - 您正在运行一个非常现代的 Windows 版本：Server 2012R2 时代，版本 6.3

优先级 200：非默认服务器配置: - Agent XPs - 此 sp_configure 选项已更改。它的默认值为 0，并且已设置为 1。 - 备份压缩默认值 - 此 sp_configure 选项已更改。它的默认值为 0 并且它已设置为 1。 - 阻塞进程阈值 (s) - 此 sp_configure 选项已更改。它的默认值为 0，并且已设置为 20。 - 并行成本阈值 - 此 sp_configure 选项已更改。它的默认值为 5，它已设置为 30。 - 数据库邮件 XPs - 此 sp_configure 选项已更改。它的默认值为 0，并且已设置为 1。 - 最大并行度 - 此 sp_configure 选项已更改。它的默认值为 0，并且已设置为 8。 - 最大服务器内存 (MB) - 此 sp_configure 选项已更改。它的默认值是 2147483647，它已设置为 496640。 - 最小服务器内存 (MB) - 此 sp_configure 选项已更改。它的默认值是 0，它已设置为 8196。 - 优化临时工作负载 - 此 sp_configure 选项已更改。它的默认值是 0，它已设置为 1。 - 远程访问 - 此 sp_configure 选项已更改。它的默认值是 1，它已设置为 0。 - 远程管理连接 - 此 sp_configure 选项已更改。它的默认值是 0，它已被设置为 1。 - 扫描启动过程 - 此 sp_configure 选项已更改。它的默认值为 0，并且已设置为 1。 - 显示高级选项 - 此 sp_configure 选项已更改。它的默认值是 0，它已被设置为 1。 - xp_cmdshell - 此 sp_configure 选项已更改。

Answer 1

唔。您显示 spid 在检查点期间等待，但没有显示平均/总计等待多长时间（老实说，这就是我所关心的）。进行差异等待统计分析以查看持续时间是否值得关注。另外，图表中的两个等待到底是什么？如果您在使用 1TB RAM 时遇到大量内存授予等待，我们需要进行不同的讨论。:-D

检查点期间的 125MB 写入速度：只是检查点写入还是全部？无论哪种方式，全闪存存储的成本似乎都很低。您是否对各种写入模式的存储进行了基准测试？如果是，您得到了多少数字？