msyql master thread

------------------------------------------------------ 2015-02-10------------------------------------------------------

本文只是简单介绍 msyql master thread 工作方式, 了解即可.

　　innodb 1.0.x 版本之前的 master thread

　　innodb 存储引擎的主要工作都在一个单独的后台线程中完成的.

　　master thread 具有最高的线程优先级. 其内部又多个循环组成. : 主循环(loop),后台循环(background loop), 刷新循环(flush loop), 暂停循环(suspend loop). master thread 会跟据mysql运行状态在这几个循环中进行切换.

　　loop :

　　  被称为主循环,因为大多数操作是在这个循环中进行的. 主循环使用 thread sleep来实现每秒/每10秒的间隔, 所以,这并不一定精确. 在负载很大的情况下,可能会有延迟.

　　　　每秒一次的操作包括 :

　　　　1.日志缓冲刷新到磁盘, 即使事务没有提交(commit).

　　　　　　　　注意! 即使事务没有提交操作, innodb 重做日志缓存仍然会刷新到重做日志文件, 所以就算很大的事务操作的commit没有想象中那么慢.

　　　　2.合并插入缓冲(可能);

　　　　　　　　合并插入缓冲不一定每秒都执行, innodb引擎会判断当前1秒内发生的IO次数是否小于5次, 如果小于5次.则合并插入缓冲.

　　　　3. 最多刷新100个 innodb缓冲池中的脏页到磁盘(可能)

　　　　　　　　innodb存储引擎通过判断当前缓冲池中脏页的比例()是否超过配置文件中innodb_max_dirty_pages_pct这个参数的值(默认为90, 表示90%).如果超过了这个阀值 ,innodb存储引擎则认为需要做磁盘同步操作,刷新100个脏页到磁盘.

4. 如果当前用户没有活动, 切换到 background thread (可能)

　　　　

　　　　每10秒执行的操作 :

　　　　　1 .刷新100个脏页到磁盘 (总是)

　　　　  2. 合并最多5个插入缓冲(总是)

　　　　 3. 将日志缓冲刷新到磁盘(总是)

　　　　　4. 删除无用的Undo页(总是)

　　　　   5. 刷新100个或者10个脏页到磁盘(总是)

　　         在10秒的循环操作中. innodb存储引擎首先判断过去10秒内的磁盘IO操作是否小于200次, 如果小于,则将100个脏页刷新到磁盘.  然后合并 (最多5个)插入缓冲, 然后将重做日志缓冲刷新到日志文件.然后,innodb存储引擎会执行一次full purge. 既删除无用的undo页. 对表(磁盘)进行update, 和delete这类操作时,原先被标记为删除,但是因为一致性读(consistent read)的关系, 需要保留这些行版本的信息. 但是在full purge 过程中, innodb存储引擎会判断当前事务中已被删除的行是否可以在表(磁盘)中删除,如果可以,则立刻删除.  innodb在执行full purge操作时,每次最多尝试回收20个undo page. 最后innodb存储引擎会判断缓冲池中脏页的比例,  如果超过70%, 则刷新100个脏页到磁盘, 如果脏页比例小于70%,则是刷新10%的脏页到磁盘.

　　

　　　background loop :

　　　　　　若当前没有用户活动或者数据库关闭(shutdown)时,就会切换到这个循环. background loop 会执行以下操作.

　　　　　　1 .删除无用的 undo 页(总是)

　　　　　　2. 合并20个插入缓冲页(总是)

　　　　　　3. 跳回到主循环(总是)

　　　　　　4. 不断刷新到100个脏页知道符合条件(可能, 跳转到flush loop 中完成)

　　　　若flush loop 中也没有什么事情可以做了, innodb存储引擎会切换到suspend_loop. 将master_thread挂起, 等待事件发生.

　　　　若用在mysql中启用了innodb存储引擎,但没有创建innodb表, 则master thread总是处于挂起状态
 ------------------------------------------------------ 2015-02-10------------------------------------------------------

------------------------------------------------------ 2015-02-11------------------------------------------------------

innodb 1.2.x 版本之前的 master thread

　　　　1.0.x版本之后(1.0.x也进行了修复) , innnodb加入了 innodb_io_capacity 参数用来控制磁盘吞吐量

　　　　 innodb_io_capacity (新增)

　　　　　　--按照该值的百分比来控制刷新到磁盘页的数量

　　　　　　　　1. 在合并插入缓冲时, 合并插入缓冲的数量是该值的5%

　　　　　　　　2. 在从缓冲中刷新脏页时, 刷新的脏页数量等于该值.

　　　　若用户使用了ssd类的磁盘或做了磁盘阵列, 可将该值适当调大.

　　　 innodb_max_dirty_pages_pct (修改)

　　　　　 --1.0.x版本之前,该值默认值为90, 表示缓冲池中脏页占缓冲池的90%. innodb 在每秒刷新缓冲池和flush loop的时候会判断该值,如果脏页所占比例大于该值才刷新100个脏页到磁盘. 仔细想想90%是不是太大了. 所以在1.0.x版本中. innodb 将该值的默认值改为75.

　　　innodb_adaptive_fulshing (新增)

　　　　　　该值影响每秒刷新脏页的数量. 之前的规则是如果脏页在缓冲池中占比超过 innodb_max_dirty_pages_pct 则执行刷新, 如果没有则不执行刷新. 随着innodb_adaptive_flushing参数的引入.innodb会通过一个名为buf_flush_get_desired_flush_rate函数来判断刷新脏页最合适的数量. 该参数通过判断产生重做日志的速度来决定最合适的刷新脏页数量. 因此当缓冲池中脏页数量小于innodb_max_dirty_pages_pct时,也有可能执行刷新.

　　   innodb_purge_batch_size (新增)

　　　　　  该参数控制每次 full purge 回收的 undo 页数量,该参数默认为20. 可动态修改.

很多测试都显示 innodb 1.0.x版本在性能方面得到了极大的提升, 这和 master thread 的改动是密不可分的, 因为innodb 的核心操作大部分集中在 master thread 后台线程中.

　　执行 show engine innodb status 命令, 如下所示

　　　　　　

mysql> show engine innodb status\G;
*************************** 1. row ***************************
Type: InnoDB
Name:
Status:
=====================================
150211 16:47:53 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 11 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 56 1_second, 56 sleeps, 5 10_second, 6 background, 6 flush
srv_master_thread log flush and writes: 56
......

　　　　　　其中 srv_master_thread loops: 56 表示主循环进行了,56次. 56 sleeps 表示挂起56次, 5 10_second 表示10秒的循环执行了5次. background loop执行6次, flush loop执行6 次.

　　　　　　如果 srv_master_thread loops  与 sleeps 存在较大差距,则表明当前服务器可能很比较繁忙 , 因为innodb在其内部进行了优化, 在压力大的情况下,1秒循环并不是每次都sleep .

innodb 1.2.x 版本的 master thread

　　　　　　1.2.x版本中, 将刷新脏页的操作从master thread 分离到一个单独的 page cleaner thread 进程中. 进一步提高了系统的并发性

------------------------------------------------------ 2015-02-11------------------------------------------------------