標籤:
本文是基於上一篇《SQLServer 2012之AlwaysOn —— 指定資料同步鏈路,消除網路抖動導致的提交延遲問題》的問題繼續進行最佳化;具體背景請參照上文;
前後折騰了一個多月,最近終於把這塊難啃的骨頭搞定了。問題只是出在網卡的進階功能上;
解決方案:關閉網卡的進階功能Jumbo Mtu和Large Send Offload V2
問題分析:根據Broadcom Ethernet 網路介面卡的解釋
Jumbo Mtu
Jumbo Mtu 屬性允許網路介面卡發送和接收長度大於 1514 位元組但小於 9000 位元組的超大 Ethernet 幀。此屬性要求具有能夠處理 Jumbo 幀的交換器。
預設情況下,幀大小設定為 1500 位元組。要增加接收幀的大小,可按 500 位元組的增量增大位元組數量。
Large Send Offload
TCP 分段通常是由協議棧完成。啟用 Large Send Offload 屬性時,TCP 分段可由網路介面卡完成。
Disable: 禁用 Large Send Offload。
Enable (預設值): 啟用 Large Send Offload。
Large Send Offload是網路介面卡的進階功能之一,其目的是在網路介面卡端進行TCP的分段工作,以此來降低CPU以及其他相關裝置的壓力;但隨著多核CPU的廣泛應用,網路介面卡的處理能力相較於CPU弱了很多,因此當大量並發請求導致資料頻繁更新或大資料量傳送時,開啟Large Send Offload將嚴重影響效能;
在網上搜了一把,此類問題的影響還比較常見
http://www.bitdefender.com/support/Large-Send-Offload-causes-performance-and-slowdown-issues-459.html
http://www.peerwisdom.org/2013/04/03/large-send-offload-and-network-performance/
https://social.technet.microsoft.com/Forums/windowsserver/en-US/bdc40358-45c8-4c4b-883b-a695f382e01a/very-slow-network-performance-with-intel-nic-when-tcp-large-send-offload-is-enabled
是最佳化前的效能曲線,圖中表示方法調用TP99指標在100~300ms之間抖動
是最佳化後的效能曲線,可以看到最佳化後的方法調用TP99指標在100~150ms範圍內,且比較平穩;
儘管WSFC不再像Windows Cluster一樣要有心跳線,但為了避免大量的資料同步對應用訪問鏈路造成影響,還是建議增加直連線(或專用的資料同步網路),並修改endpoint_url使其生效,具體方法可以參照《SQLServer 2012之AlwaysOn —— 指定資料同步鏈路,消除網路抖動導致的提交延遲問題》操作;
SQLSERVER 2012之AlwaysOn -- 同步模式下的網卡效能最佳化