<span id="mktg5"></span>

<i id="mktg5"><meter id="mktg5"></meter></i>

        <label id="mktg5"><meter id="mktg5"></meter></label>
        最新文章專題視頻專題問答1問答10問答100問答1000問答2000關鍵字專題1關鍵字專題50關鍵字專題500關鍵字專題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關鍵字專題關鍵字專題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
        當前位置: 首頁 - 科技 - 知識百科 - 正文

        mysqldump造成BufferPool污染的研究

        來源:懂視網 責編:小采 時間:2020-11-09 21:11:02
        文檔

        mysqldump造成BufferPool污染的研究

        mysqldump造成BufferPool污染的研究: 前言: 最近Oracle MySQL在其官方Blog上貼出了 5.6中一些變量默認值的修改。其中innodb_old_blocks_time 的默認值從0替換成了1000(即1s) 關于該參數的作用摘錄如下: how long in milliseconds (ms) a block inserted i
        推薦度:
        導讀mysqldump造成BufferPool污染的研究: 前言: 最近Oracle MySQL在其官方Blog上貼出了 5.6中一些變量默認值的修改。其中innodb_old_blocks_time 的默認值從0替換成了1000(即1s) 關于該參數的作用摘錄如下: how long in milliseconds (ms) a block inserted i

        前言:

        最近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 機制。

        下文就將對于這個機制做一定分析和討論。


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

         

        二、 修改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%的位置上

        三、 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. Mysql優化調優中兩個重要參數table_cache和key_buffer
      2. mysql Key_buffer_size參數的優化設置
      3. PHP中的output_buffering詳細介紹
      4. php緩沖 output_buffering和ob_start使用介紹
      5. Php output buffering緩存及程序緩存深入解析
      6. php中ob(Output Buffer 輸出緩沖)函數使用方法
      7. php中mysql操作buffer用法詳解
      8. 聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com

        文檔

        mysqldump造成BufferPool污染的研究

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

        最新推薦

        猜你喜歡

        熱門推薦

        專題
        Top
        主站蜘蛛池模板: 亚洲视频一区在线观看| 亚洲中文字幕久久精品蜜桃| 亚洲av最新在线网址| 亚洲精品美女在线观看播放| 在线观看人成视频免费无遮挡| 国产成人99久久亚洲综合精品| 亚洲国产日产无码精品| 色片在线免费观看| 亚洲国产午夜电影在线入口| 中文字幕影片免费在线观看| 亚洲色精品VR一区区三区| 美女无遮挡拍拍拍免费视频| 国产亚洲大尺度无码无码专线| 伊人久久大香线蕉免费视频| 亚洲国产精品无码久久久蜜芽| 日本黄色动图免费在线观看| 亚洲成a人片7777| 永久黄网站色视频免费观看| 黄网站色视频免费看无下截| 亚洲一区二区三区偷拍女厕 | 亚洲成AV人片在线观看ww| 日韩电影免费观看| 亚洲jjzzjjzz在线观看| 四虎影视精品永久免费网站| 一个人看www免费高清字幕| 亚洲va久久久噜噜噜久久| 免费观看无遮挡www的视频| 亚洲欧美成人综合久久久| 亚洲日韩在线中文字幕第一页| a级毛片在线免费| 亚洲国产激情在线一区| 久久久亚洲精品蜜桃臀| 最近新韩国日本免费观看| 亚洲第一第二第三第四第五第六| 亚洲男人的天堂一区二区| 久久这里只精品国产免费10| 久久综合久久综合亚洲| 国产亚洲一区二区三区在线不卡| 69视频免费在线观看| 边摸边脱吃奶边高潮视频免费| 亚洲va久久久噜噜噜久久天堂 |