本文是基于上一篇《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.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 —— 指定数据同步链路，消除网络抖动导致的提交延迟问题》操作；
- 5楼sqlct
- 肖总，弱弱问一句，TP99是啥？
- Re: 我是大菠萝
- @sqlct，这是我们自己应用端的方法调用监控。指标可以用TP99TP999表示，，意思是在一个统计周期内，同一个调用方法的返回时间，按照倒序排列，取1%的value就是TP99，1%/10的value就是TP999；，用这个指标来表示方法调用的性能，越大表示返回的越慢
- 4楼CareySon
- 太高端了...顶
- Re: 我是大菠萝
- @CareySon，搜了一下，上溯到08年就有人提出这个问题；也有说是网卡驱动和windows的兼容问题导致；，做运维DBA难啊，啥都得知道点
- 3楼老玉米
- 太牛了,必须顶!!!
- 2楼ShanksGao
- 不错,菠萝兄,Jumbo config在win中的应用还是不多见的,linux中应用较多,此外虚拟化的解决方案中经常会涉及.赞!
- Re: 我是大菠萝
- @ShanksGao，开始一直以为是交换机流量大导致的副本重连，后来加了直连线还是不行。还好有MS支持，最终定位在网卡设置上
- 1楼maxhema
- 太高端了...顶