0

我想就以下主题提出一些建议。

使用我们公司的一种产品，我们“连接”到客户方的现有数据库，并将订单导入我们自己的 SQL Server，让我们的桌面产品计划和优化它们。它们适用于不同的货车，它们将采取不同的路线将货物从 A 运送到 B。

在导入期间，我们遇到了一些性能问题，可以通过以下方式解决：

我们已经制定了几个维护计划（据我所知，这并不总是最好的方法，我们现在遵循 Ola Hallengren 的维护解决方案）来重建索引和更新统计信息。

但是性能问题仍然存在。

前 DBA 试图诊断 SQL Server 发生了什么，他使用了这个脚本：

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

SELECT 'Identify what is causing the waits.' AS [Step01];
SELECT TOP 10
        [Wait type] = wait_type,
        [Wait time (s)] = wait_time_ms / 1000,
        [% waiting] = CONVERT(DECIMAL(12,2), wait_time_ms * 100.0 / SUM(wait_time_ms)     OVER())
FROM sys.dm_os_wait_stats
WHERE wait_type NOT LIKE '%SLEEP%'
ORDER BY wait_time_ms DESC;

他发现 CXPACKET 一直比较高。

他搜索了一下，发现 MAXDOP 参数与它有关。所以他们去了 SSMS 并将 MAXDOP 从一个值“0”更改为另一个值“1”，反之亦然。

一旦参数改变（无论哪个方向），性能立即变得更好。在切换参数之前，CPU 非常高（几乎不可能使用该产品）在切换之后它立即进入最小 CPU-Usage。看起来好像 SQL Server 无聊得要死。

如果我们的人试图将 MAXDOP 切换到每个脚本的其他值：

EXEC sys.sp_configure N'show advanced options', N'1'  RECONFIGURE WITH OVERRIDE
GO
EXEC sys.sp_configure N'max degree of parallelism', N'1'
GO
RECONFIGURE WITH OVERRIDE
GO
EXEC sys.sp_configure N'show advanced options', N'0'  RECONFIGURE WITH OVERRIDE
GO

令人惊讶的是，它根本没有显示出任何效果。CPU-Usage 与执行脚本前一样高。

我对你们的问题是：你们知道为什么在 SSMS 中切换 MAXDOP 会使 CPU-Usage 降低到正常值吗？

我知道我不能指望一个完全令人满意的答案，因为我对那个故事的细节不够详细。但如果你能指出我正确的方向，我将不胜感激

嘿，看看 I/O，像这样设置你的 PerfMon，等等等等。

4

2 回答 2

2

我看到没有答案被标记为最佳答案，所以让我尝试并提供帮助。

在网上搜索以找到一些帮助我们诊断高 CXPACKET 值的原因时，我找到了一篇很好的文章，该文章显示了对我们有帮助的高 CXPACKET 值的一些不同方面和原因： http ://www.sqlshack.com/故障排除-cxpacket-wait-type-in​​-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-06-22T12:40:38.463 回答
0

由于之前有很多 CXPacket 等待，因此 DOP 值必须为 0（默认），后来设置为 1（禁用并行性）。

围绕这个话题有很多争议。对于高度优化的纯 OLTP 负载可能没问题，但大多数负载是混合的，并且往往包含通常会受益于并行性的“繁重”查询。

一般来说，我不会对将 MAXDOP 设置为 1 感到满意 - 如果您必须减少它，最好尝试将其设置为 2 或 4，看看效果如何。同样值得将“并行成本阈值”提高到高于默认值 5（初学者尝试 25）的值。这将减少考虑用于并行计划的查询数量。

于 2013-04-16T14:26:22.903 回答