BP可以被認(rèn)為是一條長鏈表。被分成young 和 old兩個部分,其中old默認(rèn)占37%的大?。ㄓ?code class="literal">innodb_old_blocks_pct 配置)??拷敹说腜age表示最近被放問。靠近尾端的Page表示長時間未被訪問。而這兩個部分的交匯處成為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 |
4 | 64717 | 6805 | 8337 |
5 | 83551 | 8676 | 15885 |
6 | 99396 | 12978 | 19893 |
7 | 112330 | 16491 | 26022 |
8 | 126600 | 23840 | 33346 |
9 | 138468 | 30760 | 39194 |
10 | 150365 | 39034 | 48925 |
11 | 163053 | 43174 | 60352 |
12 | 174916 | 52066 | 70180 |
13 | 174160 | 63853 | 78076 |
14 | 173786 | 65164 | 80661 |
15 | 174268 | 70965 | 90633 |
16 | 175044 | 80871 | 102629 |
17 | 175583 | 90689 | 103423 |
18 | 175939 | 94805 | 112629 |
19 | 175114 | 93303 | 120625 |
由結(jié)果可以看出,time=1000并沒有給查詢性能帶來很大的提升。最佳情況下也只是比time=0時提高80%的性能。
為什么呢?
其實(shí)不難理解,表中的concurrency很大程度上決定了測試page的冷熱程度。并發(fā)數(shù)越大,每面產(chǎn)生的并行請求就越多,從而每個page被訪問的頻率就越高,page在LRU鏈表中的位置也就越靠頂端。反之亦然。
那么我們來想想下高頻率熱點(diǎn)數(shù)據(jù)訪問時的情況。這時雖然mysqldump訪問的page會不斷加載在LRU頂端,但是高頻度的熱點(diǎn)數(shù)據(jù)訪問會以更快的速度把page再次搶占到LRU頂端。從而導(dǎo)致mysqldump加載入的page會被迅速刷下,并立即被evict(淘汰)。因此,time=0或1000對這種壓力環(huán)境下的訪問不會造成很大影響,因?yàn)閐ump的數(shù)據(jù)根本搶占不過熱點(diǎn)數(shù)據(jù)。
同樣,超低頻率的數(shù)據(jù)訪問也是一樣的情況。由于數(shù)據(jù)訪問頻度很低,大量的page都處于LRU鏈表的尾端。所以無論dump的page被加載到head或是midpoint位置,都會在熱點(diǎn)數(shù)據(jù)的前面。也就是說無論怎樣,數(shù)據(jù)page都會被淘汰。所以,這種壓力環(huán)境下的性能同樣不會隨著time值的配置變化有很大浮動。
真正能夠享受到time帶來的福利的是那些 處于midpoint邊緣的不溫不火的數(shù)據(jù)。
從下圖也可以看出,性能提升最大的情況集中在中等訪問量的情況下,也即 37%的位置上
從之前的分析也可以得出這樣的結(jié)論:innodb_old_blocks_time 的作用范圍對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%時,波峰也相應(yīng)平移到了 60%的位置。
總結(jié):
1. innodb_old_blocks_time =1000 一定程度上可以降低mysqldump類型的訪問對數(shù)據(jù)庫性能帶來的影響。
2. innodb_old_blocks_time =1000 的優(yōu)化效果有限,對于處于midpoint附近的page能帶來最大的提升效果。
bitsCN.com聲明:本網(wǎng)頁內(nèi)容旨在傳播知識,若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com