MySQL 内核深度优化
MYSQL数据库适用场景广泛,相较于Oracle、DB2性价比更高,Web网站、日志系统、数据仓库等场景都有MYSQL用武之地,但是也存在对于事务性支持不太好(MySQL 5.5版本开始默认引擎才是InnoDB事务型)、存在多个分支、读写效率瓶颈等问题。
所以如何用好MYSQL变得至关重要,一方面需要通过MYSQL优化找出系统读写瓶颈,提高数据库性能;另一方面需要合理涉及数据结构、调整参数,以提高用户操作响应;同时还有尽可能节省系统资源,以便系统可以提供更大负荷的服务。本文将为大家介绍腾讯云团队是如何对Mysql进行内核级优化的思路和经验。
早期的CDB主要基于开源的Oracle MySQL分支,侧重于优化运维和运营的OSS系统。在腾讯云,因为用户数的不断增加,对CDB for MySQL提出越来越高的要求,腾讯云CDB团队针对用户的需求和业界发展的技术趋势,对CDB for MySQL分支进行深度的定制优化。优化重点围绕内核性能、内核功能和外围OSS系统三个维度展开,具体的做法如下:
一.内核性能的优化
由于腾讯云上的DB基本都需要跨园区灾备的特性,因此CDB for MySQL的优化主要针对主从DB部署在跨园区网络拓扑的前提下,重点去解决真实部署环境下的性能难题。经过分析和调研,我们将优化的思路归纳为:“消除冗余I/O、缩短I/O路径和避免大锁竞争”。以下是内核性能的部分案例:
1.主备DB间的复制优化
问题分析
如上图所示,在原生MySQL的复制架构中,Master侧通过Dump线程不断发送Binlog事件给Slave的I/O线程,Slave的I/O线程在接受到Binlog事件后,有两个主要的动作:
- 写入到Relay Log中,这个过程会和Slave SQL线程争抢保护Relay Log的锁。
- 更新复制元数据(包含Master的位置等信息)。
优化方法
经过分析,我们的优化策略是:
- Slave I/O线程和Slave SQL线程是典型的单写单读生产者-消费者模型,是可以做到无锁设计的;因此实现思路就是SlaveI/O线程在每次写完数据后,原子更新Relay Log的长度信息,Slave SQL线程读取RelayLog的时以长度信息为边界。这样就将原本竞争激烈的Relay Log锁化解为无锁;
- 由于Binlog事件中的GTID(Global Transaction Identifier)和DB事务是一一对应的关系,所以RelayLog中的数据本身已经包含了所需要的复制元数据,所以我们可以不写Master info文件,消除了冗余的文件I/O;
- 于DB都是以事务为更新粒度的,因为在RelayLog文件I/O上,我们通过合并离散小I/O为事务粒度的大I/O等手段,使磁盘I/O得以大幅提升。
优化效果
如上图所示,经过优化:左图35.79%的锁竞争(futex)已经被完全消除;同压测压力下,56.15%的文件I/O开销被优化到19.16%,Slave I/O线程被优化为预期的I/O密集型线程。
2.主库事务线程和Dump线程间的优化
问题分析
如上图所示,在原生MySQL中多个事务提交线程TrxN和多个Dump线程之间会同时竞争Binlog文件资源的保护锁,多个事务提交线程对Binlog执行写入,多个Dump线程从Binlog文件读取数据并发送给Slave。所有的线程之间是串行执行的!
优化方法
经过分析,我们的优化策略是:
- 将读写分离开来,多个写入的线程还是在锁保护下串行执行,每一个写入线程写入完成后更新当前Binlog的长度信息,多个Dump线程以Binlog文件的长度信息为读取边界,多个Dump线程之间并行执行。以这种方式来让复制拓扑中的Dump线程发送得更快!
效果
经过测试,优化后的内核,不仅提升了事务提交线程的性能,在Dump线程较多的情况下,对主从复制性能有较大提升。
二.主备库交互流程优化
问题分析
如上图所示,在原生MySQL中主备库之间的数据发送和ACK回应是简单的串行执行,在上一个事件ACK回应到达之前,不允许继续发送下一个事件;这个行为在跨园区(RTT 2-3ms)的情况性能非常差,而且也不能很好地利用带宽优势。
优化方法
经过分析,我们的优化策略是:
- 将发送和ACK回应的接收独立到不同的线程中,由于发送和接收都是基于TCP流的传输,所以时序性是有保障的;这样发送线程可以在未收ACK之前继续发送,接受线程收到ACK后唤醒等待的线程执行相应的任务。
效果
根据实际用例测试,优化后的TPS提升为15%左右。
三.内核功能的优化
1. 预留运维帐号连接数配额
在腾讯云上,不时遇到用户APP异常或者BUG从而占满DB的最大连接限制,这是CDB OSS帐号无法登录以进行紧急的运维操作。针对这个现状,我们在MySQL内核单独开辟了一个可配置的连接数配额,即便在上述场景下,运维帐号仍然可以连接到DB进行紧急的运维操作。极大地降低了异常情况下DB无政府状态的风险。该帐号仅有数据库运维管理权限,无法获取用户数据,也保证了用户数据的安全性。
2. 主备强同步
针对一些应用对数据的一致性要求非常高,CDB在MySQL原生半同步的基础上进行了深度优化,确保一个事务在主库上提交之前一定已经复制到至少一个备库上。确保主库宕机时数据的一致性。
四.外围系统的优化
除了以上提到的MySQL内核侧的部分优化,我们也在外围OSS平台进行了多处优化。例如使用异步MySQL ping协议实现大量实例的监控、通过分布式技术来加固原有系统的HA/服务发现和自动扩容等功能、在数据安全/故障切换和快速恢复方面也进行了多处优化。
在此我向大家推荐一个架构学习交流群。交流学习群号:478030634 里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多
注:关注作者Q群,了解更多分布式架构、微服务、netty、MySQL、spring、性能优化、等知识点。点击链接加入群聊【Java架构师之路】:点击打开链接
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
教育、金融核心业务0故障?看阿里云护航云上的尖峰时刻
2018年云栖大会上海峰会,阿里云资深技术专家王维对保障云上尖峰时刻护航进行了分享。阿里云护航教育、金融核心业务0故障。王维就云上护航服务概念,近几年业务的迅速发展带来的典型业务场景及所面临的挑战、技术要点及案例进行了深入的解析。 数十款阿里云产品限时折扣中,赶快点击这里,领券开始云上实践吧直播视频请点击PPT下载请点击以下是精彩视频内容整理: 云上护航 对于企业系统云,阿里云希望在云上构建一个柔性和弹性的系统来支撑业务的快速发展,支撑业务转型、突破和进化。 如上图所示是客户业务的发展,从上云开始不断地有新业务上线、大促、周年促销、周年店庆和“双十一”大促等。业务得到了快速的发展,给IT系统带来非常大的挑战。 典型业务场景—及更多挑战 云上护航在金融保险的整个企业发展过程中经历了很多的挑战,其中包括系统的容量性能、稳定性等;云上护航在游戏行
- 下一篇
另一个角度的架构师
架构师要做什么? ADMEMS矩阵,明确介绍了架构师需要思考的问题,而在这个矩阵中,做完一个架构师最需要了解的什么呢?技术?业务?都不是,最需要了解的是你的领导,其次是你的团队成员。 如果你的领导是不懂且不放权的类型,那你的好架构要如何实现呢。如果你的团队技术烂的一塌糊涂,又如何开发出成熟的产品?看看ADMEMS矩阵,理论上是先上后下,先左后右。而现实中,应该是先右后左,先下后上。 看了ADMEMS矩阵,最重要的就是约束,最最重要的就是开发需求对应的约束。那么架构师要如何分析这些呢。 首先分析你的领导 1,确定他是否能清晰的分辨出团队成员技术的高下,这个清晰很重要,要十分清晰。 2,确定他支持你架构设计的力度,(强烈支持,还是设计的好就用不行就不用) 3,确定他是否真的理解了架构的重要性,还是他只是为了给工作计划戴个好看的帽子,还是两者都有。 以上三点只要有一点不满足你的架构基本上就很难实现,为什么是很难而不是不能呢?因为团队成员足以弥补一些领导的能力不足。 接着分析你的团队成员 1,你的团队成员能力差距是否过大。 2,你的团队成员能力高的和低的比例是多少。 正所谓巧妇难为无米之炊,...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- CentOS7安装Docker,走上虚拟化容器引擎之路
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS6,CentOS7官方镜像安装Oracle11G
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- Hadoop3单机部署,实现最简伪集群
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- CentOS关闭SELinux安全模块
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果