MAXDOP 是否会影响我应该创建的 tempdb 数据文件的数量?

Ken*_*her 3 sql-server-2008 sql-server sql-server-2008-r2 sql-server-2012 tempdb

根据我的阅读,配置 tempdb 的最佳实践包括创建多个数据文件。我理解的经验法则是,如果您应该创建与最多 8 个逻辑处理器相同数量的数据文件。然后,如果您有 tempdb 争用,请添加一个额外的文件,直到争用消失或您有每 4 个额外的逻辑处理器添加一个额外的文件。因此,如果您有 16 个逻辑处理器,那么您最多可以创建 10 个文件。

我很好奇的是 MAXDOP 是否会对此产生影响?因此,例如,如果我有 12 个逻辑处理器。我已将 MAXDOP 设置为 6,因为它们被分成 2 个 NUMA 节点。这是否意味着我应该为 tempdb 坚持使用 6 个数据文件?或者我是否仍然拥有推荐的处理器总数的 8 或 9?

Aar*_*and 5

我不会添加单个附加文件,我每次至少会增加 2 或 4 个。没有多少操作在 cores = 5 上比在 cores = 4 上工作得更好。我认为,当面临争用时,您从 4 个文件变为 5 个文件时不会有太大的改进。我可能会以 4 个为一组(除非你有 6 核处理器,例如,并且想要测试将 SQL Server 限制为 6 核),但是到 16 时如果你仍然有争用,我将不得不怀疑这是否真的接近解决问题 - 特别是因为您最物有所值的是将这些文件中的每一个都放在自己的一组主轴上;您极不可能拥有这么多完全独立的磁盘。

至于 MAXDOP 效果,我认为您不应该那样考虑 MAXDOP。除非您使用关联性并阻止 SQL Server 甚至看到其他 6 个内核,否则这并不意味着所有查询都将使用相同的 6 个内核。所以理论上,一个查询可以使用 1-6 个 CPU,另一个可以使用 7-12 个,如果可以通过让每个 CPU 访问自己的文件来缓解争用(实际上它运行得很好),那么某些并发操作可以受益于 12。

解决 tempdb 争用问题的另一种非常简单的方法是将几个 SSD 驱动器放入盒子中(格式化一个到 80%,用一个预先调整大小的 tempdb 文件填充它,并将另一个驱动器用作备用驱动器 - SSD 寿命可能会有所不同,但保持块未分配可以帮助延长寿命)。这甚至在 SQL Server 2012 的群集中得到支持。无论您尝试配置多少文件,慢速存储始终是一个瓶颈时,尝试从 tempdb 中挤出性能需要花费大量的思考和努力。

一些可能有用的背景阅读,特别是如果你坚持使用 tempdb 的老式旋转磁盘: