如何减少巨大的 CXPACKET & LATCH_EX (ACCESS_METHODS_DATASET_PARENT) 等待时间？

Question

问题

自今年年初以来，由于我们系统中的 SQL 超时，我们一直在经历高度的用户中断。

有问题的 SQL-Server 实例在工作时间内的 CPU 使用率非常高（所有 16 个内核的 CPU 使用率始终高于 90%）。

我们还注意到等待时间非常长：CXPACKET 和 LATCH_EX 的组合约占所有等待的 97%。这在 CXPACKET 和 LATCH_EX 之间分成大约 50/50。

占 LATCH_EX 绝大多数 (>95%) 的非缓冲闩锁等待是 ACCESS_METHODS_DATASET_PARENT。

这表明问题与并行性有关。

等待时间比例的一个例子是：

CXPACKET : 332,301,799 ms
LATCH_EX : 267,955,752 ms
PAGEIOLATCH_SH : 2,955,160 ms

这是 1 月 11 日 08:00-16:24 之间的时间段。

正在考虑的选项

1) 将 MAXDOP 从 0 更改为 4 到 8 之间的值

2) 将并行度的成本阈值从 50 修改为更高的数字

关于如何减轻我们所看到的非常高的 CPU 负载并减少超时的建议最受欢迎，特别是建议的行动方案是否明智，以及将 MAXDOP 和并行成本阈值更改为哪些数字。

背景资料

• SQL-Server 2008 R2 在 AMD Opteron 6180 SE 上运行，其中 16 个内核被分配给这个 SQL-Server 实例。

• 工作负载类型：在工作时间内同时连接 800 个连接；大多数 OLTP 类型的工作负载混合了一些 OLAP。

• Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) ... Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1).24 个内核之间的内存约为 128 Gigs。16 个内核可用于此实例

Answer 1

大多数 OLTP 类型的工作负载，其中混合了一些 OLAP

这是问题所在，而不是 CXPACKET。平行是一种症状，而不是原因。您的“某些” OLAP 工作负载正在执行触发并行性的扫描，这会级联到交换等待时间、可能的缓冲池污染和可能的阻塞（OLAP 扫描后面的 OLTP 工作负载块）。

如果 OLAP 工作负载很好理解并且绝对重要，那么您可以考虑为其添加分配器覆盖索引。但这是一场永远艰苦的战斗。我更愿意看到 OLAP 工作负载及其破坏性扫描，转移到一个专用的盒子上。较新的版本 (SQL Server 2014) 具有可读的辅助和列存储，两者都非常擅长处理分析/临时/OLAP 工作负载。

对于 SQL Server 2008 R2，我会考虑日志传送或复制（尽管我认为没有一个是“完美的”）。

短期：你有一个性能问题，你需要适当地分析它。阅读如何分析 SQL Server 性能。确定造成最大损害的一个或多个查询（请参阅确定问题查询。只有在确定实际问题之后，才能推荐解决方案。

注意：LATCH_EXonACCESS_METHODS_DATASET_PARENT根本与 IO 无关。它与并行性密切相关，因为并行扫描“子”线程必须在父线程上获取的闩锁才能为该子线程分配扫描范围。对它的争用表明并行性效率低下（比实际有用的工作做更多的“家庭作业”）。分区会加剧这种症状，特别是未对齐的分区（因为每个分区都设置了父/子数据集）。错误的基数估计（过时的统计数据？）也可能是罪魁祸首，在不需要时进行并行处理。我所有的建议都是一样的：确定实际的问题查询。