将 SQL Server 网络数据包大小与 mtu 相匹配可提高性能

Question

我们最近将生产设施升级到 SQL Server 2017，并迁移到无集群可用性组。有一个主要设备、一个现场辅助设备和一个远程辅助设备。我们遇到与远程辅助同步的周期性中断。带宽低至6G，sql流量与所有其他流量竞争。好消息是AG会在5-15分钟后“追上”。在研究是否可以采取任何措施来改善这种情况时，我通过实验发现网络 MTU 为 1400，并且 sql 的网络数据包大小设置为默认值 4092。作为实验，我将数据包大小设置为 1400 以匹配MTU。我们已经好几天没有收到有关 AG 的警报了，所以它“似乎”得到了帮助。

我的问题是这样做是否正确？我已经读过很多次，除非 MS 也建议你，否则不要更改网络数据包大小，并且永远不要将其设置为小于默认值 4096。然而......它似乎有所帮助。因此，我正在寻找类似情况下更有经验的人的意见。

Answer 1

TLDR：如果对您有帮助，请将其设置得较低，监视您的数据包大小以查看您发送的数据包是否超出您的需要。

\n\n

MTU 控制每个服务器之间的所有点上的每个网段可以有多大，想想路由跟踪跃点 - MTU 大致控制 2 个跃点之间的网段有多大。某一特定网段上的 MTU 越小，数据包通过多个网段发送的可能性就越大。这通常没问题，除非您有一个特别繁忙的部分。

\n\n

数据包大小控制 sql 中每个 TDS 数据包可以发送的数据量。每个 TDS 数据包都有一个标头，因此会产生一些额外的开销。数据包大小越小，发送数据所需的数据包就越多，但需要注意以下事项：

\n\n

\n
• 如果您要发送的数据包始终小于最大数据包大小，那么您可以将最大数据包大小设置为 16k 之类，这不会产生任何影响，因为您可以放入一个数据包中。
\n

\n\n

如果您只调用名为 \xe2\x80\x9ca\xe2\x80\x9d 的存储过程而不带任何参数，并且响应仅是存储过程状态代码，那么您可以将最大数据包大小设置为很小的值，例如 50。大请求（大量数百行选择语句）和响应中的大量行，那么您需要尽可能大的数据包大小，以避免更多数据包标头的开销。

\n\n

当您有一个高错误连接时，TCP 会妨碍并发送重传，这进一步堵塞网络，并且当数据包丢失时，一切都会被阻止，直到丢失的数据包发送为止，因此通常会出现大量重传的高错误率对于性能来说确实很糟糕。数据包大小越小，数据包就越多，从而导致丢失数据包的可能性越大，这又意味着等待丢失位的重传和延迟会更多。

\n\n

那么较小的数据包大小是否不好？通常情况下，但这实际上取决于您的网络。

\n\n

我会做两件事，首先获取 Microsoft Message Analyzer ( https://www.microsoft.com/en-gb/download/details.aspx?id=44226 ) 并在每台服务器上进行跟踪，然后查找 TCP 重新传输，如果您如果有很多这样的数据包，那么错误率就会很高，这表明您需要发送更少的数据包，从而提高数据包大小。

\n\n

在消息分析器中，您可以添加一列来显示 TDS PacketSize，因此如果您将最大数据包大小设置为 1000，并且您看到许多大小为 1000 的数据包，然后看到许多大小为 1 的数据包，那么理想的可能是 1001 或 1002。

\n\n

第二件事是查看诸如 tds 硝基之类的东西，它可以压缩 TDS，这样您最终可以得到更少的数据包，这可能有助于高延迟高错误连接（http://nitrosphere.com/nitroaccelerator/）

\n\n

埃德

\n