使用Server 2014同步AlwaysOn的高延迟

Question

我在我们的开发环境中构建了一个由2个节点组成的SQL 2014集群。非共享磁盘

Specifications:

• 存储是灵活的存储阵列，有专用的LUN提供给管理程序，每个客户上的每个驱动器(数据、日志、tempdb)都有一个专用的LUN。
• LUN的缓存在SSD上，延迟在数组上，LUN的缓存在0.25ms以下，用于读写。
• 此测试的整个数据集为<350 is
• vSphere 6.0U1
• 2个相同的VM(WindowsServer2012R2 STD)
  • 10 vCPU
  • 64 Ram
  • 存储在专用VMDK的- pVSCSCi上，所有VMDK都是厚厚的-EAGERZERO.
  • VMXNET3
  • Server 2014 SP1-CU5

• AG名称是AG02
• 主节点为SQL2K14-02。
• 次要节点为SQL2K14-01。
• 同步模式
• 自动故障转移

生产数据库的一个副本显示插入延迟了1000 in，因此在以下场景中使用HammerDB (www.hammerdb.com)运行了相同的测试：

1. HammerDB - Node1，no AG
2. HammerDB - Node2，no AG
3. HammerDB - AG1，Sync (Node1+Node2)
4. HammerDB - AG1，异步(Node1+Node2)

发现：

1. 测试1和测试2的性能是一样的，所以我们知道我们没有一个节点来减缓我们的速度。
2. 使用AG1作为同步，事务延迟时间为1000 as /秒，这是非常糟糕的，我们无法弄清楚原因。HADR_SYNC_COMMIT的等待时间到处都是。
3. 使用带有异步的AG1，我们有0延迟，但这是我们不能使用的。
4. 我能够排除网络延迟，因为两个VM都在同一个VLAN上。同时做一个恒定的ping + tcpping + iperf，延迟小于0.3ms，而两个服务器都在TCP上推送> 3Gbit/s。
5. 下面是AG相关指标的图表。
6. 在insert (它是运行顺序插入命令(或更新或删除)的单个会话期间，我在该会话上运行了一个跟踪，并看到持续时间与下面的图表完全相同。
7. 当没有同步(意为异步，或直接在每个节点上)运行相同的测试时，我没有看到任何延迟，每个操作的持续时间为0(零)。

问题

• 发生了什么，为什么会有第二次的延迟？
• 我以为我做错了什么，但没有在文档中找到任何东西。

谢谢，伊丹。

Answer 1

@sean，我完全了解这些指标，这就是我收集的。尽管如此，SQL集群还是让人窒息。并花费了超过1秒(从客户端应用程序的时间)。在向微软提出问题后(这并没有帮助)。

从存储数组中根本没有延迟，所以这不是问题所在。

最后，我决定将vSphere版本从6.0U1升级到6.0U2，这解决了这个问题。在查看vSphere更改日志时，没有任何东西是“修复”的，这可能会使我更早地走向这个方向。

总之，谢谢大家的支持。如果有人遇到这种行为，应该检查实际的驱动程序(物理的或虚拟的)。

Answer 2

把我的评论变成回答。

当涉及到可用性组时，对于某些性能计数器是如何工作的，似乎存在一些误解。只有同步提交副本才会被计算为Transaction Delay (ms)/Sec，异步提交副本不会改变这个计数器，因为它们不会传输镜像事务(是的，这可以被称为更好的东西)。

让我纠正原问题中思维过程中的一些假设。

2.使用AG1作为同步，事务延迟时间为1000 as /s，这是非常糟糕的，我们无法弄清楚原因。HADR_SYNC_COMMIT的等待时间到处都是。

在真空状态下，事务延迟( Transaction，ms)/Sec只意味着您至少有两个同步提交副本。这是因为只有同步提交副本才有此值，因为我们等待来自其他同步副本的确认，即数据已增强。

为了获得完整的图片，并获得每个事务的平均延迟开销，我们需要捕获Mirrored Transactions/Sec计数器。这个计数器将给出有多少同步提交事务被“镜像”到其他同步副本。如果我们取Transaction Delay (ms)/Sec并除以Mirrored Transactions/Sec计数器，最终结果将是每个事务的ms的平均延迟。

3.使用带有异步的AG1，我们有0延迟，但这是我们不能使用的。

这一点都不准确。事实上，更大的延迟是在异步提交副本上增强事务块，只是我们不像同步一样等待它们的增强。因此，仍然存在延迟(您的网络并没有神奇地变成一个非等待环境)，它只是不包括在特定的计数器中，因为该计数器只包含用于同步提交副本和事务的信息。

6. insert是运行顺序插入命令(或更新或删除)的单个会话，在此期间，我在该会话上运行了跟踪，发现持续时间与下图完全相同。

几乎没有足够的信息让我相信这是事实。即使在一些相当糟糕的基础设施上，我通常也能看到200到300毫秒，而且每笔交易没有接近1秒的信息。

7.在没有同步(意为异步，或直接在每个节点上)的情况下运行相同的测试时，我没有看到任何延迟，每个操作的持续时间为0(零)。

见我对3.的答复，这也是对这一问题的同样回答。

跟踪

1. 捕获两个计数器，Transaction Delay (ms)/Sec和Mirrored Transactions/Sec，并回发结果。
2. 根据特定的工作负载进行测试，因为工作负载类型的更改将极大地影响响应时间。