HADR_SYNC_COMMIT的奇怪情况等待


11

我们注意到HADR_SYNC_COMMIT在我们的环境中等待的一种有趣模式。我们有三个副本。数据中心中有一个主,一个同步辅助和一个异步辅助,我们刚刚在另一个数据中心(相距约2400英里)中添加了三个ASYNC副本。

从那时起,我们开始注意到HADR_SYNC_COMMIT等待的数量大大增加。当我们查看活动会话时,我们看到一堆COMMIT TRANSACTION查询在SYNC副本上等待

从屏幕截图中,我们可以清楚地看到HADR_SYNC_COMMIT6月29日的等待时间有所增加,我们最终于7月1日中午某个时候在远程数据中心删除了三个异步副本中的“两个”。这大大减少了等待时间。

图片

到目前为止,我们已检查的内容–日志发送队列,重做队列,远程副本上的上次强化时间和上次提交时间。我们在工作时间内连续发生小笔交易,因此在给定的时间戳(介于60KB和1MB之间的任何地方),发送队列非常小。
远程副本几乎是同步的,副本上任何单独的lsn的上次提交时间和上次强化时间之间的差异很小。

网络管道为10G,我们将传输缓冲区的大小从256兆修改为2兆,这是在假定网络正在丢弃数据包并重新传输数据的前提下完成的。两种方法似乎都没有太大帮助。

因此,我想知道ASYNC副本与HADR_SYNC_COMMIT等待有什么关系?SYNC副本不应该仅依赖于此等待类型吗,我在这里缺少什么?


1
那么实际上有问题吗?很多人只是看着他们的等待,然后说,嘿,这是最高的等待,一定是一个问题!等待只是一个数字,总会有一个数字最大-这不一定意味着要解决性能问题。特别是对于这种等待,似乎您已经排除了最常见的原因,并且由于您的中学工作并没有落后,因此我不会在这个“问题”上花费很多精力,直到
Aaron Bertrand

您还会在等待计数器中出现一些其他症状,并带有较高的数字,并且可以将其与等待计数器较高相关联。
亚伦·伯特兰

@AaronBertrand是的,有。主副本上的活动spid等待日志块在同步辅助副本上变硬,这种延迟/等待又导致应用程序速度大大降低。您在屏幕快照中看到的pagelatch_up等待时间是7月9日,是由于tempdb争用(等待pfs页面),我们从dba端添加了更多文件,应用程序人员对存储过程进行了调优,以非常频繁地命中tempdb,以缓解该问题。回到hadr_sync_waits,为什么异步提交首先会影响hadr_sync_commits?谢谢。
阿伦·戈皮纳斯

1
我猜想等待时间包括传输时间,并且数据是一起传输的,异步只是不必等待提交确认。因此,无论同步还是异步,您拥有的辅助服务器越多,将花费更多的时间来传输日志活动(这不一定是时钟时间,因为其中一些可能是并发的)。您可能想让网络人员尝试查看是否存在一般性的或添加更多次要节点的不适当延迟。
亚伦·伯特兰

Answers:


7

首先,您的问题所涉及的等待事件的描述是:

等待同步的辅助数据库的事务提交处理以加强日志。事务延迟性能计数器也反映了此等待。对于同步的可用性组,此等待类型是预期的,它指示向辅助数据库发送,写入和确认日志的时间。

https://msdn.microsoft.com/zh-CN/library/ms179984.aspx

深入研究这种等待的机制,您将传输并强化日志块,但是在远程服务器上恢复未完成。在这种情况下,并且考虑到您添加了其他副本,则可以认为由于带宽需求的增加,HADR_SYNC_COMMIT可能会增加。在这种情况下,亚伦·伯特兰德(Aaron Bertrand)对这个问题的评论是完全正确的。

来源:http//blogs.msdn.com/b/psssql/archive/2013/04/26/alwayson-hadron-learning-series-hadr-sync-commit-vs-writelog-wait.aspx

深入探讨有关此等待如何与应用程序速度降低相关的问题的第二部分。我认为这是因果关系问题。您正在等待的时间越来越长,最近的用户投诉越来越多,并且得出的结论可能是错误地认为两者之间确实存在关系,而事实并非如此。您添加了tempdb文件并且您的应用程序对我的响应速度更快的事实表明,当数据库处于可用性组中时,隐式快照隔离级别开销的额外开销可能会加剧一些基础争用问题。这可能与您的HADR_SYNC_COMMIT等待几乎没有关系。

如果要对此进行测试,可以利用扩展事件跟踪,该跟踪在主副本上查看hadr_db_commit_mgr_update_harden XEvent并获取基线。一旦有了基准,就可以一次添加一个副本,并查看跟踪的变化。我强烈建议您使用驻留在不包含任何数据库的卷上的文件,并设置过渡和最大大小。请根据需要调整持续时间过滤器,以收集与您的等待时间相匹配的事件,以便您可以进一步进行故障排除并将其与其他需要参与的团队相关联。

CREATE EVENT SESSION [HADR_SYNC_COMMIT-Monitor] ON SERVER  -- Run this on the primary replica 
ADD EVENT sqlserver.hadr_db_commit_mgr_update_harden(
    WHERE ([delay]>(10))) -- I strongly encourage you to use the delay filter to avoid getting too many events back, this is measured in milliseconds
ADD TARGET package0.event_file(SET filename=N'<YourFilePathHere>')
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO
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.