程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> MYSQL數據庫 >> MySQL綜合教程 >> mysqldump形成Buffer Pool淨化的研討

mysqldump形成Buffer Pool淨化的研討

編輯:MySQL綜合教程

mysqldump形成Buffer Pool淨化的研討。本站提示廣大學習愛好者:(mysqldump形成Buffer Pool淨化的研討)文章只能為提供參考,不一定能成為您想要的結果。以下是mysqldump形成Buffer Pool淨化的研討正文


媒介:

比來Oracle MySQL在其官方Blog上貼出了 5.6中一些變量默許值的修正。個中innodb_old_blocks_time 的默許值從0調換成了1000(即1s)

關於該參數的感化摘錄以下:

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.

其實感化就是:減小單次的年夜批量數據查詢(相似於mysqldump的行動)關於BufferPool(下稱BP)的淨化。

說到這裡就不能不提一下BP的midpoint insert 機制。

下文就將關於這個機制做必定剖析和評論辯論。


1、 Buffer Pool 的insert 機制

BP可以被以為是一條長鏈表。被分紅young 和 old兩個部門,個中old默許占37%的年夜小(由innodb_old_blocks_pct 設置裝備擺設)。接近頂真個Page表現比來被放問。接近尾真個Page表現長時光未被拜訪。而這兩個部門的交匯處成為midpoint。每當有新的Page須要加載到BP時,該page都邑被拔出到midpoint的地位,並聲明為old-page。當old部門的page,被拜訪到時,該page會被晉升到鏈表的頂端,標識為young。

因為table scan的操作是先load page,然後立刻觸發一次拜訪。所以當innodb_old_blocks_time =0 時,會招致table scan所須要的page不讀的作為young page被添加到鏈表頂端。而一些應用較為不頻仍的page就會被擠出BP,使得以後的SQL會發生磁盤IO,從而招致呼應速度變慢。這也就是題目中所提到的BP淨化。

 

2、 修正innodb_old_blocks_time 的後果

percona之前也做過相干測試,其結論是time=0時,正常拜訪的吞吐量降低為10%;當time=1000時,吞吐量和沒有備份時的機能分歧。

能否真是如斯呢,我們來親身測試一下。

上面是測試成果:

個中concurrency代表sysbench中 --num-threads的數值。

OPT代表該情況下,沒有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

由成果可以看出,time=1000並沒有給查詢機能帶來很年夜的晉升。最好情形下也只是比time=0時進步80%的機能。

為何呢?

其實不難懂得,表中的concurrency很年夜水平上決議了測試page的冷熱水平。並發數越年夜,每面發生的並行要求就越多,從而每一個page被拜訪的頻率就越高,page在LRU鏈表中的地位也就越靠頂端。反之亦然。

那末我們來想一想下高頻率熱門數據拜訪時的情形。這時候固然mysqldump拜訪的page會赓續加載在LRU頂端,然則高頻度的熱門數據拜訪會以更快的速度把page再次搶占到LRU頂端。從而招致mysqldump加載入的page會被敏捷刷下,並立刻被evict(镌汰)。是以,time=0或1000對這類壓力情況下的拜訪不會形成很年夜影響,由於dump的數據基本搶占不外熱門數據。

異樣,超低頻率的數據拜訪也是一樣的情形。因為數據拜訪頻度很低,年夜量的page都處於LRU鏈表的尾端。所以不管dump的page被加載到head或是midpoint地位,都邑在熱門數據的後面。也就是說不管如何,數據page都邑被镌汰。所以,這類壓力情況下的機能異樣不會跟著time值的設置裝備擺設變更有很年夜浮動。

真正可以或許享用到time帶來的福利的是那些 處於midpoint邊沿的不溫不火的數據。

從下圖也能夠看出,機能晉升最年夜的情形集中在中等拜訪量的情形下,也即 37%的地位上

3、 Mid Point地位帶來的影響

從之前的剖析也能夠得出如許的結論:innodb_old_blocks_time 的感化規模對page的冷熱忱況有直接接洽。而innodb_old_blocks_pct 又決議了BP的數據散布。

那末 innodb_old_blocks_pct 的調理,可以或許閣下 innodb_old_blocks_time的影響規模。

上圖的曲線也證實了如許的不雅點。當innodb_old_blocks_pct 調理到60%時,波峰也響應平移到了 60%的地位。

總結:
1. innodb_old_blocks_time =1000 必定水平上可以下降mysqldump類型的拜訪對數據庫機能帶來的影響。
2. innodb_old_blocks_time =1000 的優化後果無限,關於處於midpoint鄰近的page能帶來最年夜的晉升後果。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved