本文是基于上一篇《SQLServer 2012之AlwaysOn —— 指定数据同步链路,消除网络抖动导致的提交延迟问题》的问题继续进行优化;具体背景请参照上文;
前后折腾了一个多月,最近终于把这块难啃的骨头搞定了。问题只是出在网卡的高级功能上;
解决方案:关闭网卡的高级功能Jumbo Mtu和Large Send Offload V2
问题分析:根据Broadcom Ethernet 网络适配器的解释
Jumbo MtuJumbo Mtu 属性允许网络适配器发送和接收长度大于 1514 字节但小于 9000 字节的超大 Ethernet 帧。此属性要求具有能够处理 Jumbo 帧的交换机。
默认情况下,帧大小设置为 1500 字节。要增加接收帧的大小,可按 500 字节的增量增大字节数量。
Large Send OffloadTCP 分段通常是由协议栈完成。启用 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 —— 指定数据同步链路,消除网络抖动导致的提交延迟问题》操作;
新闻热点
疑难解答