use*_*606 3 sql-server parallelism maxdop sql-server-2016
我们的 MS SQL Server 2016 数据库运行缓慢,我一直在使用 Brent Ozar 的急救箱进行一些初步故障排除。
我看到大量 CXPACKET 等待类型,在 17.5 小时的数据样本中,我们看到 10 个 CPU 的等待时间为 99 小时,即 55.5%!
我希望这里有人可以确认我们应该关注这个数字并尽快解决它。我们的 MAXDOP 设置为 4,这与 MS 的建议是准确的,但我们的 CTP 设置为 5,我认为需要更改为 50。
在我将这些信息交给我的老板之前,我只是想澄清一下,是的,我是数据库管理的新手,是的,我正在研究其他等待类型,但这似乎是迄今为止最重要的。
干杯,
乔希
你提到你在 13.0.1745.2 上。这是 SQL Server 的 RTM 版本,实际上从 2018 年 1 月 9 日起不再受支持。
另外,如果您安装 SP2,您将获得新的 CXCONSUMER 等待类型(有关更多信息,请参见此处)。这将“无害”并行等待与您实际上可以做些什么的并行等待分开。这可以帮助您确定 CXPACKET 是否真的是您服务器的问题!
查看 Paul Randal 的这篇文章:Knee-Jerk Wait Statistics : CXPACKET
在其中,他谈到了 CXPACKET 如何成为正常的等待类型——如果查询是并行的,它总是会发生(特别是因为你还没有 CXCONSUMER 拆分)。他还讨论了查询优化如何成为比调整 MAXDOP 和成本阈值更有效的解决方案(找到根本原因):
意外并行的常见情况之一是当表扫描发生在您期望较小的索引查找或扫描时。
他接着说,可以使用索引、统计更新等来消除扫描,因此查询不太可能并行。
如果您确实需要减少 CXPACKET 等待的数量,您可以将 MAXDOP 减少到 2(从当前设置为 4) - 但这可能会引入其他问题。当然,如果您已经通过性能测试确定 4 是适合您系统的设置,请忽略该建议。
另一种选择是增加此值,以防止某些查询完全并行。我已经看到很多建议表明50是一个很好的起点,而不是默认的5(示例)。
| 归档时间: |
|
| 查看次数: |
1196 次 |
| 最近记录: |