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------------------------------------------------------