將 SQL Server 網路數據包大小與 mtu 匹配是否會提高性能
我們最近將生產設施升級到 sql server 2017，並遷移到無集群可用性組。有一個主節點、一個現場輔助節點和一個遠端輔助節點。我們遇到與遠端輔助同步的周期性中斷。頻寬低至 6G，sql 流量與所有其他流量競爭。好消息是 AG 會在 5-15 分鐘後“趕上”。在調查是否有什麼辦法可以改善這種情況時，我通過實驗發現網路 MTU 為 1400，並且 sql 的網路數據包大小設置為預設值 4092。作為實驗，我將數據包大小設置為 1400 以匹配MTU。我們已經有好幾天沒有收到關於 AG 的警報了，所以它“似乎”有幫助。
我的問題是這樣做是否正確？我已經讀過很多次了，除非 MS 也建議您，否則不要更改網路數據包大小，並且永遠不要將其設置為低於預設值 4096。然而……它似乎有幫助。因此，我正在尋找類似情況下更有經驗的人的意見。
TLDR：如果對您有幫助，請將其設置得較低，監控您的數據包大小以查看您發送的數據包是否超出您的需要。
MTU 控制每個網路段在每個伺服器之間的所有點上的大小，想想 traceroute 躍點 - MTU 大致控製網段在 2 個躍點之間的大小。特定分段上的 MTU 越小，數據包越有可能通過多個分段發送。這通常很好，除非您有一個特別繁忙的段。
數據包大小控制 sql 中每個 TDS 數據包可以發送多少數據。每個 TDS 數據包都有一個標頭，因此有一些額外的成本。數據包越小，您需要發送數據的數據包就越多，請注意：
- 如果您要發送的數據包總是小於最大數據包大小，那麼您可以將最大數據包大小設置為 16k，這沒有什麼區別，因為您可以容納在一個數據包中。
如果您只呼叫名為“a”且沒有參數的儲存過程，並且響應只是一個儲存過程狀態程式碼，那麼您可以將最大數據包大小設置為 50 之類的小值。如果您有非常大的請求（大量的數百行選擇語句) 並且響應中有很多行，那麼您可能希望數據包大小盡可能大，以避免更多數據包標頭的成本。
當你有一個高錯誤連接時，TCP 會阻礙並發送重傳，這會進一步阻塞網路，當封包遺失時，一切都會被阻止，直到發送失去的那些，所以通常會出現高錯誤率和大量重傳對性能真的很不利。具有較小的數據包大小會導致更多的數據包，從而導致失去數據包的可能性更大，這反過來意味著更多的重傳和等待失去位的延遲。
那麼較小的數據包大小不好嗎？通常，但這實際上取決於您的網路。
我會做兩件事，首先獲取 Microsoft 消息分析器 ( https://www.microsoft.com/en-gb/download/details.aspx?id=44226 ) 並跟踪每台伺服器並查找 TCP 重新傳輸，如果你有很多這樣的錯誤率很高，這表明您需要發送更少的數據包，因此數據包的大小更大。
在消息分析器中，您可以添加一列來顯示 TDS PacketSize，因此如果您將最大數據包大小設置為 1000，並且您看到大量大小為 1000 的數據包，然後是大量大小為 1 的數據包，那麼理想的數據包可能是 1001 或 1002。
第二件事是看看像 tds nitro 這樣的東西，它壓縮 TDS，這樣你就可以減少數據包，這可能有助於高延遲高錯誤連接（http://nitrosphere.com/nitroaccelerator/）
和