本文是基于上一篇《SQLServer 2012之AlwaysOn —— 指定数据同步链路,消除网络抖动致使的提交延迟问题》的问题继续进行优化;具体背景请参照上文;html
先后折腾了一个多月,最近终于把这块难啃的骨头搞定了。问题只是出在网卡的高级功能上;windows
解决方案:关闭网卡的高级功能Jumbo Mtu和Large Send Offload V2网络
问题分析:根据Broadcom Ethernet 网络适配器的解释并发
Jumbo Mtu
Jumbo Mtu 属性容许网络适配器发送和接收长度大于 1514 字节但小于 9000 字节的超大 Ethernet 帧。此属性要求具备可以处理 Jumbo 帧的交换机。 dom
默认状况下,帧大小设置为 1500 字节。要增长接收帧的大小,可按 500 字节的增量增大字节数量。tcp
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将严重影响性能;url
在网上搜了一把,此类问题的影响还比较常见
http://www.peerwisdom.org/2013/04/03/large-send-offload-and-network-performance/
下图是优化前的性能曲线,图中表示方法调用TP99指标在100~300ms之间抖动
下图是优化后的性能曲线,能够看到优化后的方法调用TP99指标在100~150ms范围内,且比较平稳;
尽管WSFC再也不像Windows Cluster同样要有心跳线,但为了不大量的数据同步对应用访问链路形成影响,仍是建议增长直连线(或专用的数据同步网络),并修改endpoint_url使其生效,具体方法能够参照《SQLServer 2012之AlwaysOn —— 指定数据同步链路,消除网络抖动致使的提交延迟问题》操做;