高CXPACKET和LATCH_EX等待

我正在使用的数据处理系统存在一些性能问题。我从一个小时的周期中收集了等待统计信息，其中显示了大量CXPACKET和LATCH_EX等待事件。

该系统由3个处理SQL Server组成，这些SQL Server进行了大量的数字运算和计算，然后将数据馈送到中央群集服务器中。处理服务器可以一次最多运行6个作业。这些等待统计数据是针对我认为正在引起瓶颈的中央集群的。中央群集服务器具有16个核心和64GB RAM。MAXDOP设置为0。

我猜CXPACKET来自正在运行的多个并行查询，但是我不确定LATCH_EX等待事件指示什么。从我读到的内容来看，这可能是非缓冲等待？

谁能说出这种等待统计的原因是什么，我应该采取什么行动来调查这个性能问题的根本原因？

顶部查询结果是等待的总计统计信息，底部查询结果是1小时内的统计信息

CXPACKET可以附带一个LATCH_XX（可能还附带PAGEIOLATCH_XX或SOS_SCHEDULER_YIELD）。如果是这种情况（基于这个问题，我相信是这样），则应降低MAXDOP值以适合您的硬件。

除此之外，以下是一些建议的步骤，用于诊断CXPACKET等待统计值较高的原因（在SQL Server上进行更改之前）：

• 不要将MAXD​​OP设置为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性能》对您有任何帮助。

除了阅读上面提供的链接之外，最有可能将“最大并行度”设置从0更改为类似8的内容，您还希望缩小哪些查询并行进行以及它们的成本是多少。

在看到此更改的影响后，您还可以考虑修改“并行度的成本阈值”以微调并行进行的操作。

这是来自Brent Ozar的精彩视频，将为您提供帮助：掌握CXPACKET和MAXDOP的艺术

您的目标是等待CXPACKET的时间少于50％。祝好运！！