最新文章專題視頻專題問答1問答10問答100問答1000問答2000關(guān)鍵字專題1關(guān)鍵字專題50關(guān)鍵字專題500關(guān)鍵字專題1500TAG最新視頻文章推薦1 推薦3 推薦5 推薦7 推薦9 推薦11 推薦13 推薦15 推薦17 推薦19 推薦21 推薦23 推薦25 推薦27 推薦29 推薦31 推薦33 推薦35 推薦37視頻文章20視頻文章30視頻文章40視頻文章50視頻文章60 視頻文章70視頻文章80視頻文章90視頻文章100視頻文章120視頻文章140 視頻2關(guān)鍵字專題關(guān)鍵字專題tag2tag3文章專題文章專題2文章索引1文章索引2文章索引3文章索引4文章索引5123456789101112131415文章專題3
問答文章1 問答文章501 問答文章1001 問答文章1501 問答文章2001 問答文章2501 問答文章3001 問答文章3501 問答文章4001 問答文章4501 問答文章5001 問答文章5501 問答文章6001 問答文章6501 問答文章7001 問答文章7501 問答文章8001 問答文章8501 問答文章9001 問答文章9501
當(dāng)前位置: 首頁 - 科技 - 知識百科 - 正文

mysqldump造成BufferPool污染的研究_MySQL

來源:懂視網(wǎng) 責(zé)編:小采 時間:2020-11-09 18:05:00
文檔

mysqldump造成BufferPool污染的研究_MySQL

mysqldump造成BufferPool污染的研究_MySQL:mysqldump bitsCN.com 前言: 最近Oracle MySQL在其官方Blog上貼出了 5.6中一些變量默認(rèn)值的修改。其中innodb_old_blocks_time 的默認(rèn)值從0替換成了1000(即1s) 關(guān)于該參數(shù)的作用摘錄如下: how long in milliseconds (ms)
推薦度:
導(dǎo)讀mysqldump造成BufferPool污染的研究_MySQL:mysqldump bitsCN.com 前言: 最近Oracle MySQL在其官方Blog上貼出了 5.6中一些變量默認(rèn)值的修改。其中innodb_old_blocks_time 的默認(rèn)值從0替換成了1000(即1s) 關(guān)于該參數(shù)的作用摘錄如下: how long in milliseconds (ms)

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

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污染。

二、 修改innodb_old_blocks_time 的效果

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%的位置上

三、 Mid Point位置帶來的影響

從之前的分析也可以得出這樣的結(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

文檔

mysqldump造成BufferPool污染的研究_MySQL

mysqldump造成BufferPool污染的研究_MySQL:mysqldump bitsCN.com 前言: 最近Oracle MySQL在其官方Blog上貼出了 5.6中一些變量默認(rèn)值的修改。其中innodb_old_blocks_time 的默認(rèn)值從0替換成了1000(即1s) 關(guān)于該參數(shù)的作用摘錄如下: how long in milliseconds (ms)
推薦度:
標(biāo)簽: mysql 污染 bufferpool
  • 熱門焦點(diǎn)

最新推薦

猜你喜歡

熱門推薦

專題
Top