Mysql配置參數innodb_buffer_pool_size的學習與整理

    原文地址：Mysql配置參數innodb_buffer_pool_size的學習與整理

    這半個月來，一直在作一些關於服務器交易端性能的提高工做，主要是分析和討論交易端性能的瓶頸，找出致使性能減慢的緣由，擬定出合理的解決方案，主要是經過幾個方面進行研究和學習，今天總算有了一點點突破，主要是涉及mysql核心參數innodb_buffer_pool_size的學習和討論，這裏簡單的整理和總結一下。
   

    首先簡單的介紹一下服務器交易端的環境，使用的是Spring + MyBatis + Mysql的架構，代碼中使用了Spring聲明式事務進行管理，性能的瓶頸主要是存在於事務提交上面，經過測試和分析日誌，發現代碼在進行事務提交時耗時比較嚴重，這半個月的研究也走了許多彎路，總算有得有失，對於其中的一些知識也有了必定的理解，主要是包含下面幾個方面：
    MyBatis

    第一點想到的可能緣由是MyBatis對Connection的管理，因爲對MyBatis的理解不深刻，簡單的分析日誌，發現MyBatis日誌中出現大量的create SqlSession，因而簡單的研究了一下MyBatis SqlSession，這裏有一篇總結的文章：關於MyBatis sqlSession的一點整理

    經過研究討論和查閱源碼，對MyBatis SqlSession有了必定的理解，發現問題可能再也不這裏。

     Mysql

    Mysql的配置是懷疑致使性能瓶頸的緣由，不過沒有證據證實，同事提到了thread_concurrency參數，因而開始了mysql配置參數的學習，可是mysql的配置參數不少，短期內沒法作到面面俱到，因而經過分析線上運行的mysql的配置文件進行學習，這裏也整理出了幾篇文章：

  關於Mysql thread_concurrency和innodb_thread_concurrency參數的一點整理 

  Mysql一些重要配置參數的學習與整理（一） 

  Mysql一些重要配置參數的學習與整理（二） 

  Mysql一些重要配置參數的學習與整理（三）

    經過對線上mysql一些配置參數的學習和討論，感受這些所瞭解到的參數的配置較爲合理，因而研究的重心發生了偏移，轉向了Spring事務管理機制的研究。
    Spring

    Spring的事務管理機制，本身的理解也不清晰，對於源碼也沒有過認真的研讀，因而花費了點時間對Spring Transaction事務管理機制和MyBatis SqlSession進行了再次的學習和研究討論，也算有了一點點收穫，期間也作了總結和整理，並根據本身的理解作了時序圖，詳情見這裏：Spring Transaction + MyBatis SqlSession事務管理機制研究學習

    可是問題又來了，經過與同事的討論和閱讀源碼，更加的迷惑了，好像性能的瓶頸也不是Spring Transaction的問題。不知道接下來該怎麼突破了，一次偶然的與同事交流，出現了起色，在本機進行測試時，發現我本機的性能要明顯優於同事的電腦，那麼問題來了，是什麼致使了性能的差別？

    首先是硬件的不一樣，雖然內存一致，可是CPU版本卻徹底不一樣，CPU的差別是致使性能的一部分緣由，這是第一個突破點；其次是本地mysql配置的不一樣，發現我本地使用的是mysql默認生成的配置，同事本地使用的是服務器上的mysql配置，第二個突破點就是mysql配置的差別，主要是參數的不一樣，因而重心又轉移到了mysql配置文件的研究學習討論上面。

    Mysql   

    中間出現的曲折就不說了，說多了都是淚，結果反覆的測試，發如今增大或減少一個參數的值時，性能差別明顯，通過與同事討論和測試，發現這個參數在高併發高I/O時正確的配置很是重要，可能帶來很大的性能提高，這個參數就是innodb_buffer_pool_size，下面，就來詳細的學習和整理一下這個參數的意義。       

    innodb_buffer_pool_size參數表示緩衝池字節大小，InnoDB緩存表和索引數據的內存區域。mysql默認的值是128M。最大值與你的CPU體系結構有關，在32位操做系統，最大值是 4294967295 (2^32-1) ，在64 位操做系統，最大值爲18446744073709551615 (2^64-1)。在32位操做系統中，CPU和操做系統實用的最大大小低於設置的最大值。若是設定的緩衝池的大小大於1G，設置innodb_buffer_pool_instances的值大於1，在服務器繁忙的時候能夠提升伸縮性，不過在實際的測試中，發現帶來的性能提高並不明顯，並且參考了這裏的一篇文章mysql優化---第7篇：參數 innodb_buffer_pool_instances設置，初步設置innodb_buffer_pool_instances爲1。

    這個值設置的越大，在不止一次的訪問相同的數據表數據時，消耗的磁盤I / O就越少。在一個專用的數據庫服務器，則可能將其設置爲高達80％的機器物理內存大小。不過在實際的測試中，發現無限的增大這個值，帶來的性能提高也並不顯著，對CPU的壓力反而增大，設置合理的值纔是最優。在出現如下問題時，你就須要考慮減小這個參數的值了：

• 物理內存的競爭可能會致使操做系統分頁。
  

• InnoDB儲備額外的內存緩衝區和控制結構,以便總分配空間大於指定的大小大約是10%。

• 地址空間必須是連續的，在經過DLL加載特定地址的Windows系統中，這可能存在問題。
  

• 初始化緩衝池的時間大體與它的大小成正比。在大型系統中，初始化的時間可能很顯著。例如：在現代化的Linux x86_64服務器上，初始化一個10GB的緩衝池大小，大約須要6秒鐘。

    在MySQL 5.7.5版本後，innodb_buffer_pool_size參數的值能夠動態的設置，這意味着你能夠在不啓動服務器的狀況下，從新設置緩衝區的大小。這種調整的操做是按塊執行的。能夠經過innodb_buffer_pool_chunk_size參數配置塊的大小。Innodb_buffer_pool_resize_status狀態變量記錄了從調整操做的狀態。

    一樣的，在mysql的衆多參數中，關係到磁盤IO的參數還有兩個，分別是：innodb_log_buffer_size和innodb_log_file_size。      

    innodb_log_buffer_size表示InnoDB寫入到磁盤上的日誌文件時使用的緩衝區的字節數，默認值爲8M。一個大的日誌緩衝區容許大量的事務在提交以前不寫日誌到磁盤。所以，若是你有不少事務的更新，插入或刪除很操做，經過這個參數會大量的節省了磁盤I / O。

    innodb_log_file_size表示在一個日誌組每一個日誌文件的字節大小。日誌文件的總大小（innodb_log_file_size* innodb_log_files_in_group）不能超過最高值512GB。例如一對255 GB的日誌文件，已經接近了極限，不能超過它。默認值是48M。比較合適的值的範圍是從1MB到1 / N個的緩衝池大小，其中N是該組中的日誌文件的數量。該值越大，緩衝池中必要的檢查點刷新活動就會越少，節省磁盤I/ O。可是越大的日誌文件，mysql的崩潰恢復就越慢，儘管在mysql5.5以後改進了恢復性能和日誌文件恢復的代價。

    上面的兩個參數，並無進行mysql性能的測試，也並無特定的進行配置，下一步，會仔細的研究測試一下，敬請期待。