深入理解MySQL——master thread分析

1. master thread的线程分析

master thread的线程优先级别最高。其内部由几个循环(loop)组成:主循环(loop)、后台循环(background loop)、刷新循环(flush loop)、暂停循环(suspend loop)。master thread会根据数据库运行的状态在loop、background loop、flush loop和suspend loop中进行切换。

loop称为主循环,因为大多数的操作都在这个循环中,其中有两大部分操作:每秒钟的操作和每10秒的操作。伪代码如下:
深入理解MySQL——master thread分析_第1张图片
可以看到,loop循环通过thread sleep来实现,这意味着所谓的每秒一次或每10秒一次的操作是不精确的。在负载很大的情况下可能会有延迟(delay),只能说大概在这个频率下。当然,InnoDB源代码中还采用了其他的方法来尽量保证这个频率。
每秒一次的操作包括:

  • 日志缓冲刷新到磁盘,即使这个事务还没有提交(总是)。
  • 合并插入缓冲(可能)。
  • 至多刷新100个InnoDB的缓冲池中的脏页到磁盘(可能)。
  • 如果当前没有用户活动,切换到background loop(可能)。

即使某个事务还没有提交,InnoDB存储引擎仍然会每秒将重做日志缓冲中的内容刷新到重做日志文件。这一点是必须知道的,这可以很好地解释为什么再大的事务commit的时间也是很快的。

合并插入缓冲(insert buffer)并不是每秒都发生。InnoDB存储引擎会判断当前一秒内发生的IO次数是否小于5次,如果小于5次,InnoDB认为当前的IO压力很小,可以执行合并插入缓冲的操作。

同样,刷新100个脏页也不是每秒都在发生。InnoDB存储引擎通过判断当前缓冲池中脏页的比例(buf_get_modified_ratio_pct)是否超过了配置文件中innodb_max_dirty_pages_pct这个参数(默认为90,代表90%),如果超过了这个阈值,InnoDB存储引擎认为需要做磁盘同步操作,将100个脏页写入磁盘。

总结上述3个操作,伪代码可以进一步具体化,如下所示:
深入理解MySQL——master thread分析_第2张图片
接着来看每10秒的操作,包括如下内容:

  • 刷新100个脏页到磁盘(可能)。
  • 合并至多5个插入缓冲(总是)。
  • 将日志缓冲刷新到磁盘(总是)。
  • 删除无用的Undo页(总是)。
  • 刷新100个或者10个脏页到磁盘(总是)。
  • 产生一个检查点(总是)。

在以上的过程中,InnoDB存储引擎会先判断过去10秒之内磁盘的IO操作是否小于200次。如果是,InnoDB存储引擎认为当前有足够的磁盘IO操作能力,因此将100个脏页刷新到磁盘。接着,InnoDB存储引擎会合并插入缓冲。不同于每1秒操作时可能发生的合并插入缓冲操作,这次的合并插入缓冲操作总会在这个阶段进行。之后,InnoDB存储引擎会再执行一次将日志缓冲刷新到磁盘的操作,这与每秒发生的操作是一样的。

接着InnoDB存储引擎会执行一步full purge操作,即删除无用的Undo页。对表执行update、delete这类操作时,原先的行被标记为删除,但是因为一致性读(consistent read)的关系,需要保留这些行版本的信息。

但是在full purge过程中,InnoDB存储引擎会判断当前事务系统中已被删除的行是否可以删除,比如有时候可能还有查询操作需要读取之前版本的Undo信息,如果可以,InnoDB会立即将其删除。从源代码中可以发现,InnoDB存储引擎在操作full purge时,每次最多删除20个Undo页。

然后,InnoDB存储引擎会判断缓冲池中脏页的比例(buf_get_modified_ratio_pct),如果有超过70%的脏页,则刷新100个脏页到磁盘;如果脏页的比例小于70%,则只需刷新10%的脏页到磁盘。
最后,InnoDB存储引擎会产生一个检查点(checkpoint),InnoDB存储引擎的检查点也称为模糊检查点(fuzzy checkpoint)。

InnoDB存储引擎在checkpoint时并不会把所有缓冲池中的脏页都写入磁盘,因为这样可能会对性能产生影响,而只是将最老日志序列号(oldest LSN)的页写入磁盘。

现在,我们可以完整地把主循环(main loop)的伪代码写出来了,内容如下:

深入理解MySQL——master thread分析_第3张图片
深入理解MySQL——master thread分析_第4张图片

接着来看background loop,若当前没有用户活动(数据库空闲时)或者数据库关闭时,就会切换到这个循环。这个循环会执行以下操作:

  • 删除无用的Undo页(总是)。* 合并20个插入缓冲(总是)。
  • 跳回到主循环(总是)。
  • 不断刷新100个页,直到符合条件(可能,跳转到flush loop中完成)。

如果flush loop中也没有什么事情可以做了,InnoDB存储引擎会切换到suspend_loop,将master thread挂起,等待事件的发生。若启用了InnoDB存储引擎,却没有使用任何InnoDB存储引擎的表,那么master thread总是处于挂起状态。

最后,master thread完整的伪代码如下:

深入理解MySQL——master thread分析_第5张图片
深入理解MySQL——master thread分析_第6张图片
从InnoDB Plugin开始,用命令SHOW ENGINE INNODB STATUS可以查看当前master thread的状态信息,如下所示:

深入理解MySQL——master thread分析_第7张图片
这里可以看到主循环执行了45次,每秒sleep的操作执行了45次(说明负载不是很大),10秒一次的活动执行了4次,符合1:10。background loop执行了6次,flush loop执行了6次。因为当前这台服务器的压力很小,所以能在理论值上运行。但是,如果是在一台压力很大的MySQL服务器上,我们看到的可能会是下面的情景:
深入理解MySQL——master thread分析_第8张图片

可以看到当前主循环运行了2188次,但是循环中的每一秒钟SLEEP的操作只运行了1537次。这是因为InnoDB对其内部进行了一些优化,当压力大时并不总是等待1秒。所以说,我们并不能认为1_second和sleeps的值总是相等的。在某些情况下,可以通过两者之间差值的比较来反映当前数据库的负载压力。

2. master thread的潜在问题

在了解了master thread的具体实现过程后,我们会发现InnoDB存储引擎对于IO其实是有限制的,在缓冲池向磁盘刷新时其实都做了一定的硬性规定(hard coding)。在磁盘技术飞速发展的今天,当固态磁盘出现时,这种规定在很大程度上限制了InnoDB存储引擎对磁盘IO的性能,尤其是写入性能。

从前面的伪代码来看,无论何时,lnnoDB存储引擎最多都只会刷新100个脏页到磁盘,合并20个插入缓冲。如果是在密集写的应用程序中,每秒中可能会产生大于100个的脏页或是产生大于20个插入缓冲,此时master thread似乎会“忙不过来”,或者说它总是做得很慢。

即使磁盘能在1秒内处理多于100个页的写入和20个插入缓冲的合并,由于hard coding,master thread也只会选择刷新100个脏页和合并20个插入缓冲。同时,当发生岩机需要恢复时,由于很多数据还没有刷新回磁盘,所以可能会导致恢复需要很快的时间,尤其是对于insert buffer。

这个问题最初是由Google的工程师Mark Callaghan提出的,之后InnoDB对其进行了修正并发布了补丁。InnoDB存储引擎的开发团队参考了Google的patch,提供了类似的方法来修正该问题。

因此InnoDB Plugin开始提供了一个参数,用来表示磁盘IO的吞吐量,参数为innodb_io_capacity,默认值为200。对于刷新到磁盘的数量,会按照innodb_io_capacity 的百分比来刷新相对数量的页。规则如下:

  • 在合并插入缓冲时,合并插入缓冲的数量为innodb_io_capacity数值的5%。
  • 在从缓冲区刷新脏页时,刷新脏页的数量为innodb_io_capacity。

如果你使用了SSD类的磁盘,或者将几块磁盘做了RAID,当你的存储拥有更高的IO 速度时,完全可以将innodb_io_capacity的值调得再高点,直到符合你的磁盘IO的吞吐量为止。

另一个问题是参数innodb_max_dirty_pages_pct的默认值,在MySQL5.1版本之前(包括5.1),该值的默认值为90,意味着脏页占缓冲池的90%。但是该值“太大”了,因为你会发现,InnoDB存储引擎在每1秒刷新缓冲池和flush loop时,会判断这个值,如果大于innodb_max_dirty_pages_pct,才刷新100个脏页。因此,如果你有很大的内存或你的数据库服务器的压力很大,这时刷新脏页的速度反而可能会降低。同样,在数据库的恢复阶段可能需要更多的时间。

在很多论坛上都有对这个问题的讨论,有人甚至将这个值调到了20或10,然后测试发现性能会有所提高,但是将innodb_max_dirty_pages_pct调到20或10会增加磁盘的压力,对系统的负担还是会有所增加。Google对这个问题进行了测试,可以证明20并不是一个最优值。而从InnoDB Plugin开始,innodb_max_dirty_pages_pct默认值变为了75,和Google测试的80比较接近。这样既可以加快刷新脏页的频率,也能保证磁盘IO的负载。

InnoDB Plugin带来的另一个参数是innodb_adaptive_flushing(自适应地刷新),该值影响每1秒刷新脏页的数量。

原来的刷新规则是:如果脏页在缓冲池所占的比例小于innodb_max_dirty_pages_pct时,不刷新脏页。大于innodb_max_dirty_pages_pct时,刷新100个脏页,而innodb_adaptive_flushing参数的引入,InnoDB存储引擎会通过一个名为buf_flush_get_desired_flush_rate的函数来判断需要刷新脏页最合适的数量。

粗略地翻阅源代码后你会发现,buf_flush_get_desired_flush_rate是通过判断产生重做日志的速度来判断最合适的刷新脏页的数量。因此,当脏页的比例小于innodb_max_dirty_pages_pct时,也会刷新一定量的脏页。

通过上述的讨论和解释,从InnoDB Plugin开始,master thread的伪代码最终变成了:

深入理解MySQL——master thread分析_第9张图片深入理解MySQL——master thread分析_第10张图片
很多测试都显示,InnoDB Plugin较之以前的InnoDB存储引擎在性能方面有了极大的提高,其实这与以上master thread的改动是密不可分的,因为InnoDB存储引擎的核心操作大部分都是在master thread中。

你可能感兴趣的:(深入理解MySQL,mysql,MySQL源码分析,MySQL源码,master,thread分析,innodb)