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


9

当我们从一个较早的全闪存阵列迁移到一个较新的全闪存阵列(不同但信誉良好的供应商)时,我们开始发现检查点期间SQL Sentry中的等待时间增加了。

版本:SQL Server 2012 Sp4

在我们的旧存储中,检查点期间的等待时间约为2k,“峰值”为2500,而在新存储中,峰值通常为10k,峰值接近50k。哨兵将我们更多地指向PAGEIOLATCH瓦蒂斯。做我们自己的分析,似乎是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。

我们可以看到,几乎所有等待都在数据页面上,偶尔的PFS为DCM页面类型。等待在用户数据库中,而不在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]数据库正在使用压缩。如果将此数据库还原到Standard Edition Server上,则还原将在2016 SP1之前的版本上失败。* xxxxx-[xxxxxx]数据库正在使用分区。如果将此数据库还原到Standard Edition Server上,则还原将在2016 SP1之前的版本上失败。

优先级240:等待状态:-未检测到重大等待-该服务器可能只是闲置着,或者有人最近清除了等待状态。

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

优先级200:非默认服务器配置:-代理XP-此sp_configure选项已更改。其默认值为0,并且已将其设置为1。-备份压缩默认值-此sp_configure选项已更改。其默认值为0,并且已将其设置为1。-阻止的进程阈值-此sp_configure选项已更改。其默认值为0,并且已将其设置为20。-并行性的成本阈值-此sp_configure选项已更改。其默认值为5,并且已将其设置为30。-数据库邮件XP-已更改此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选项已更改。


忘记提及... SQL 2012 SP4
Doley

你可以运行sp_Blitz@OutputType = 'MARKDOWN'和后的结果?
Kin Shah

我将它们添加到帖子中(我认为有用的帖子)。
多利

您是否完成了I / O繁重的任务,例如重建大索引并将时间与旧SAN进行了比较?它与旧SAN的闪存类型相同吗?卷的布局以及与其他应用程序或服务器共享它们的布局如何?
阿伦(Alen)

1
在新阵列上,数据库,日志和tempdb之间的分隔级别是否相同?Checkpoint猛击数据库文件,但可能与这些驱动器上的其他IO发生冲突。
David Browne-微软

Answers:


1

嗯 您显示的是在检查点期间等待的spid,但不是平均/总计等待的时间(坦白地说,这就是我关心的全部)。进行差异等待统计分析以查看持续时间是否值得关注。另外,图表中的两次等待到底是什么?如果您正在等待1TB RAM的情况下获得大量的内存授予等待,我们需要进行其他讨论。:-D

检查点期间125 MB的写入速度:是仅检查点写入还是ALL?无论哪种方式,全闪存存储都显得很低。您是否针对各种写入模式对上述存储进行了基准测试,如果是,您得到了多少数字?


0

我们不确定为什么我们的SQL Server的行为发生了变化(并且有证据表明发生在存储切换之前),但是为用户DB启用间接检查点已经为我们解决了此问题。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.