SQLSERVER 2012之AlwaysOn -- 同步模式下的网卡性能优化

原文:SQLSERVER 2012之AlwaysOn -- 同步模式下的网卡性能优化

本文是基于上一篇《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 —— 指定数据同步链路,消除网络抖动导致的提交延迟问题》操作;

时间: 2024-09-11 08:06:17

SQLSERVER 2012之AlwaysOn -- 同步模式下的网卡性能优化的相关文章

SQLServer 2012之AlwaysOn —— 指定数据同步链路,消除网络抖动导致的提交延迟问题

原文:SQLServer 2012之AlwaysOn -- 指定数据同步链路,消除网络抖动导致的提交延迟问题 事件起因:近期有研发反应,某数据库从08切换到12环境后,不定期出现写操作提交延迟的问题: 事件分析:在排除了系统资源争用等问题后,初步分析可能由于网络抖动导致同步模式alwayson节点经常出现会话超时等待提交的问题导致. 经过排查,扩展事件里发现不定期出现35202错误,这是一条副本连接恢复的消息.   由于机房网络环境复杂,数据库服务器和应用服务器混用一个交换机,在业务高峰期时,因

SQLSERVER 2012之AlwaysOn -- 一次硬件升级引发的问题

原文:SQLSERVER 2012之AlwaysOn -- 一次硬件升级引发的问题 这是上周遇到的一个案例:对已有的硬件进行升级而引发的问题,期间还触发了一个比较严重的BUG,可谓多灾多难:不过值得庆幸的是,在一连串连锁问题出现的时候,并没有出现人工操作失误(这往往是在处理故障中风险最高.影响最大的问题)而扩大故障影响范围:   ==========================华丽丽的分割线==========================     先说一下环境:     我做的是跨机房3

SQL Server AlwaysON 同步模式的疑似陷阱

原文:SQL Server AlwaysON 同步模式的疑似陷阱 SQL Server 2012 推出的最重要的功能之一Alwayson,是一个集之前Cluster和Mirror于一体的新功能,即解决了Cluster依赖共享存储的问题,又解决了镜像不能实时读以及转移后连接串需要添加转移IP的问题,看起来的确很实用. 而且Alwayson多副本的功能为实现读写分离提供了可能,试想一下,当主副本压力比较大的时候,是否可以将读操作引向辅助副本呢?答案一般来讲是肯定的,请注意,是一般! Alwayson

SQLServer 2012异常问题(二)--由安装介质引发性能问题

原文:SQLServer 2012异常问题(二)--由安装介质引发性能问题 问题描述:生产环境一个数据库从SQLSERVER 2008 R2升级到SQLSERVER 2012 ,同时更换硬件,但迁移后发现性能明显下降,应用写入.读取性能下降的比较厉害:   向微软寻求帮助后得出答案,原来这与SQLSERVER的安装介质有关. 大致意思是说由于NUMA架构可以自行管理内存池,在安装了CAL的EE后,由于限制只能使用20个cores,同样内存则只能管理到20个cores涉及到的NUMA的对应的内存空

[文档]桌面虚拟化环境下的交互式性能优化

桌面虚拟化环境下的交互式性能优化 汪小林,周凯,张彬彬,杨亮,罗英伟,李晓明 硬件辅助虚拟化的提出,极大地提高了全虚拟化的性能.但是全虚拟化下类似网络教室等桌面虚拟化应用,在交互式性能方面还存在较大局限.交互式性能主要受I/O 性能的影响:一方面I/O 设备属于慢速设备:另一方面全虚拟化中采用模拟方式来共享设备.对全虚拟化的交互式性能进行了改进,充分利用多核处理器的物理特征来部署配置虚拟机,根据用户行为动态调整虚拟机的使用资源,依据虚拟化特征进行I/O 调度的优化.   temp_1204110

软件定义数据中心条件下的物理基础设施优化之道

DCD上海站在浦东嘉里大酒店召开,在"如何优化物理基础设施,实现软件定义数据中心的顺畅运营"这一专家讨论环节,来自数据中心专业服务商的data24公司总裁罗耀兴与业内专家.分析师们,一起探讨SDDC给数据中心基础设施的规划设计和运营所带来的挑战和机会. SDDC:实现数据中心弹性扩容 在谈到在云计算及SDDC的全新应用模式下,如何进一步优化数据中心.合理规划基础设施的问题时,罗耀兴认为, SDDC从运用的角度提出了如何更有效使用IT系统资源的新思路,力求建立更有动态和弹性的资源配置方式

蚂蚁金服技术专家对性能优化的常见模式及趋势的思考

发表自<中生代>微信公众号.作者是陈显铭,从事研发工作七年,蚂蚁金服技术专家.对于性能优化的思考,很有价值,分享给大家. 从上图可以看出几个优点 成本降低 稳定性提升 用户体验体验提升 性能优化的缺点也有 维护成本增加:代码可能变复杂,结构可能变复杂,技术栈可能变复杂 性能优化的两种模式 个人总结,性能优化整体上可以分为两类:单应用优化和结构型优化. 单应用优化,关注单系统瓶颈,通过解决单系统瓶颈提升性能. 结构型优化,通过改造链路结构和配比,进行整体性能的优化. 单应用优化常见步骤 优化基本

性能优化的常见模式及趋势 | 陈显铭

性能优化的价值 从上图可以看出几个优点 成本降低 稳定性提升 用户体验体验提升 性能优化的缺点也有 维护成本增加:代码可能变复杂,结构可能变复杂,技术栈可能变复杂 性能优化的两种模式 个人总结,性能优化整体上可以分为两类:单应用优化和结构型优化. 单应用优化,关注单系统瓶颈,通过解决单系统瓶颈提升性能. 结构型优化,通过改造链路结构和配比,进行整体性能的优化. 单应用优化常见步骤 优化基本思路(闭环) 确定性能瓶颈/热点 确定优化方案 实施.反馈优化情况 确定性能瓶颈/热点的常见方法 性能压测:

AlwaysON同步的原理及可用模式

新一代读写分离技术--AlwaysOn 早在SQL Server 2005的时候微软就已经实现了数据库的查询分离技术--发布订阅.但生产库和查询库的同步性能较差,时常出现性能问题,因此在大型生产环境中一直被人所诟病. 从SQL Server 2012开始,微软逐渐使用AlwaysON技术来取代发布订阅.AlwaysOn 作为SQL Server 2012引入的一种新的技术架构,性能相比发布订阅而言提升很多,最明显的区别在于其充分利用内存高效读取的原理来实现日志的传递.下文将通过AlwaysOn的