MAXDOP和有趣的性能体验

时间:2013-04-15 21:34:36

标签: sql-server performance

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

使用我们公司的一个产品,我们“连接”到客户端的现有数据库,并将订单导入我们自己的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相对较高。

他用google搜索了一下,发现MAXDOP参数与它有关。 所以他们去了SSMS并将MAXD​​OP从一个值“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.   ,像这样设置你的PerfMon   等等。

2 个答案:

答案 0 :(得分:2)

我认为没有答案被标记为最佳答案,所以让我试着帮忙。

在网上搜索以找到帮助诊断我们方面的高CXPACKET值的原因时,我点击了一篇很好的文章,其中显示了一些不同的方面和高CXPACKET值的原因,这些都帮助了我们:http://www.sqlshack.com/troubleshooting-the-cxpacket-wait-type-in-sql-server/

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

  • 不要将MAXD​​OP设置为1(这绝不是解决方案)。要了解详情,请导航至此page

  • 调查您的查询和CXPACKET历史记录,以了解并确定它是仅发生过一次或两次的事情,因为它可能只是系统中通常正常工作的例外

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

  • 检查并行成本阈值(CTFP),并确保使用的值适合您的系统

  • 检查CXPACKET是否附带LATCH_XX(可能还有PAGEIOLATCH_XX或SOS_SCHEDULER_YIELD)。如果是这种情况,则应降低MAXDOP值以适合您的硬件

  • 检查CXPACKET是否附带LCK_M_XX(通常附带IO_COMPLETION和ASYNC_IO_COMPLETION)。如果是这种情况,那么并行性不是瓶颈。对这些等待统计信息进行故障排除以找出问题的根本原因和解决方案

答案 1 :(得分:0)

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

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

我不满意MAXDOP一般设置为1 - 如果必须减少它,最好尝试将其设置为2或4,看看它是如何进行的。 同样值得将“并行度的成本门槛”提高到高于默认值5(初学者尝试25)。这将减少考虑并行计划的查询数量。