主页 / dba / 问题 / 131050
Accepted
John K. N.
Asked: 2016-03-03 08:53:22 +0800 CST

多实例 SQL Server Standard Editon MaxDop 设置

  • 772

看了标题还是一头雾水？好吧，我也是。

我刚刚开始为一家新雇主担任 DBA 的新工作，并且遇到了一些安装 SQL Server 的创造性方法。我以前使用 SQL Server 的经验都是基于在虚拟或物理硬件上运行的单个 MSSQLSERVER 实例。我们过去常常避免 SQL Server 的多实例安装，只是为了让一切真正分离和简单。

在我的新雇主那里，他们在一个虚拟硬件上集成了很多 SQL Server Standard Edition 实例。他们的（嗯，我想我现在应该称之为我们的……）推理：

  • 在一件（虚拟）硬件上拥有多个 SQL Server 实例可以减少整个环境中 SQL Server 的数量和许可成本。

我还没有发现这种配置背后的任何其他原因。

绝对没有可用性组或事务复制正在进行，事务日志传送也没有实现。

服务器已配置为具有默认实例和多个附加实例，如下所述。

SQL 服务器环境

SQL Server 配置为包含多个实例。

服务器到实例的关系

每个 SQL Server 可以有 1 到n 个实例

SQL_SERVER_01 (Standard Edition SQL Server)
\ MSSQLSERVER (default instance)
\ VARIOUS_INS (the 2nd instance)
\ SOMETHINGNW (the 3rd instance)
\ A_NAMEGIVEN (the 4th instance)
\ INSTANCENEW (the xth instance)

实例 | 知识产权 | 港口 | 别名 (CNAME)

每个实例都与一个 IP 地址相关，每个 IP 地址都有一个单独的别名 (CNAME)，因此 SQL Server 可以始终侦听端口 1433。这简化了防火墙配置，因为只需为默认 SQL Server 端口添加规则. 嗯。

MSSQLSERVER | 10.0.0.22 | 1433 | SQL_SERVER_01_I00
VARIOUS_INS | 10.0.0.23 | 1433 | SQL_SERVER_01_I01
SOMETHINGNW | 10.0.0.24 | 1433 | SQL_SERVER_01_I02
A_NAMEGIVEN | 10.0.0.25 | 1433 | SQL_SERVER_01_I03
INSTANCENEW | 10.0.0.26 | 1433 | SQL_SERVER_01_I04

因此，对于在同一台虚拟服务器上运行的每个 SQL Server 实例，网络团队必须为虚拟 NIC 提供一个 IP 地址，并为该实例的 IP 地址创建一个 CNAME/别名。必须为每个虚拟 NIC 配置正确的 IP 地址，并且必须为每个实例的 IP 地址正确配置 SQL Server 配置（侦听此 IP 地址，激活此 IP 地址，....）。SQL Server 不会响应典型的 SERVER\INSTANCE 表示法，这意味着服务器只能通过别名/CNAME 访问（例如 SQL_SERVER_01_I00）

（虚拟）硬件

在我忘记之前，我认为让您了解为此类 SQL Server 实例配置的典型虚拟硬件可能是个好主意。

磁盘

虚拟磁盘在 VMware 中预先配置并附加到 SQL Server。一些硬件供应商在后台。可能是 IBM，可能是 Hitachi，.... MDF 文件的磁盘和 LDF 文件的磁盘。

处理器

是的，多个处理器。在此示例中，四个逻辑处理器 @2.9 GHz

记忆

该服务器只有 32GB。每个 SQL Server 实例都配置为消耗 1GB 到 4GB 的内存。例如，该服务器有 6 个实例，每个实例包含 1 ... 10 个数据库，大小从几百 MB 到几 GB 不等。没什么大不了的。

SQL Server 实例配置

每个 SQL Server 实例将配置如下。

最大并行度

默认 (0)

记忆

最小内存将设置为 256 MB，最大内存将设置为 1GB 到 4GB 之间。

亲和面具

未配置。

最大并行度的代价

默认 (5)

我的想法

根据我的经验，我了解到在配置设置和分析问题时，拥有单个实例是最好的。但这似乎不是一个选择。所以没有必要朝那个方向开始讨论。我知道。

我认为只有 4 个逻辑处理器和所有七个实例的 MAX_DOP 都设置为 0 并且后台有多个数据库是一个坏主意。如果一个系统滞后，那么它们都会严重滞后。

问题

鉴于您已经了解了我的环境，我想有人会有类似的配置，并且能够为我提供一些脚本来分析所有内容，或者能够为我指明正确的建议方向。

开始：

  1. 假设我目前只有 4 个逻辑处理器用于 6 个实例并且 MAX_DOP 设置为 0，我是否应该为每个实例至少配备一个逻辑处理器？
  2. 如果每个实例有一个逻辑处理器，我应该将 MAX_DOP 保留为 0 还是将每个实例限制为 MAX_DOP = 1？
  3. 鉴于它是标准版，我是否应该将 MAX_DOP 限制为 4 作为替代方案？

我不着急，我确实有一些时间可以花。我只是很好奇是否有人遇到过与我相同的情况以及您/他们是如何处理这种情况的。

谢谢你的时间。

sql-server configuration

1 个回答

  1. Best Answer

    1. 考虑到我目前只有 4 个逻辑处理器用于 6 个实例并且 MAX_DOP 设置为 0，我是否应该为每个实例至少配备一个逻辑处理器？

    这取决于每个实例平均使用多少 CPU 使用率？您可以从正在运行的默认运行状况会话扩展事件中获取此信息（假设 2008+）。

    四个逻辑处理器可能完全适合这种工作负载——在我们有数据之前我们不会知道。话虽如此，由于 SQL Server 的每个实例都独立运行并且不知道安装的其他实例，我确信 Windows 对交换线程不太满意。

    我会查看我的等待统计数据 dmv，看看我们在 signal_wait 部分的等待时间百分比是否更高，这表明调度问题和实例之间可能存在的争用。此外，我会通过 cpu 上下文切换来确定这一点，以查看是否与实例运行状况的“糟糕时期”和“良好时期”之间存在微弱或直接的相关性。

    不过，我的直觉告诉我，除非这些是可悲的未充分利用的实例，否则此服务器必然会出现问题 - 无论它们是现在发生还是几个月后发生。

    2. 如果每个实例有一个逻辑处理器，我应该将 MAX_DOP 保留为 0 还是将每个实例限制为 MAX_DOP = 1？

    MAXDOP 仅限制单个并行查询在执行期间可能使用的逻辑处理器（“调度程序”）的数量。没有什么可以阻止 SQL Server 运行多个并行查询；事实上，我已经为甚至不知道他们有调度问题的地方多次诊断并解决了这个问题（它被视为“阻塞”问题）。

    将 MAXDOP 设置为 1 实质上会使所有用户查询成为单线程。同样，这不会阻止 SQL Server 一次执行多个任务，因为它只是强制串行执行。这意味着每个实例都有四 (4) 个可见的在线调度程序，总共有4*x 个可能的并发查询实例。在这里设置 MAXDOP 并不能解决逻辑上负担过重的问题，没有考虑到虚拟服务器的实际设置是否可以在超线程（如果启用）内核上运行。哎呀。

    我并不是说强制 MAXDOP 为 1 是好是坏，只是我们没有数据可以继续。因此我们不知道设置的影响。不过，我绝对不会将其设置为四 (4)！

    3. 鉴于它是标准版，我是否应该将 MAX_DOP 限制为 4 作为替代方案？

    好吧，它不能高于四 (4)，所以它已经受到限制。我认为，这个问题与上述问题密切相关。希望我已经将其解释到令人满意的理解水平。

    如果您想了解（由于并行性的小阈值）有多少查询被并行化，您可以检查执行计划 dmv。这是一个相当昂贵的操作，所以请在所有实例之间的几个小时或几乎没有使用的时间进行。请记住，由于服务器的共享性质，您对一个实例所做的操作将（大致）对所有实例执行。

    • 4

相关问题