前言:
最近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ù)據(jù)查詢(類似于mysqldump的行為)對于BufferPool(下稱BP)的污染。
說到這里就不得不提一下BP的midpoint insert 機制。
下文就將對于這個機制做一定分析和討論。
BP可以被認(rèn)為是一條長鏈表。被分成young 和 old兩個部分,其中old默認(rèn)占37%的大小(由innodb_old_blocks_pct 配置)??拷敹说腜age表示最近被放問??拷捕说腜age表示長時間未被訪問。而這兩個部分的交匯處成為midpoint。每當(dāng)有新的Page需要加載到BP時,該page都會被插入到midpoint的位置,并聲明為old-page。當(dāng)old部分的page,被訪問到時,該page會被提升到鏈表的頂端,標(biāo)識為young。
由于table scan的操作是先load page,然后立即觸發(fā)一次訪問。所以當(dāng)innodb_old_blocks_time =0 時,會導(dǎo)致table scan所需要的page不讀的作為young page被添加到鏈表頂端。而一些使用較為不頻繁的page就會被擠出BP,使得之后的SQL會產(chǎn)生磁盤IO,從而導(dǎo)致響應(yīng)速度變慢。這也就是標(biāo)題中所提到的BP污染。
percona之前也做過相關(guān)測試,其結(jié)論是time=0時,正常訪問的吞吐量下降為10%;當(dāng)time=1000時,吞吐量和沒有備份時的性能一致。
是否真是如此呢,我們來親自測試一下。
下面是測試結(jié)果:
其中concurrency代表sysbench中 --num-threads的數(shù)值。
OPT代表該環(huán)境下,沒有mysqldump時的sysbench QPS。
余下兩列分別代表有mysqldump時的sysbench QPS。
| Concurrency | OPT | old_time=0 | old_time=1000 |
| 1 | 17394 | 1836 | 2141 |
| 2 | 29703 | 3670 | 3981 |
| 3 | 47347 | 5683 | 6540 |