《MySQL技术内幕:InnoDB存储引擎第2版》——2.5 Master Thread工作方式-阿里云开发者社区

开发者社区> 华章计算机> 正文

《MySQL技术内幕:InnoDB存储引擎第2版》——2.5 Master Thread工作方式

简介: 本节书摘来自华章计算机《MySQL技术内幕:InnoDB存储引擎第2版》一书中的第2章,第2.5节,作者:姜承尧著, 更多章节内容可以访问云栖社区“华章计算机”公众号查看。
+关注继续查看

2.5 Master Thread工作方式

在2.3节中我们知道了,InnoDB存储引擎的主要工作都是在一个单独的后台线程Master Thread中完成的,这一节将具体解释该线程的具体实现及该线程可能存在的问题。
2.5.1 InnoDB 1.0.x版本之前的Master Thread
Master Thread具有最高的线程优先级别。其内部由多个循环(loop)组成:主循环(loop)、后台循环(backgroup loop)、刷新循环(flush loop)、暂停循环(suspend loop)。Master Thread会根据数据库运行的状态在loop、background loop、flush loop和suspend loop中进行切换。
Loop被称为主循环,因为大多数的操作是在这个循环中,其中有两大部分的操作——每秒钟的操作和每10秒的操作。伪代码如下:

void master_thread(){
loop:
for(int i= 0; i<10; i++){
   do thing once per second
   sleep 1 second if necessary
}
do things once per ten seconds
goto loop;
}

可以看到,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个脏页写入磁盘中。
总结上述操作,伪代码可以进一步具体化,如下所示:

void master_thread(){
   goto loop;
loop:
for(int i = 0; i<10; i++){
   thread_sleep(1) // sleep 1 second
   do log buffer flush to disk
   if (last_one_second_ios < 5 )
      do merge at most 5 insert buffer
   if ( buf_get_modified_ratio_pct > innodb_max_dirty_pages_pct )
      do buffer pool flush 100 dirty page
   if ( no user activity )
      goto backgroud loop
}
do things once per ten seconds
background loop:
   do something
   goto loop:
}

接着来看每10秒的操作,包括如下内容:
?刷新100个脏页到磁盘(可能的情况下);
?合并至多5个插入缓冲(总是);
?将日志缓冲刷新到磁盘(总是);
?删除无用的Undo页(总是);
?刷新100个或者10个脏页到磁盘(总是)。
在以上的过程中,InnoDB存储引擎会先判断过去10秒之内磁盘的IO操作是否小于200次,如果是,InnoDB存储引擎认为当前有足够的磁盘IO操作能力,因此将100个脏页刷新到磁盘。接着,InnoDB存储引擎会合并插入缓冲。不同于每秒一次操作时可能发生的合并插入缓冲操作,这次的合并插入缓冲操作总会在这个阶段进行。之后,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%的脏页到磁盘。
现在我们可以完整地把主循环(main loop)的伪代码写出来了,内容如下:

void master_thread(){
   goto loop;
loop:
for(int i = 0; i<10; i++){
   thread_sleep(1) // sleep 1 second
   do log buffer flush to disk
   if (last_one_second_ios < 5 )
      do merge at most 5 insert buffer
   if ( buf_get_modified_ratio_pct > innodb_max_dirty_pages_pct )
      do buffer pool flush 100 dirty page
   if ( no user activity )
      goto backgroud loop
}
if ( last_ten_second_ios < 200 )
   do buffer pool flush 100 dirty page
do merge at most 5 insert buffer
do log buffer flush to disk
do full purge
if ( buf_get_modified_ratio_pct > 70% )
   do buffer pool flush 100 dirty page
else
   buffer pool flush 10 dirty page
goto loop
background loop:
   do something
goto loop:
}

接着来看background loop,若当前没有用户活动(数据库空闲时)或者数据库关闭(shutdown),就会切换到这个循环。background loop会执行以下操作:
?删除无用的Undo页(总是);
?合并20个插入缓冲(总是);
?跳回到主循环(总是);
?不断刷新100个页直到符合条件(可能,跳转到flush loop中完成)。
若flush loop中也没有什么事情可以做了,InnoDB存储引擎会切换到suspend__loop,将Master Thread挂起,等待事件的发生。若用户启用(enable)了InnoDB存储引擎,却没有使用任何InnoDB存储引擎的表,那么Master Thread总是处于挂起的状态。
最后,Master Thread完整的伪代码如下:

void master_thread(){
   goto loop;
loop:
for(int i = 0; i<10; i++){
   thread_sleep(1) // sleep 1 second
   do log buffer flush to disk
   if ( last_one_second_ios < 5 )
      do merge at most 5 insert buffer
   if ( buf_get_modified_ratio_pct > innodb_max_dirty_pages_pct )
      do buffer pool flush 100 dirty page
   if ( no user activity )
      goto backgroud loop
}
if ( last_ten_second_ios < 200 )
   do buffer pool flush 100 dirty page
do merge at most 5 insert buffer
do log buffer flush to disk
do full purge
if ( buf_get_modified_ratio_pct > 70% )
   do buffer pool flush 100 dirty page
else
   buffer pool flush 10 dirty page
goto loop
background loop:
do full purge
do merge 20 insert buffer
if not idle:
goto loop:
else:
   goto flush loop
flush loop:
do buffer pool flush 100 dirty page
if ( buf_get_modified_ratio_pct>innodb_max_dirty_pages_pct )
   goto flush loop
goto suspend loop
suspend loop:
suspend_thread()
waiting event
goto loop;
}

2.5.2 InnoDB1.2.x版本之前的Master Thread
在了解了1.0.x版本之前的Master Thread的具体实现过程后,细心的读者会发现InnoDB存储引擎对于IO其实是有限制的,在缓冲池向磁盘刷新时其实都做了一定的硬编码(hard coding)。在磁盘技术飞速发展的今天,当固态磁盘(SSD)出现时,这种规定在很大程度上限制了InnoDB存储引擎对磁盘IO的性能,尤其是写入性能。
从前面的伪代码来看,无论何时,InnoDB存储引擎最大只会刷新100个脏页到磁盘,合并20个插入缓冲。如果是在写入密集的应用程序中,每秒可能会产生大于100个的脏页,如果是产生大于20个插入缓冲的情况,Master Thread似乎会“忙不过来”,或者说它总是做得很慢。即使磁盘能在1秒内处理多于100个页的写入和20个插入缓冲的合并,但是由于hard coding,Master Thread也只会选择刷新100个脏页和合并20个插入缓冲。同时,当发生宕机需要恢复时,由于很多数据还没有刷新回磁盘,会导致恢复的时间可能需要很久,尤其是对于insert buffer来说。
这个问题最初由Google的工程师Mark Callaghan提出,之后InnoDB官方对其进行了修正并发布了补丁(patch)。InnoDB存储引擎的开发团队参考了Google的patch,提供了类似的方法来修正该问题。因此InnoDB Plugin(从InnoDB1.0.x版本开始)提供了参数innodb_io_capacity,用来表示磁盘IO的吞吐量,默认值为200。对于刷新到磁盘页的数量,会按照innodb_io_capacity的百分比来进行控制。规则如下:
?在合并插入缓冲时,合并插入缓冲的数量为innodb_io_capacity值的5%;
?在从缓冲区刷新脏页时,刷新脏页的数量为innodb_io_capacity。
若用户使用了SSD类的磁盘,或者将几块磁盘做了RAID,当存储设备拥有更高的IO速度时,完全可以将innodb_io_capacity的值调得再高点,直到符合磁盘IO的吞吐量为止。
另一个问题是,参数innodb_max_dirty_pages_pct默认值的问题,在InnoDB 1.0.x版本之前,该值的默认为90,意味着脏页占缓冲池的90%。但是该值“太大”了,因为InnoDB存储引擎在每秒刷新缓冲池和flush loop时会判断这个值,如果该值大于innodb_max_dirty_pages_pct,才刷新100个脏页,如果有很大的内存,或者数据库服务器的压力很大,这时刷新脏页的速度反而会降低。同样,在数据库的恢复阶段可能需要更多的时间。
在很多论坛上都有对这个问题的讨论,有人甚至将这个值调到了20或10,然后测试发现性能会有所提高,但是将innodb_max_dirty_pages_pct调到20或10会增加磁盘的压力,系统的负担还是会有所增加的。Google在这个问题上进行了测试,证明20并不是一个最优值。而从InnoDB 1.0.x版本开始,innodb_max_dirty_pages_pct默认值变为了75,和Google测试的80比较接近。这样既可以加快刷新脏页的频率,又能保证了磁盘IO的负载。
InnoDB 1.0.x版本带来的另一个参数是innodb_adaptive_flushing(自适应地刷新),该值影响每秒刷新脏页的数量。原来的刷新规则是:脏页在缓冲池所占的比例小于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通过判断产生重做日志(redo log)的速度来决定最合适的刷新脏页数量。因此,当脏页的比例小于innodb_max_dirty_pages_pct时,也会刷新一定量的脏页。
还有一个改变是:之前每次进行full purge操作时,最多回收20个Undo页,从InnoDB 1.0.x版本开始引入了参数innodb_purge_batch_size,该参数可以控制每次full purge回收的Undo页的数量。该参数的默认值为20,并可以动态地对其进行修改,具体如下:

mysql> SHOW VARIABLES LIKE 'innodb_purge_batch_size'\G;
*************************** 1. row ***************************
Variable_name: innodb_purge_batch_size
       Value: 20

mysql> SET GLOBAL innodb_purge_batch_size=50;
Query OK, 0 rows affected (0.00 sec)

通过上述的讨论和解释我们知道,从InnoDB 1.0.x版本开始,Master Thread的伪代码必将有所改变,最终变成:

void master_thread(){
   goto loop;
loop:
for(int i = 0; i<10; i++){
   thread_sleep(1) // sleep 1 second
   do log buffer flush to disk
   if ( last_one_second_ios < 5% innodb_io_capacity )
      do merge 5% innodb_io_capacity insert buffer
   if ( buf_get_modified_ratio_pct > innodb_max_dirty_pages_pct )
      do buffer pool flush 100% innodb_io_capacity dirty page
   else if enable adaptive flush
      do buffer pool flush desired amount dirty page
   if ( no user activity )
      goto backgroud loop
}
if ( last_ten_second_ios <innodb_io_capacity)
   do buffer pool flush 100% innodb_io_capacity dirty page
do merge 5% innodb_io_capacity insert buffer
do log buffer flush to disk
do full purge
if ( buf_get_modified_ratio_pct > 70% )
   do buffer pool flush 100% innodb_io_capacity dirty page
else
   dobuffer pool flush 10% innodb_io_capacity dirty page
goto loop
background loop:
do full purge
do merge 100% innodb_io_capacity insert buffer
if not idle:
goto loop:
else:
   goto flush loop
flush loop:
do buffer pool flush 100% innodb_io_capacity dirty page
if ( buf_get_modified_ratio_pct>innodb_max_dirty_pages_pct )
   go to flush loop
   goto suspend loop
suspend loop:
suspend_thread()
waiting event
goto loop;
}

很多测试都显示,InnoDB 1.0.x版本在性能方面取得了极大的提高,其实这和前面提到的Master Thread的改动是密不可分的,因为InnoDB存储引擎的核心操作大部分都集中在Master Thread后台线程中。
从InnoDB 1.0.x开始,命令SHOW ENGINE INNODB STATUS可以查看当前Master Thread的状态信息,如下所示:

mysql>SHOW ENGINE INNODB STATUS\G;
*************************** 1. row ***************************
  Type: InnoDB
  Name: 
Status: 
=====================================
090921 14:24:56 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 6 seconds
----------
BACKGROUND THREAD
----------
srv_master_thread loops: 45 1_second, 45 sleeps, 4 10_second, 6 background, 6 flush
srv_master_thread log flush and writes: 45  log writes only: 69
……

这里可以看到主循环进行了45次,每秒挂起(sleep)的操作进行了45次(说明负载不是很大),10秒一次的活动进行了4次,符合1∶10。background loop进行了6次,flush loop也进行了6次。因为当前这台服务器的压力很小,所以能在理论值上运行。如果是在一台压力很大的MySQL数据库服务器上,看到的可能会是下面的情景:

mysql> show engine innodb status\G;
*************************** 1. row ***************************
  Type: InnoDB
  Name: 
Status: 
=====================================
091009 10:14:34 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 42 seconds
----------
BACKGROUND THREAD
----------
srv_master_thread loops: 2188 1_second, 1537 sleeps, 218 10_second, 2 background, 2 flush
srv_master_thread log flush and writes: 1777  log writes only: 5816
……

可以看到当前主循环运行了2188次,但是循环中的每秒挂起(sleep)的操作只运行了1537次。这是因为InnoDB对其内部进行了一些优化,当压力大时并不总是等待1秒。因此,并不能认为1_second和sleeps的值总是相等的。在某些情况下,可以通过两者之间差值的比较来反映当前数据库的负载压力。
2.5.3 InnoDB 1.2.x版本的Master Thread
在InnoDB 1.2.x版本中再次对Master Thread进行了优化,由此也可以看出Master Thread对性能所起到的关键作用。在InnoDB 1.2.x版本中,Master Thread的伪代码如下:

if InnoDB is idle
  srv_master_do_idle_tasks();
else
  srv_master_do_active_tasks();

其中srv_master_do_idle_tasks()就是之前版本中每10秒的操作,srv_master_do_active_tasks()处理的是之前每秒中的操作。同时对于刷新脏页的操作,从Master Thread线程分离到一个单独的Page Cleaner Thread,从而减轻了Master Thread的工作,同时进一步提高了系统的并发性。

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

相关文章
InnoDB的行溢出数据,Char的行结构存储
行溢出数据 InnoDB存储引擎可以将一条记录中的某些数据存储在真正的数据页面之外,即作为行溢出数据。一般认为BLOB、LOB这类的大对象列类型的存储会把数据存放在数据页面之外。但是,这个理解有点偏差,BLOB可以不将数据放在溢出页面,而即使是varchar列数据类型,依然有可能存放为行溢出数据。
782 0
Castle.ActiveRecord 使用 存储过程 返回实体类
Castle,ActiveRecord,使用,存储过程,实体类 这几日就在研究这个问题 寻遍网上,也没找到个解决方法只有在NHibernate里执行存储过程 里面操作NHibernate的一点方法 于是动手写成了以下这个类 当然,只能保证测试可以通过,可能还有很多问题,要一个一个解决  1namespace ChAlumna.
725 0
InnoDB的后台线程(IO线程,master线程,锁监控线程,错误监控线程)和内存(缓冲池,重做日志缓冲池,额外内存池)
InnoDB有多个内存块,你可以认为这些内存块组成了一个大的内存池,负责如下工作: 维护所有进程/线程需要访问的多个内部数据结构。 缓存磁盘上的数据,方便快速地读取,并且在对磁盘文件的数据进行修改之前在这里缓存。
815 0
10059
文章
0
问答
来源圈子
更多
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载