MySQL錯誤日志分析
最近這段時間，線上的一個生產庫，經常看到內存用的很滿，而且磁盤IO出現告警，於是打開錯誤日志，分析了一下，其中一條note引起了注意，如下，
2019-05-04T00:58:57.708768+08:00 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4111ms. The settings might not
be optimal. (flushed=1164 and evicted=0, during the time.)
2019-05-04T00:59:43.866249+08:00 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4335ms. The settings might not
be optimal. (flushed=1041 and evicted=0, during the time.)
2019-05-04T01:05:19.581244+08:00 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 5172ms. The settings might not
be optimal. (flushed=731 and evicted=0, during the time.)
2019-05-04T02:29:15.037309+08:00 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4073ms. The settings might not
be optimal. (flushed=148 and evicted=0, during the time.)
我們從這個日志中可以了解到，我們刷臟頁的page_cleaner一直在輸出日志，想到翻看源碼，從源碼包storage的innobase目錄下的buf中找到buf0flu.cc這個代碼文件，經過網上查詢以及分析，定位到了上面輸出的源代碼位置，如下：
通過這段源碼，我們可以知道，觸發它輸出日志的條件主要是，curr_time > next_loop_time + 3000即當前實際刷臟頁的時間比原定的時間超出很多，而next_loop_time的標准時間是1000毫秒，即1秒鍾做一次刷新頁的操作，這里就牽出了我們master thread主線程中loop主循環的每1秒的操作和每10秒的操作，如下
日志后面輸出的(flushed=148 and evicted=0, during the time.)，對應n_flushed_last與n_evicted 變量，而這兩個變量又由n_flushed_list與n_flushed_lru賦值。
而這兩個變量的賦值函數為pc_wait_finished，我們再來看下對於這個函數的注釋，
這里我只拉了一部分代碼注釋，其中主要是一些條件判斷刷新頁的操作。
n_flushed_lru 這個值表示從lru 列表尾部刷新的頁數，也就是日志中如evicted=0 指標的所表示的值。
最后與開發人員溝通了一下，得知這套庫平常以寫入居多，刷新頁的操作很頻繁，導致IO吃緊，又
找了一些網上大神的博客總結，根據官方文檔中針對page_cleaner線程的描述我們將innodb_lru_scan_depth參數做了調整，默認是1024，調整成了 innodb_io_capacity / innodb_buffer_pool_instances=300，后續需要繼續跟蹤觀察錯誤日志。
https://blog.csdn.net/isoleo/article/details/54342180
https://yq.aliyun.com/articles/41005