MySQL:Innodb page clean 執行緒 (二) 解析
本文為學習筆記，有誤請指出。本文第一分部為基礎部分第二部分為解析部分涉及部分原始碼淺析。
本文使用原始碼版本：Percona 5.7.14
本文約定
-協調工作執行緒：因為page clean執行緒的協調執行緒也會完成部分重新整理工作，所以叫做協調工作執行緒。
一、資料結構和入口函式
1、資料結構
-
page_cleaner_t：整個Innodb只有一個，包含整個page clean執行緒相關資訊。其中包含了一個page_cleaner_slot_t的指標。
| 變數名 | 含義 |
|---|---|
| mutex | 用於保護整個page_cleaner_t結構體和page_cleaner_slot_t結構體，當需要修改結構體資訊的時候需要獲取這個mutex，如在pc_request函式中 |
| is_requested | 一個條件變數，用於喚醒堵塞在這個條件之上的工作執行緒 |
| is_finished | 一個條件變數，用於通知協調執行緒重新整理工作已經完成 |
| n_workers | 當前存在的工作執行緒總數 |
| requested | 布林值，當前是否需要進行髒資料重新整理工作 |
| lsn_limit | 需要重新整理到lsn的位置，當需要同步重新整理的時候，這個值將被賦予，以保證小於這個lsn的日誌都已經完成了刷盤工作 |
| n_slots | 槽的數量，槽的數量和buffer instance的數量相同 |
| n_slots_requested | 當前處於需要重新整理狀態下(PAGE_CLEANER_STATE_REQUESTED)的槽的數量 |
| n_slots_flushing | 當前處於重新整理狀態下(PAGE_CLEANER_STATE_FLUSHING)的槽的數量 |
| n_slots_finished | 當前處於已經重新整理完成狀態下(PAGE_CLEANER_STATE_FINISHED)的槽的數量 |
| flush_time | 整個(以innodb buffer為單位)重新整理消耗的時間（累計 page_cleaner->flush_time += ut_time_ms() - tm;） |
| flush_pass | 整個(以innodb buffer為單位)重新整理的次數（累計 page_cleaner->flush_pass++;） |
| slots | 指標指向實際的槽 |
| is_running | 布林值，如果關閉innodb會被設定為false，進行強行重新整理髒資料 |
-
page_cleaner_slot_t：每個buffer instance都包含一個這樣的結構體，page clean工作執行緒重新整理的時候每個執行緒都會輪詢的檢測每個槽，知道找到沒有被其他page clean執行緒重新整理的槽進行重新整理工作，直到每個槽（buffer instance ）都重新整理完成。參考pc_flush_slot函式。
| 變數名 | 含義 |
|---|---|
| state | 狀態PAGE_CLEANER_STATE_REQUESTED、PAGE_CLEANER_STATE_FLUSHING和PAGE_CLEANER_STATE_FINISHED中的一種 |
| n_pages_requested | 本槽需要重新整理的總的塊數量 |
| n_flushed_list | 已經重新整理的塊數 |
| succeeded_list | 布林值，重新整理是否完成 |
| flush_list_time | 本槽重新整理消耗的時間（累計參考pc_flush_slot函式） |
| flush_list_pass | 本槽進行重新整理操作的次數（累計參考pc_flush_slot函式） |
2、入口函式
-
協調工作執行緒入口：buf_flush_page_cleaner_coordinator
-
工作執行緒入口：buf_flush_page_cleaner_worker
二、主迴圈解析
其由函式buf_flush_page_cleaner_coordinator實現。實際正常執行情況下的工作都包含在while (srv_shutdown_state == SRV_SHUTDOWN_NONE) 這個大迴圈下。
1、是否需要睡眠1秒判斷
首先如果沒有活躍的change buffer 並且沒有pending的物理塊，並且上次重新整理的塊數量為0
則不需要睡眠1秒：
if (srv_check_activity(last_activity)
|| buf_get_n_pending_read_ios() || n_flushed == 0){
ret_sleep = pc_sleep_if_needed(
next_loop_time, sig_count); //睡眠一秒 if (srv_shutdown_state != SRV_SHUTDOWN_NONE) { break;
}
} else if (ut_time_ms() > next_loop_time) { //如果當前時間大於 上次重新整理 時間+1 秒則 設定為OS_SYNC_TIME_EXCEEDED
ret_sleep = OS_SYNC_TIME_EXCEEDED;
} else {
ret_sleep = 0;
}
但是這個睡眠是可以被喚醒的，比如同步重新整理應該就會喚醒它（buf_flush_request_force函式）。參考函式os_event::wait_time_low
2、IO能力不足警告
如前文所描述這裡產生如下警告：
page_cleaner: 1000ms intended loop took **ms. The settings might not be optimal.((flushed="**" , during the time.)
原始碼片段：
if (curr_time > next_loop_time + 3000) { //如果重新整理時間 大於了 上次時間 +1 秒+3 秒 則報info
if (warn_count == 0) {
ib::info() << "page_cleaner: 1000ms"
" intended loop took "
<< 1000 + curr_time
- next_loop_time
<< "ms. The settings might not"
" be optimal. (flushed="
<< n_flushed_last
<< ", during the time.)"; if (warn_interval > 300) {
warn_interval = 600;
} else {
warn_interval *= 2;
}
3、同步重新整理判斷
-
觸發條件
(ret_sleep != OS_SYNC_TIME_EXCEEDED && srv_flush_sync && buf_flush_sync_lsn > 0)
同步會喚醒正在睡眠狀態的page clean協調工作執行緒那麼睡眠應該不會滿足一秒的條件所以不會被標記為OS_SYNC_TIME_EXCEEDED，同時srv_flush_sync和buf_flush_sync_lsn均會被設定接下來就是喚醒工作執行緒進行重新整理，同時本協調執行緒也完成部分任務。
-
工作程式碼
pc_request(ULINT_MAX, lsn_limit); //喚醒page clean 工作執行緒幹活
/* Coordinator also treats requests */ //協調者同樣要完成部分任務
while (pc_flush_slot() > 0) {}
-
喚醒操作
如前文描述在checkpoint或者DML語句執行過程中都會透過log_free_check檢查是否redo log處於安全的狀態，如果不安全就會呼叫如下程式碼（log_preflush_pool_modified_pages函式中）喚醒page clean執行緒進行同步重新整理：
if (srv_flush_sync) { /* wake page cleaner for IO burst */
buf_flush_request_force(new_oldest); //設定全域性變數同時透過broadcast喚醒同步重新整理
}
buf_flush_wait_flushed(new_oldest); //所有執行緒等待同步重新整理完成
4、活躍重新整理
-
觸發條件
srv_check_activity(last_activity)
這裡判斷是否有活躍的執行緒，所謂活躍就是呼叫srv_inc_activity_count函式進行增加的，一般來講DML和DDL會標記為活躍，purge執行緒及其工作執行緒工作期間會標記為活躍。可以將斷點做到srv_inc_activity_count進行debug。所以線上資料庫DML比較多所以一般都會是活躍重新整理。
-
工作程式碼
這裡涉及到重新整理多少個塊計算主要函式為 page_cleaner_flush_pages_recommendation，後面在討論。
n_to_flush = page_cleaner_flush_pages_recommendation(&lsn_limit, last_pages);//此處n_to_flush就是本次需要重新整理的塊數的數量pc_request(n_to_flush, lsn_limit); //喚醒page clean 工作執行緒幹活/* Coordinator also treats requests */ //工作協調執行緒同樣要完成部分任務
while (pc_flush_slot() > 0) {}
pc_wait_finished(&n_flushed_list);//等待其他重新整理完成
5、空閒重新整理
-
觸發條件
else if (ret_sleep == OS_SYNC_TIME_EXCEEDED)
當睡足了1秒，並且沒有活躍的執行緒。那麼就進行空閒重新整理，一般來講如果沒有DML/DDL等語句那麼應該進行是空閒重新整理。
-
工作程式碼
buf_flush_lists(PCT_IO(100), LSN_MAX, &n_flushed); //io能力 重新整理到那個lsn 以及傳出重新整理的塊數量//PCT_IO是一個宏如下：#define PCT_IO(p) ((ulong) (srv_io_capacity * ((double) (p) / 100.0)))
可以看到這裡的百分比直接是100%及按照innodb_io_capacity引數的設定進行重新整理。
當然這裡只是看了正常期間工作的程式碼，如果是Innodb shutdown也會觸發同步重新整理。可自行參考程式碼。
三、page_cleaner_flush_pages_recommendation函式
前面提過這個函式，是活躍重新整理重新整理塊的計算函式，下面直接給出整個程式碼
{
cur_lsn = log_get_lsn();//獲取當前的lsn 在 redo buffer中的
if (prev_lsn == 0) { //靜態變數如果是0則代表是第一次執行本函式
/* First time around. */
prev_lsn = cur_lsn;
prev_time = ut_time(); //獲取當前時間
return(0);
} if (prev_lsn == cur_lsn) { //如果沒有redo日誌生成
return(0);
}
sum_pages += last_pages_in; time_t curr_time = ut_time(); double time_elapsed = difftime(curr_time, prev_time);
avg_page_rate = static_cast<ulint>(
((static_cast<double>(sum_pages)
/ time_elapsed)
+ avg_page_rate) / 2); //算出上次重新整理每秒重新整理的pages數量，同時加上次計算的每秒平均重新整理塊數 然後除以2 得到一個每秒重新整理的pages數量 ！！！第一個計算條件avg_page_rate 生成
/* How much LSN we have generated since last call. */
lsn_rate = static_cast<lsn_t>( static_cast<double>(cur_lsn - prev_lsn)
/ time_elapsed);//計算redo lsn生成率
lsn_avg_rate = (lsn_avg_rate + lsn_rate) / 2;//計算redo每秒平均生成率
/* aggregate stats of all slots */
mutex_enter(&page_cleaner->mutex);
ulint flush_tm = page_cleaner->flush_time;
ulint flush_pass = page_cleaner->flush_pass;
page_cleaner->flush_time = 0;
page_cleaner->flush_pass = 0;
ulint list_tm = 0;
ulint list_pass = 0; for (ulint i = 0; i < page_cleaner->n_slots; i++) {//掃描所有的槽
page_cleaner_slot_t* slot;
slot = &page_cleaner->slots[i];
list_tm += slot->flush_list_time;
list_pass += slot->flush_list_pass;
slot->flush_list_time = 0;
slot->flush_list_pass = 0;
}
mutex_exit(&page_cleaner->mutex);
oldest_lsn = buf_pool_get_oldest_modification(); //獲取flush list中最老的ls
ut_ad(oldest_lsn <= log_get_lsn());//斷言
age = cur_lsn > oldest_lsn ? cur_lsn - oldest_lsn : 0; //獲取當前LSN和最老LSN的之間的差值
pct_for_dirty = af_get_pct_for_dirty(); //計算出一個重新整理百分比 (比如100) !!!!重點
pct_for_lsn = af_get_pct_for_lsn(age);//計算出lsn的比率 百分比(l列如4.5)
pct_total = ut_max(pct_for_dirty, pct_for_lsn);//取他們的大值
/* Estimate pages to be flushed for the lsn progress *///計算target_lsn
ulint sum_pages_for_lsn = 0; lsn_t target_lsn = oldest_lsn
+ lsn_avg_rate * buf_flush_lsn_scan_factor; //計算下一次重新整理的 目標lsn 及target_lsnbuf_flush_lsn_scan_factor是定值3
for (ulint i = 0; i < srv_buf_pool_instances; i++) {//迴圈整個buffer instance找到小於target_lsn的髒塊
buf_pool_t* buf_pool = buf_pool_from_array(i);
ulint pages_for_lsn = 0;
buf_flush_list_mutex_enter(buf_pool); for (buf_page_t* b = UT_LIST_GET_LAST(buf_pool->flush_list);//每個innodb buffer的末尾的flush list 進行掃描，頭插法?
b != NULL;
b = UT_LIST_GET_PREV(list, b)) { if (b->oldest_modification > target_lsn) { break;
}
++pages_for_lsn; //某個 innodb buffer 例項中 flush list 小於這個 target lsn 的 page計數
}
buf_flush_list_mutex_exit(buf_pool);
sum_pages_for_lsn += pages_for_lsn; //這裡彙總所有 innodb buffer例項中 flush list 小於這個 target lsn 的 page 總數
mutex_enter(&page_cleaner->mutex);
ut_ad(page_cleaner->slots[i].state
== PAGE_CLEANER_STATE_NONE);//斷言所有的槽處於沒有重新整理狀態
page_cleaner->slots[i].n_pages_requested
= pages_for_lsn / buf_flush_lsn_scan_factor + 1; //確認槽的n_pages_requested值
mutex_exit(&page_cleaner->mutex);
}
sum_pages_for_lsn /= buf_flush_lsn_scan_factor;//buf_flush_lsn_scan_factor為定值3
/* Cap the maximum IO capacity that we are going to use by
max_io_capacity. Limit the value to avoid too quick increase */
n_pages = PCT_IO(pct_total); //根據 前面得到的 pct_total 和 srv_io_capacity引數得到 重新整理的塊數 !!!第二個計算引數生成。
if (age < log_get_max_modified_age_async()) { //如果日質量小於 非同步重新整理的範疇
ulint pages_for_lsn = std::min<ulint>(sum_pages_for_lsn,
srv_max_io_capacity * 2); //即便是需要重新整理的塊數很多，最多隻能刷max_io_capacity*2的數量!!!第三個計算引數生成
n_pages = (n_pages + avg_page_rate + pages_for_lsn) / 3; // 3部分組成 1、根據引數計算出來的IO能力 2、以往每秒重新整理頁的數量 3、根據target lsn 計算出來的一個需要重新整理的塊數
} if (n_pages > srv_max_io_capacity) {
n_pages = srv_max_io_capacity;
} return(n_pages);
}
此函式最後計算出了需要重新整理的塊，其中重新整理比率計算的的重點函式為af_get_pct_for_dirty和af_get_pct_for_lsn 下面將給出程式碼註釋，其實前文中的演算法就來自af_get_pct_for_dirty。
四、af_get_pct_for_dirty和af_get_pct_for_lsn函式
-
af_get_pct_for_dirty函式
double dirty_pct = buf_get_modified_ratio_pct(); //得到 修改的塊/總的塊的 的百分比 記住髒資料比率
if (dirty_pct == 0.0) { /* No pages modified */
return(0);
}
ut_a(srv_max_dirty_pages_pct_lwm
<= srv_max_buf_pool_modified_pct); if (srv_max_dirty_pages_pct_lwm == 0) { //如果innodb_max_dirty_pages_pct_lwm沒有設定
/* The user has not set the option to preflush dirty
pages as we approach the high water mark. */
if (dirty_pct >= srv_max_buf_pool_modified_pct) { //如果髒資料比率大於了innodb_max_dirty_pages_pct則返回比率100%
/* We have crossed the high water mark of dirty
pages In this case we start flushing at 100% of
innodb_io_capacity. */
return(100);
}
} else if (dirty_pct >= srv_max_dirty_pages_pct_lwm) { //如果設定了innodb_max_dirty_pages_pct_lwm 並且髒資料比率大於了
/* We should start flushing pages gradually. */ //innodb_max_dirty_pages_pct_lwm引數設定
return(static_cast<ulint>((dirty_pct * 100)
/ (srv_max_buf_pool_modified_pct + 1))); //則返回 (髒資料比率/(innodb_max_dirty_pages_pct+1))*100 也是一個比率 如(45/76)*100
} return(0);//否則返回0
-
af_get_pct_for_lsn函式：
注意innodb_cleaner_lsn_age_factor引數預設設定為high_checkpoint，可以看到演算法最後是除以700.5，所有前文我說這個函式算出來的比率一般比較小。
lsn_t af_lwm = (srv_adaptive_flushing_lwm
* log_get_capacity()) / 100;// srv_adaptive_flushing_lwm=10 那麼大約就是 logtotalsize*(9/10)*(1/10) 943349 計算一個low water mark
if (age < af_lwm) { //如果當前生成的redo 小於了 low water master 則返回0 也就是說 redo日誌量生成量不高則不需要權衡
/* No adaptive flushing. */ //可以看出這裡和redo設定的大小有關，如果redo檔案設定越大則af_lwm越大，觸發權衡的機率越小
return(0);
}
max_async_age = log_get_max_modified_age_async(); //獲取需要非同步重新整理的的位置 大約為logtotalsize*(9/10)*(7/8)
if (age < max_async_age && !srv_adaptive_flushing) { //如果小於非同步重新整理 且 自適應flush 沒有開啟
/* We have still not reached the max_async point and
the user has disabled adaptive flushing. */
return(0);
} /* If we are here then we know that either:
1) User has enabled adaptive flushing
2) User may have disabled adaptive flushing but we have reached
max_async_age. */
lsn_age_factor = (age * 100) / max_async_age; //比率lsn_age_factor = (本次重新整理的日誌量/(logtotalsize*(9/10)*(7/8)))
ut_ad(srv_max_io_capacity >= srv_io_capacity);
switch ((srv_cleaner_lsn_age_factor_t)srv_cleaner_lsn_age_factor) { case SRV_CLEANER_LSN_AGE_FACTOR_LEGACY: return(static_cast<ulint>(
((srv_max_io_capacity / srv_io_capacity)
* (lsn_age_factor
* sqrt((double)lsn_age_factor)))
/ 7.5)); //430
case SRV_CLEANER_LSN_AGE_FACTOR_HIGH_CHECKPOINT: //innodb_cleaner_lsn_age_factor引數預設設定為high_checkpoint
return(static_cast<ulint>(
((srv_max_io_capacity / srv_io_capacity) // ((max_io_cap /io_cap) * (sqrt(lsn_age_factor)*lsn_age_factor*lsn_age_factor))/700.5
* (lsn_age_factor * lsn_age_factor //(10 * (3.3*10*10))/700 =4.3
* sqrt((double)lsn_age_factor)))
/ 700.5)); //
五、總結
本文只是解釋了對於page clean執行緒的結構和重新整理方式，但是真正的重新整理工作實際上從pc_flush_slot函式呼叫才開始，後面非常複雜。如果有機會在好好學習。
作者微信：
微信.jpg
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7728585/viewspace-2157990/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- MySQL:Innodb page clean 執行緒 (一) 基礎MySql執行緒
- MySQL：Innodb purge執行緒略解MySql執行緒
- MySQL 配置InnoDB的併發執行緒MySql執行緒
- MySQL 配置InnoDB主執行緒I/O速率MySql執行緒
- MySQL 配置後臺InnoDB I/O執行緒數MySql執行緒
- MySQL底層概述—3.InnoDB執行緒模型MySql執行緒模型
- MySQL執行緒池總結(二)MySql執行緒
- InnoDB從內分析之Page（二）
- MySQL5.7 InnoDB Page CompressionMySql
- 二. 執行緒管理之執行緒池執行緒
- 【java多執行緒】（二）執行緒停止Java執行緒
- MySQL原理 - InnoDB引擎 - 行記錄儲存 - Off-page 列MySql
- InnoDB儲存引擎——後臺執行緒儲存引擎執行緒
- 【多執行緒總結(二)－執行緒安全與執行緒同步】執行緒
- Java執行緒池二：執行緒池原理Java執行緒
- 解決mysql innodb page corrupt一例MySql
- 執行緒安全（二）執行緒
- 多執行緒（二）執行緒
- RxJava原始碼解析(二)—執行緒排程器SchedulerRxJava原始碼執行緒
- 大話Android多執行緒(二) synchronized使用解析Android執行緒synchronized
- 執行緒的基本解析執行緒
- innodb master執行緒的工作機制AST執行緒
- Android執行緒篇(二)Java執行緒池Android執行緒Java
- 多執行緒系列（二）：多執行緒基礎執行緒
- MySQL_殺mysql執行緒MySql執行緒
- MySQL 批量殺mysql執行緒MySql執行緒
- 多執行緒與高併發(二)執行緒安全執行緒
- android程式與執行緒詳解二：執行緒Android執行緒
- MySQL:一段innodb buffer instance和cleaner執行緒計算邏輯MySql執行緒
- mysql併發執行緒控制之innodb_thread_concurrency的改進MySql執行緒thread
- 執行緒池執行模型原始碼全解析執行緒模型原始碼
- 【Java多執行緒】輕鬆搞定Java多執行緒（二）Java執行緒
- 友好 RxJava2.x 原始碼解析（二）執行緒切換RxJava原始碼執行緒
- MySQL併發複製系列二：多執行緒複製MySql執行緒
- InnoDB: Error: space id and page n:o stored in the page?Error
- MySQL執行計劃解析MySql
- MySQL innodb引擎的事務執行過程MySql
- Mysql innodb引擎（二）鎖MySql