前言：

最近Oracle MySQL在其官方Blog上貼出了 5.6中一些變量默認(rèn)值的修改。其中innodb_old_blocks_time 的默認(rèn)值從0替換成了1000（即1s）

關(guān)于該參數(shù)的作用摘錄如下：

how long in milliseconds (ms) a block inserted into the old sublist must stay there after its first access before it can be moved to the new sublist. Increasing this value protects against the buffer pool being filled up by data that is referenced only for a brief period, such as during a full table scan.

其實(shí)作用就是：減小單次的大批量數(shù)據(jù)查詢（類似于mysqldump的行為）對(duì)于BufferPool（下稱BP）的污染。

說到這里就不得不提一下BP的midpoint insert 機(jī)制。

下文就將對(duì)于這個(gè)機(jī)制做一定分析和討論。

一、 Buffer Pool 的insert 機(jī)制

BP可以被認(rèn)為是一條長(zhǎng)鏈表。被分成young 和 old兩個(gè)部分，其中old默認(rèn)占37%的大?。ㄓ?CODE class=literal>innodb_old_blocks_pct 配置）?？拷敹说腜age表示最近被放問?？拷捕说腜age表示長(zhǎng)時(shí)間未被訪問。而這兩個(gè)部分的交匯處成為midpoint。每當(dāng)有新的Page需要加載到BP時(shí)，該page都會(huì)被插入到midpoint的位置，并聲明為old-page。當(dāng)old部分的page，被訪問到時(shí)，該page會(huì)被提升到鏈表的頂端，標(biāo)識(shí)為young。

由于table scan的操作是先load page，然后立即觸發(fā)一次訪問。所以當(dāng)innodb_old_blocks_time =0 時(shí)，會(huì)導(dǎo)致table scan所需要的page不讀的作為young page被添加到鏈表頂端。而一些使用較為不頻繁的page就會(huì)被擠出BP，使得之后的SQL會(huì)產(chǎn)生磁盤IO，從而導(dǎo)致響應(yīng)速度變慢。這也就是標(biāo)題中所提到的BP污染。

二、 修改innodb_old_blocks_time 的效果

percona之前也做過相關(guān)測(cè)試，其結(jié)論是time=0時(shí)，正常訪問的吞吐量下降為10%；當(dāng)time=1000時(shí)，吞吐量和沒有備份時(shí)的性能一致。

是否真是如此呢，我們來(lái)親自測(cè)試一下。

下面是測(cè)試結(jié)果：

其中concurrency代表sysbench中 --num-threads的數(shù)值。

OPT代表該環(huán)境下，沒有mysqldump時(shí)的sysbench QPS。

余下兩列分別代表有mysqldump時(shí)的sysbench QPS。

由結(jié)果可以看出，time=1000并沒有給查詢性能帶來(lái)很大的提升。最佳情況下也只是比time=0時(shí)提高80%的性能。

為什么呢？

其實(shí)不難理解，表中的concurrency很大程度上決定了測(cè)試page的冷熱程度。并發(fā)數(shù)越大，每面產(chǎn)生的并行請(qǐng)求就越多，從而每個(gè)page被訪問的頻率就越高，page在LRU鏈表中的位置也就越靠頂端。反之亦然。

那么我們來(lái)想想下高頻率熱點(diǎn)數(shù)據(jù)訪問時(shí)的情況。這時(shí)雖然mysqldump訪問的page會(huì)不斷加載在LRU頂端，但是高頻度的熱點(diǎn)數(shù)據(jù)訪問會(huì)以更快的速度把page再次搶占到LRU頂端。從而導(dǎo)致mysqldump加載入的page會(huì)被迅速刷下，并立即被evict（淘汰）。因此，time=0或1000對(duì)這種壓力環(huán)境下的訪問不會(huì)造成很大影響，因?yàn)閐ump的數(shù)據(jù)根本搶占不過熱點(diǎn)數(shù)據(jù)。

同樣，超低頻率的數(shù)據(jù)訪問也是一樣的情況。由于數(shù)據(jù)訪問頻度很低，大量的page都處于LRU鏈表的尾端。所以無(wú)論dump的page被加載到head或是midpoint位置，都會(huì)在熱點(diǎn)數(shù)據(jù)的前面。也就是說無(wú)論怎樣，數(shù)據(jù)page都會(huì)被淘汰。所以，這種壓力環(huán)境下的性能同樣不會(huì)隨著time值的配置變化有很大浮動(dòng)。

真正能夠享受到time帶來(lái)的福利的是那些 處于midpoint邊緣的不溫不火的數(shù)據(jù)。

從下圖也可以看出，性能提升最大的情況集中在中等訪問量的情況下，也即 37%的位置上

三、 Mid Point位置帶來(lái)的影響

從之前的分析也可以得出這樣的結(jié)論：innodb_old_blocks_time 的作用范圍對(duì)page的冷熱情況有直接聯(lián)系。而innodb_old_blocks_pct 又決定了BP的數(shù)據(jù)分布。

那么 innodb_old_blocks_pct 的調(diào)節(jié)，能夠左右 innodb_old_blocks_time的影響范圍。

上圖的曲線也證明了這樣的觀點(diǎn)。當(dāng)innodb_old_blocks_pct 調(diào)節(jié)到60%時(shí)，波峰也相應(yīng)平移到了 60%的位置。

總結(jié)：
1. innodb_old_blocks_time =1000 一定程度上可以降低mysqldump類型的訪問對(duì)數(shù)據(jù)庫(kù)性能帶來(lái)的影響。
2. innodb_old_blocks_time =1000 的優(yōu)化效果有限，對(duì)于處于midpoint附近的page能帶來(lái)最大的提升效果。

最新評(píng)論