在上期的[月報](http://mysql.taobao.org/index.php?title=MySQL%E5%86%85%E6%A0%B8%E6%9C%88%E6%8A%A5_2015.02)中，我們已經詳細介紹了Oracle MySQL以及社區分支最新的對InnoDB page flush的優化。在最近release的5.7.6版本中又有了進一步的改進。主要包括以下幾點修改 **修改一、更精確的loop時間** Page cleaner每做srv_flushing_avg_loops次flush后，會去計算刷臟和Redo LSN增長的速度。由于每次Page cleaner的工作量是自適應的，一次flush操作的時間可能超過1秒。 在新版本中，統一采用當前時間和上次更新速率的時間差來確認是否需要重新計算速率。因此參數innodb_flushing_avg_loops的行為實際上等同于每這么多秒后重計算速率。 **修改二、根據buffer pool實例的臟頁分布來決定刷臟** 從5.7版本開始支持配置多個page cleaner線程以實現并行刷臟。在5.7.6之前的版本，Page cleaner協調線程根據當前的負載情況，會計算出預計需要flush的總page數和目標LSN，然后在多個bp instance間做個均分。 但是考慮一種場景：如果bp實例間的負載不平衡，某個實例在目標LSN之前的臟頁很多，而有些實例很少，那么本應該多做刷臟動作的bp就可能產生堆積。 我們之前在[webscalesql google公開討論組](https://groups.google.com/forum/#!topic/webscalesql/bs6mFnrm-0A)?有過類似的討論，感興趣的可以看看。 回到正題上來，在5.7.6版本中，計算目標page數的方法大概如下： * 根據當前臟頁占比和Redo LSN增長狀態，計算利用IO Capacity的百分比（pct_total） * 計算目標LSN: ~~~ target_lsn = oldest_lsn + lsn_avg_rate * buf_flush_lsn_scan_factor ~~~ 其中oldest_lsn表示當前buffer pool中最老page的LSN，lsn_avg_rate表示每秒LSN推進的平均速率，buf_flush_lsn_scan_factor目前是hardcode的，值為3。 * 統計每個buffer pool 小于target_lsn的page數pages_for_lsn 初步估定每個bp instance 的n_pages_requested= pages_for_lsn /buf_flush_lsn_scan_factor。每個bp的pages_for_lsn被累加到sum_pages_for_lsn * 同時根據io capacity估算總的需要flush的Page數量： ~~~ sum_pages_for_lsn /= buf_flush_lsn_scan_factor; n_pages = (PCT_IO(pct_total) + avg_page_rate + sum_pages_for_lsn) / 3; ~~~ n_pages若超過innodb_io_capacity_max，則設置為innodb_io_capacity_max * 輪詢每個Buffer pool 實例： ~~~ 如果當前有足夠的Redo 空間：n_pages_requested = n_pages / srv_buf_pool_instances 否則：n_pages_requested = n_pages_requested * n_pages / sum_pages_for_lsn ~~~ 也就是說，在Redo 空間足夠時，依然采用均衡的刷臟邏輯。 在早期版本中，會根據兩個條件來判斷每個bp刷臟的進度：目標LSN及page數。而到了5.7.6版本里，大多數情況下只根據更加準確的請求刷page數來進行判定 （系統空閑時進行100% io capactiy的page flush、崩潰恢復時、以及實例shutdown時的刷臟除外） 雖然計算公式比較清晰，但有些factor的定值依然讓人很困惑，也許是官方測試的比較理想的配置。不過最好還是設置成可配置的，由有經驗的用戶根據自己具體的負載情況來進行定制。 **修改三、用戶線程在檢查Redo 空間時不參與刷臟** 在之前版本中，當未做checkpoint的日志量過多時，用戶線程會進行batch flush操作，將每個buffer pool instance的LSN推進到某個指定值。如果某個bp instance已經有別的線程在flush，則跳過嘗試下一個instance，同時認為這次的flush操作是失敗的，會返回重試。 當用戶線程參與到刷臟時，通常會認為這是個性能拐點，TPS會出現急劇下降，大量線程陷入condtion wait 和并發flush。因此在5.7.6里，當用戶線程需要推進LSN時，不再主動發起刷臟，這些工作會留給page cleaner線程來作。 用戶線程只去輪詢每個bp instance，直到所有的bp instance 的LSN超過其目標LSN，每次輪詢默認sleep重試時間為10000微妙 事實上, Percona Server早在5.6版本里已經使用相同的策略了。 **修改四、為page cleaner線程設置更高的優先級** 在Linux平臺下，對于page cleaner的協調線程和worker線程，其CPU優先級被設置為-20，即最高優先級，通過函數set_priority設置。目前還不支持參數配置。 **修改五、防止checkpoint LSN被覆蓋** 在之前的版本中，盡管每次在寫Redo時都會去檢查日志文件是否容留了足夠百分比的可用空間，但實際上并沒有考慮即將寫入的Redo log長度。如果我們操作一些極大的記錄并產生很長的Redo log記錄，這可能導致檢查點LSN被覆蓋掉，如果這時候crash就會無法安全的做崩潰恢復。 在新的邏輯里，在檢測到當前寫入的Redo 可能造成覆蓋上次的checkpoint點時，就會進入sleep，等待page cleaner線程刷臟，然后再做一次Redo log checkpoint。如此循環直到checkpoint的LSN推進到安全的位置。 **參考**：?[worklog：wl#7868](http://dev.mysql.com/worklog/task/?id=7868)，及[補丁](https://github.com/zhaiwx1987/mysql-server/commit/6ca9b51d2f749b10b9de3fcf3c0b15a056a4df1c)