1

我正在尝试减少我的 SQL Server 2012 数据库中的 CXPACKET 等待。

为此，我将调整 MAXDOP 和 Cost Threshold for Parallelism。请参阅 Brent Ozar 的文章。

为了衡量更改对等待时间的影响，我使用sys.dm_os_wait_stats并遵循此建议每 15 分钟跟踪一次等待时间。我想在调整前和调整后 2 周读取 2 周的读数。

但是，我也对跟踪整体查询性能感兴趣。什么是查看查询在更改之前和之后的执行情况的好方法 - 在相同的 2 周之前/2 周之后的时间范围内？是否有 sprocs 可以为我提供这些数据？

4

3 回答 3

1

在运行大量大型查询的环境中，您总是会看到 CXPacket 位于等待列表的顶部，这不是问题。唯一的问题是当它开始飙升超过你的正常等待时。在这些情况下，这通常意味着您的统计数据相距甚远，以至于无法获得准确的执行计划，您需要研究更好的索引维护。

从你所说的来看，我没有理由仅仅基于这一点来降低 MaxDOP。相反，我会采用最多 8 个的典型建议，并且不超过 OLTP 的单个 NUMA 节点中的核心数量。

在您的情况下，我将开始使用Query Stats以及根据服务器端跟踪的最大查询来查看您最昂贵的查询。如果您能够调整您在此处看到的最大违规者，那么您将拥有更快的服务器以及更低的 CXPacket 等待类型。

作为免责声明，我是您提到的等待统计文章以及此回复中链接到的文章的作者。

请随时在此处回复此问题或在我的博客上回复任何其他问题。

于 2013-10-11T13:06:33.267 回答
1

CXPACKET 等待不一定表示并行性问题——它通常是其他问题的症状。

当一个查询并行时，假设有 10 个线程，并且这 10 个线程中的一个线程比其他线程花费更长的时间来完成它的工作，其他 9 个线程将累积 CXPACKET 等待。

您还看到了哪些其他高等待类型？

于 2013-09-26T13:25:11.283 回答
1

基于以上内容，您似乎可以使用一些实用程序来帮助您监控查询性能。

我可以推荐 ApexSQL Monitor（一个商业工具，但提供免费试用），它可以存储历史信息，这样您就可以在减少 MAXDOP 之前和之后查看详细信息 - 并且您可以查看整体查询性能。

除此之外，您还可以在这篇文章http://www.sqlshack.com/troubleshooting-the-cxpacket-wait-type-in ​​-sql-server/ 中找到关于 CXPACKET 和 MAXDOP 可能原因的一个很好的解释。以下是这篇文章的一些关键要点：

在诊断高 CXPACKET 等待统计值的原因时推荐的步骤（在做出任何本能反应并在 SQL Server 上更改某些内容之前）：

  • 不要将 MAXDOP 设置为 1，因为这永远不是解决方案
  • 调查查询和 CXPACKET 历史以了解并确定它是否只发生了一次或两次，因为它可能只是系统中正常工作的异常
  • 检查查询使用的表的索引和统计信息，并确保它们是最新的
  • 检查并行成本阈值 (CTFP) 并确保使用的值适合您的系统
  • 检查 CXPACKET 是否带有 LATCH_XX（也可能带有 PAGEIOLATCH_XX 或 SOS_SCHEDULER_YIELD）。如果是这种情况，则应降低 MAXDOP 值以适合您的硬件
  • 检查 CXPACKET 是否带有 LCK_M_XX（通常带有 IO_COMPLETION 和 ASYNC_IO_COMPLETION）。如果是这种情况，那么并行性就不是瓶颈。对这些等待统计信息进行故障排除，以找到问题的根本原因和解决方案
于 2016-10-07T07:56:34.500 回答