mysql內存優化

一.環境說明：

操做系統：CentOS 6.5 x86_64

數據庫：Mysql 5.6.22

服務器：阿里雲VPS，32G Mem，0 swap


二.問題狀況：

1.某日發現公司線上系統的Mysql某個實例的從庫長時間內存佔用達到60%以下圖



2.因而開始按照如下步驟排查：

(1).查看mysql裏的線程，觀察是否有長期運行或阻塞的sql：

show full processlist

經查看，沒有發現相關線程，可排除該緣由


(2).疑似mysql鏈接使用完成後沒有真正釋放內存，查看mysql內存，緩存的相關配置，使用如

show global variables like '%sort_buffer_size%';

查看相關的配置項，結果列表彙總以下

 

( 注：上圖爲mysql使用內存計算器，具體地址爲http://www.mysqlcalculator.com/ )


其中左列爲mysql默認配置，右列爲當前數據庫的配置，可見預期內存使用最大值足足達到了1T，不符合當前系統負載量，說明當前配置不合理，須要進行調整


(3).其中

key_buffer_size = 32M         //key_buffer_size指定索引緩衝區的大小，它決定索引處理的速度，尤爲是索引讀的速度。只對MyISAM表起做用。即便你不使用MyISAM表，可是內部的臨時磁盤表是MyISAM表，也要使用該值。因爲個人數據庫引擎爲innodb，大部分表均爲innodb，此處取默認值一半32M。


query_cache_size = 64M    //查詢緩存大小，當打開時候，執行查詢語句會進行緩存，讀寫都會帶來額外的內存消耗，下次再次查詢若命中該緩存會馬上返回結果。默認改選項爲關閉，打開則須要調整參數項query_cache_type=ON。此處採用默認值64M。


tmp_table_size = 64M    //範圍設置爲64-256M最佳，當須要作相似group by操做生成的臨時表大小，提升聯接查詢速度的效果，調整該值直到created_tmp_disk_tables / created_tmp_tables * 100% <= 25%，處於這樣一個狀態之下，效果較好，若是網站大部分爲靜態內容，可設置爲64M，若是爲動態頁面，則設置爲100M以上，不宜過大，致使內存不足I/O堵塞。此處咱們設置爲64M。


innodb_buffer_pool_size = 8196M   //這個參數主要做用是緩存innodb表的索引，數據，插入數據時的緩衝。專用mysql服務器設置的大小： 操做系統內存的70%-80%最佳。因爲咱們的服務器還部署有其餘應用，估此處設置爲8G。此外，這個參數是非動態的，要修改這個值，須要重啓mysqld服務。設置的過大，會致使system的swap空間被佔用，致使操做系統變慢，從而減低sql查詢的效率。


innodb_additional_mem_pool_size = 16M    //用來存放Innodb的內部目錄，這個值不用分配太大，系統能夠自動調。不用設置過高。一般比較大數據設置16Ｍ夠用了，若是表比較多，能夠適當的增大。若是這個值自動增長，會在error log有中顯示的。此處咱們設置爲16M。


innodb_log_buffer_size = 8M  //InnoDB的寫操做，將數據寫入到內存中的日誌緩存中，因爲InnoDB在事務提交前，並不將改變的日誌寫入到磁盤中，所以在大事務中，能夠減輕磁盤I/O的壓力。一般狀況下，若是不是寫入大量的超大二進制數據（a lot of huge blobs），4MB-8MB已經足夠了。此處咱們設置爲8M。


max_connections = 800    //最大鏈接數，根據同時在線人數設置一個比較綜合的數字，最大不超過16384。此處咱們根據系統使用量綜合評估，設置爲800。

sort_buffer_size = 2M    //是一個connection級參數，在每一個connection第一次須要使用這個buffer的時候，一次性分配設置的內存。並非越大越好，因爲是connection級的參數，過大的設置+高併發可能會耗盡系統內存資源。官方文檔推薦範圍爲256KB~2MB，這裏咱們設置爲2M。


read_buffer_size = 2M   //（數據文件存儲順序）是MySQL讀入緩衝區的大小，將對錶進行順序掃描的請求將分配一個讀入緩衝區，MySQL會爲它分配一段內存緩衝區，read_buffer_size變量控制這一緩衝區的大小，若是對錶的順序掃描很是頻繁，並你認爲頻繁掃描進行的太慢，能夠經過增長該變量值以及內存緩衝區大小提升其性能，read_buffer_size變量控制這一提升表的順序掃描的效率 數據文件順序。此處咱們設置得比默認值大一點，爲2M。


read_rnd_buffer_size = 250K  //是MySQL的隨機讀緩衝區大小，當按任意順序讀取行時（列如按照排序順序）將分配一個隨機讀取緩衝區，進行排序查詢時，MySQL會首先掃描一遍該緩衝，以免磁盤搜索，提升查詢速度，若是須要大量數據可適當的調整該值，但MySQL會爲每一個客戶鏈接分配該緩衝區因此儘可能適當設置該值，以避免內存開銷過大。表的隨機的順序緩衝 提升讀取的效率。此處設置爲跟默認值類似，250KB。


join_buffer_size = 250K   //多表參與join操做時的分配緩存，適當分配，下降內存消耗，此處咱們設置爲250KB。


thread_stack = 256K   //每一個鏈接線程被建立時，MySQL給它分配的內存大小。當MySQL建立一個新的鏈接線程時，須要給它分配必定大小的內存堆棧空間，以便存放客戶端的請求的Query及自身的各類狀態和處理信息。Thread Cache 命中率：Thread_Cache_Hit = (Connections - Threads_created) / Connections * 100%;命中率處於90%纔算正常配置，當出現「mysql-debug: Thread stack overrun」的錯誤提示的時候須要增長該值。此處咱們配置爲256K。


binlog_cache_size = 250K  // 爲每一個session 分配的內存，在事務過程當中用來存儲二進制日誌的緩存。做用是提升記錄bin-log的效率。沒有什麼大事務，dml也不是很頻繁的狀況下能夠設置小一點，若是事務大並且多，dml操做也頻繁，則能夠適當的調大一點。前者建議是1048576  --1M；後者建議是： 2097152 -- 4194304  即 2--4M。此處咱們根據系統實際，配置爲250KB。



調整後各項性能參數以下圖，且通過圖表計算，實例使用的內存將穩定在12G左右，符合當前系統負載狀況

 

以後重啓Mysql實例，發現內存佔用量回落，而且長時間內沒有再次發生佔用太高狀況，優化成功。


三.總結：

具體涉及到內存分配，緩存的參數及其具體做用在此不一一贅述，後續可自行查閱相關資料，只有屢次根據實際觀測結果調優，才能獲得符合當前業務系統運行的最佳配置。


---------------------
原文：https://blog.csdn.net/dc666/article/details/78901341