开发者社区> 技术小能手> 正文

MySQL中sync_relay_log选项对I/O thread的影响分析

简介: MySQL中sync_relay_log选项对I/O thread的影响分析
+关注继续查看

搭建好的一套从库,发现延迟很高,一直追不上,从库的bin_log没开,flush_log_at_trx_commit设置为0,简化的状态如下:

image

发现Master_Log_File,Read_Master_Log_Pos一直进展比较缓慢,一般来说内网的瓶颈不会在网络,同时一般I/O THREAD并不存再CPU密集型操作,那么瓶颈很可能在I/O,使用iotop命令查看服务器I/O情况如下:

image

发现MYSQL线程LWP号为44706 的线程I/O非常高,但是写入只有600来K,明显这种情况是不正常的。

一般来说,LINUX有KERNEL BUFFER/CACHE,write只是写入到KERNEL BUFFER/CACHE就好了;

例外就是以dirctor写入方式,这种方式依赖的是用户态缓存,还有就是写入调用了大量的fsync之类的同步kernel cache/buffer到磁盘的系统调用。

然后查看这个LWP号是否为I/O thread如下,因为5.7可以非常轻松的找到MYSQL conn_id和系统LWP之间的关系如下:

image

确实发现这个大量I/O的确实是MYSQL从库的I/O thread,那么接下来的就是进行strace看看到底为什么这么慢,strace片段如下:

image

我们发现文件描述符fd=50的文件有大量的写入而且频繁的调用fdatasync来同步磁盘,消耗时间非常可观,是MUTEX调用和write操作的N倍,我们可以通过/proc/pid目录下找到文件描述符和文件的对应关系,那么我们就看看文件描述符50到底是什么,如下:

image

确实是我们的replay log。
那么问题就确定了,就是因为replay log的写入调用了大量的fdatasync造成的I/O THREAD非常慢,那么是哪一个参数呢?
其实参数就是sync_relay_log,这个参数用来保证relay log的安全,官方文档有如下的图:

image

我们可以看到如果不设置sync_relay_log那么有可能造成relay log丢失的风险,其实上面的分析已经看到就是调用fdatasync来完成这个功能,但是
这样的代价基本是不可接受的。

官方文档有如下说明:

It is important to note the impact of sync_relay_log=1, which requires a write of to the relay log per transaction. Although this setting is the most resilient to an unexpected halt, with at most one unwritten transaction being lost, it also has the potential to greatly increase the load on storage. Without sync_relay_log=1, the effect of an unexpected halt depends on how the relay log is handled by the operating system.

A value of 1 is the safest choice because in the event of a crash you lose at most one event from the relay log. However, it is also the slowest choice (unless the disk has a battery-backed cache, which makes synchronization very fast).

每次事务都会调用fdatasync,代价太高。所以没办法修改了sync_relay_log的设置,默认值是10000,也就是10000个事务进行一次fdatasync。

原文发布时间为:2018-06-29
本文作者:八怪
本文来自云栖社区合作伙伴“ 老叶茶馆”,了解相关信息可以关注“ 老叶茶馆”。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
ThreadLocal内存溢出代码演示和原因分析!(4)
ThreadLocal内存溢出代码演示和原因分析!(4)
31 0
ThreadLocal内存溢出代码演示和原因分析!(5)
ThreadLocal内存溢出代码演示和原因分析!(5)
20 0
IDA反汇编/反编译静态分析iOS模拟器程序(五)F5反编译
反编译是IDA最让人振奋的功能,它的本质是IDA的一个插件,不过会被当做hex-rays的另一个产品。既然是产品,那当然就另外收费,demo版是没有的。
1242 0
IDA反汇编/反编译静态分析iOS模拟器程序(二)加载文件与保存数据库
启动windows版的IDA,在Quickstart界面点击New,弹出一个对话框选择文件。也可以按取消后再把文件拖进IDA。由于Mac版的IDA没注册,没有save功能,所以只好先把Mac上的东西拷贝到windows再打开了。
1147 0
面经手册 · 第20篇《Thread 线程,状态转换、方法使用、原理分析》
大部分考试考的,基本都是不怎么用的。例外的咱们不说😄 就像你做程序开发,尤其在RPC+MQ+分库分表,其实很难出现让你用一个机器实例编写多线程压榨CPU性能。很多时候是扔出一个MQ,异步消费了。如果没有资源竞争,例如库表秒杀,那么其实你确实很难接触多并发编程以及锁的使用。 但!凡有例外,比如你需要开发一个数据库路由中间件,那么就肯定会出现在一台应用实例上分配数据库资源池的情况,如果出现竞争就要合理分配资源。如此,类似这样的中间件开发,就会涉及到一些更核心底层的技术的应用。
51 0
Java多线程编程:变量共享分析(Thread)
在编写多线程程序时,最重要的就是搞清楚哪些变量是共享的,哪些变量是不共享的。也就是要分析清楚其中的原理呀。 因为最近要使用多线程就看了一些,对使用Thread类的子类创建线程的情况,总结如下: 1.方法体内部定义的局部变量不共享    这是因为方法内部定义的变量是在运行时动态生成的。
1009 0
ThreadLocal内存溢出代码演示和原因分析!(6)
ThreadLocal内存溢出代码演示和原因分析!(6)
21 0
+关注
技术小能手
云栖运营小编~
7195
文章
9
问答
文章排行榜
最热
最新
相关电子书
更多
JS零基础入门教程(上册)
立即下载
性能优化方法论
立即下载
手把手学习日志服务SLS,云启实验室实战指南
立即下载