高 CXPACKET 和 LATCH_EX 等待
stu*_*mct 14 performance sql-server parallelism wait-types query-performance
我正在处理的数据处理系统存在一些性能问题。我从一小时的 peroid 中收集了等待统计数据，其中显示了大量的 CXPACKET 和 LATCH_EX 等待事件。
该系统由 3 个处理 SQL Server 组成，它们进行大量的数字运算和计算，然后将数据馈送到中央集群服务器。处理服务器最多可以同时运行 6 个作业。这些等待统计数据适用于我认为导致瓶颈的中央集群。中央集群服务器有 16 个内核和 64GB RAM。MAXDOP 设置为 0。
我猜 CXPACKET 来自正在运行的多个并行查询，但是我不确定 LATCH_EX 等待事件表示什么。从我读到的这可能是一个非缓冲等待？
任何人都可以建议这种等待统计的原因是什么，以及我应该采取什么行动来调查这个性能问题的根本原因？
顶部查询结果是总等待统计数据，底部查询结果是 1 小时内的统计数据
小智 9
CXPACKET 可以带有 LATCH_XX（也可能带有 PAGEIOLATCH_XX 或 SOS_SCHEDULER_YIELD）。如果是这种情况（我相信是这样，基于问题）那么 MAXDOP 值应该降低以适合您的硬件。
除此之外，这里有一些更推荐的步骤，用于诊断高 CXPACKET 等待统计值的原因（在 SQL Server 上更改某些内容之前）：
不要将 MAXDOP 设置为 1，因为这永远不是解决方案
调查查询和 CXPACKET 历史以了解并确定它是否只发生了一次或两次，因为它可能只是正常工作的系统中的异常
检查查询使用的表的索引和统计信息，并确保它们是最新的
检查并行成本阈值 (CTFP) 并确保使用的值适合您的系统
检查 CXPACKET 是否伴随着 LCK_M_XX（通常伴随着 IO_COMPLETION 和 ASYNC_IO_COMPLETION）。如果是这种情况，那么并行性就不是瓶颈。对这些等待统计信息进行故障排除以找到问题的根本原因和解决方案
如果您真的需要深入了解 CXPACKET 等待类型，我建议您阅读SQL Server文章中的对 CXPACKET 等待类型进行故障排除
阅读诊断和解决 SQL Server 上的闩锁争用，是关于该主题的最全面的论文。您必须深入研究sys.dm_os_latch_stats并查看争用的闩锁类型。
看看阅读如何分析 SQL Server 性能是否对您有任何帮助。