Sql server MAXDOP和有趣的性能体验

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

使用我们公司的一款产品，我们可以“连接”到客户端的现有数据库，并将订单导入到我们自己的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;

他发现数据包相对较高

他在谷歌上搜索了一下，发现MAXDOP参数与此有关。 因此，他们转到SSM，将MAXDOP从一个值“0”更改为另一个值“1”，反之亦然

一旦参数改变（无论哪个方向），性能立即得到改善。在切换参数之前，CPU非常高（使用该产品几乎不可能），切换之后，CPU使用率立即降至最低。看来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使用率保持与执行脚本之前相同的高水平

我的问题是：你们知道为什么在SSMS中切换MAXDOP会使CPU使用率下降到正常值吗

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

嘿，看看I/O ，将您的性能设置为这样 等等等等等等

---

因为之前有很多CXPacket等待，所以DOP值必须是0（默认值），然后设置为1（禁用并行性）

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

一般来说，如果将MAXDOP设置为1，我会很不高兴-如果必须将其减小，最好尝试将其设置为2或4，然后看看效果如何。

---

同样值得将“并行性成本阈值”提高到高于默认值5的水平（首先尝试25）。这将减少为并行计划考虑的查询数量。

我发现没有任何答案被标记为最佳答案，所以让我尝试帮助您

在搜索web以找到一些帮助，帮助我们诊断高CXPACKET值的原因时，我找到了一篇好文章，其中展示了帮助我们的高CXPACKET值的一些不同方面和原因：

以下是我在文章中找到的建议：

• 不要将MAXDOP设置为1（这永远不是解决方案）。要了解更多信息，请导航到此

• 调查您的查询和CXPACKET历史记录，以了解并确定它是只发生了一次还是两次，因为它可能只是系统中正常工作的异常

• 检查查询使用的表的索引和统计信息，确保它们是最新的

• 检查并行性的成本阈值（CTFP）并确保使用的值适合您的系统

• 检查CXPACKET是否带有锁存器（也可能带有PAGEIOLATCH或SOS调度程序）。如果是这种情况，则应降低MAXDOP值以适合您的硬件

• 检查CXPACKET是否附带LCK_M_XX（通常附带IO_完成和异步IO_完成）。如果是这样，那么并行性就不是瓶颈。对这些等待状态进行故障排除，以找到问题的根本原因和解决方案

---

哪一个修复了它？将MAXDOP设置为1或将其设置为0？使用SSMS，它与将其从1设置为0无关，反之亦然。当一个查询使用多个线程而它们不能完全同时完成分配的任务时，只需更改该值就可以执行技巧.CXPACKET等待。它们不会直接导致高cpu，因为等待线程不会消耗cpu。“性能问题”到底是什么？高CPU？较慢的数据导入？是的，性能问题既有高CPU，也有较慢的数据导入。顺便说一句，我在ServerFault上交叉发布了这个问题，@mrdenny通过切换参数MAXDOP.指出了过期执行计划的方向。我会进一步调查，并在这里发表我的评论。