| 作者 鄧英明 ，騰訊云DBA，擅長數(shù)據(jù)庫架構(gòu)設(shè)計、故障診斷、性能優(yōu)化，現(xiàn)主要負責騰訊云數(shù)據(jù)庫MySQL/TDSQL-C/Redis的相關(guān)工作。

在日常工作中，時不時會收到內(nèi)存使用率高的告警，那么我們應(yīng)該如何處理呢？本文將從Linux和MySQL兩個層面，介紹內(nèi)存管理的相關(guān)知識點，希望能給大家?guī)硪恍椭?，以便更好地?yīng)對內(nèi)存問題。

一、如何看懂內(nèi)存指標

遇到內(nèi)存問題，可以先通過free、vmstat、top等命令，進行檢查。free命令，可以獲取系統(tǒng)內(nèi)存的總體使用情況；vmstat命令，可以實時觀察內(nèi)存的變化情況；top命令，可以進行排序，獲取內(nèi)存占用大的進程。這里簡單介紹一下free命令輸出(以CentOS 7為例)：

total        used        free      shared  buff/cache   available 
Mem:        8008704     5234876      157920         640     2615908     2467292 
Swap:          2047           0        2047 

第一行是內(nèi)存數(shù)據(jù)

1. total：內(nèi)存總大小，對應(yīng)于/proc/meminfo的MemTotal

2. used：已使用的內(nèi)存大小，對應(yīng)于/proc/meminfo的(MemTotal - MemFree - Buffers - Cached - Slab)

3. free：未使用的內(nèi)存大小，對應(yīng)于/proc/meminfo的MemFree

4. buff/cache：已使用的緩存大小，對應(yīng)于/proc/meminfo的Buffers+Cached

5. available：可供使用的內(nèi)存大小，這是一個預估值，對應(yīng)于/proc/meminfo的MemAvailable

第二行是交換分區(qū)數(shù)據(jù)

1. total：交換分區(qū)總大小，對應(yīng)于/proc/meminfo的SwapTotal

2. used：已使用的交換分區(qū)，對應(yīng)于/proc/meminfo的(SwapTotal - SwapFree)

3. free：未使用的的內(nèi)存大小，對應(yīng)于/proc/meminfo的SwapFree

這里值得注意的是，Linux操作系統(tǒng)會最大限度利用內(nèi)存，空閑內(nèi)存free少，不代表系統(tǒng)內(nèi)存不夠用了。個人建議，一方面需要觀察內(nèi)存增長的整體趨勢是否逐漸趨于平穩(wěn)、以及used和buff/cache的變化情況；另一方面需要觀察是否頻繁使用到交換分區(qū)swap，當然了，這里要避免NUMA和swapiness設(shè)置不正確帶來的干擾。

二、MySQL如何使用內(nèi)存

在MySQL中，內(nèi)存占用主要包括以下幾部分，全局共享的內(nèi)存、線程獨占的內(nèi)存、內(nèi)存分配器占用的內(nèi)存，具體如下：

全局共享

1. innodb_buffer_pool_size：InnoDB緩沖池的大小

2. innodb_additional_mem_pool_size：InnoDB存放數(shù)據(jù)字典和其他內(nèi)部數(shù)據(jù)結(jié)構(gòu)的內(nèi)存大小，5.7已被移除

3. innodb_log_buffer_size：InnoDB日志緩沖的大小

4. key_buffer_size：MyISAM緩存索引塊的內(nèi)存大小

5. query_cache_size：查詢緩沖的大小，8.0已被移除

線程獨占

1. thread_stack：每個線程分配的堆棧大小

2. sort_buffer_size：排序緩沖的大小

3. join_buffer_size：連接緩沖的大小

4. read_buffer_size：MyISAM順序讀緩沖的大小

5. read_rnd_buffer_size：MyISAM隨機讀緩沖的大小、MRR緩沖的大小

6. tmp_table_size/max_heap_table_size：內(nèi)存臨時表的大小

7. binlog_cache_size：二進制日志緩沖的大小

內(nèi)存分配器

在MySQL中，buffer pool的內(nèi)存，是通過mmap()方式直接向操作系統(tǒng)申請分配；除此之外，大多數(shù)的內(nèi)存管理，都需要經(jīng)過內(nèi)存分配器。為了實現(xiàn)更高效的內(nèi)存管理，避免頻繁的內(nèi)存分配與回收，內(nèi)存分配器會長時間占用大量內(nèi)存，以供內(nèi)部重復使用。關(guān)于內(nèi)存分配器的選擇，推薦使用jemalloc，可以有效解決內(nèi)存碎片與提升整體性能。

因此，MySQL占用內(nèi)存高的原因可能包括：innodb_buffer_pool_size設(shè)置過大、連接數(shù)/并發(fā)數(shù)過高、大量排序操作、內(nèi)存分配器占用、以及MySQL Bug等等。一般來說，在MySQL整個運行周期內(nèi)，剛啟動時內(nèi)存上漲會比較快，運行一段時間后會逐漸趨于平穩(wěn)，這種情況是不需要過多關(guān)注的；如果在穩(wěn)定運行后，出現(xiàn)內(nèi)存突增、內(nèi)存持續(xù)增長不釋放的情況，那就需要我們進一步分析是什么原因造成的。

三、到底是誰占用了內(nèi)存

在絕大多數(shù)情況下，我們是不需要花費過多精力，去關(guān)注MySQL內(nèi)存使用情況的； 但是，也不能排除確實存在內(nèi)存占用異常的情況，這個時候我們應(yīng)該如何去進行深入排查呢？ 其實，MySQL官方就提供了強大的實時監(jiān)控工具——performance_schema庫下的監(jiān)控內(nèi)存表，通過這個工具，我們可以很清晰地觀察到MySQL內(nèi)存到底是被誰占用了、分別占用了多少。

開啟內(nèi)存監(jiān)控

實例啟動時開啟

我們可以選擇，在實例啟動時，開啟內(nèi)存監(jiān)控采集器，具體方法如下：

vi my.cnf 
performance-schema-instrument='memory/%=ON' 

禁用方法如下：

vi my.cnf 
performance-schema-instrument='memory/%=OFF' 

實例運行時開啟

我們也可以選擇 ，在實 例運 行時，動態(tài)開啟內(nèi)存監(jiān)控采集器，具體方法如下：

mysql> UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'memory/%'; 

禁用方法如下：

mysql> UPDATE performance_schema.setup_instruments SET ENABLED = 'NO' WHERE NAME LIKE 'memory/%'; 

因為采集器的實現(xiàn)原理，是在內(nèi)存進行分配/回收時，更新相對應(yīng)內(nèi)存監(jiān)控表的數(shù)據(jù)；換句話說，就是采集器只能監(jiān)控到開啟之后的內(nèi)存使用情況；而MySQL很大一部分內(nèi)存都是在實例啟動時就預先分配的，因此要想準確監(jiān)控實例的內(nèi)存使用率，需要在實例啟動時就開啟內(nèi)存采集器。

內(nèi)存監(jiān)控表

在performance_schema庫下，提供多個維度的內(nèi)存監(jiān)控表，具體如下：

memory_summary_by_account_by_event_name： 賬號緯度的內(nèi)存監(jiān)控表

memory_summary_by_host_by_event_name： 主機緯度的內(nèi)存監(jiān)控表

memory_summary_by_thread_by_event_name： 線程維度的內(nèi)存監(jiān)控表

memory_summary_by_user_by_event_name： 用戶緯度的內(nèi)存監(jiān)控表

memory_summary_global_by_event_name： 全局緯度的內(nèi)存監(jiān)控表

內(nèi)存監(jiān)控表均包括以下關(guān)鍵字段：

COUNT_ALLOC： 內(nèi)存分配次數(shù)

C OUNT_FREE： 內(nèi)存回收次數(shù)

S UM_NUMBER_OF_BYTES_ALLOC： 內(nèi)存分配大小

SUM_NUMBER_OF_BYTES_FREE： 內(nèi)存回收大小

CURRENT_COUNT_USED： 當前分配的內(nèi)存，通過COUNT_ALLOC-COUNT_FREE計算得到

CURRENT_NUMBER_OF_BYTES_USED： 當前分配的內(nèi)存大小，通過SUM_NUMBER_OF_BYTES_ALLOC-SUM_NUMBER_OF_BYTES_FREE計算得到

LOW_COUNT_USED： CURRENT_COUNT_USED的最小值

HIGH_COUNT_USED： CURRENT_COUNT_USED的最大值

LOW_NUMBER_OF_BYTES_USED： CURRENT_NUMBER_OF_BYTES_USED的最小值

HIGH_NUMBER_OF_BYTES_USED： CURRENT_NUMBER_OF_BYTES_USED的最大值

接下來，讓我們看一個正常運行實例的內(nèi)存使用情況，具體如下：

mysql> select USER,HOST,EVENT_NAME,COUNT_ALLOC,COUNT_FREE,CURRENT_COUNT_USED,SUM_NUMBER_OF_BYTES_ALLOC,SUM_NUMBER_OF_BYTES_FREE,CURRENT_NUMBER_OF_BYTES_USED from performance_schema.memory_summary_by_account_by_event_name order by CURRENT_NUMBER_OF_BYTES_USED desc limit 10; 
+------+-----------+----------------------------+-------------+------------+--------------------+---------------------------+--------------------------+------------------------------+ 
| USER | HOST      | EVENT_NAME                 | COUNT_ALLOC | COUNT_FREE | CURRENT_COUNT_USED | SUM_NUMBER_OF_BYTES_ALLOC | SUM_NUMBER_OF_BYTES_FREE | CURRENT_NUMBER_OF_BYTES_USED | 
+------+-----------+----------------------------+-------------+------------+--------------------+---------------------------+--------------------------+------------------------------+ 
| NULL | NULL      | memory/innodb/buf_buf_pool |          32 |          0 |                 32 |                4500488192 |                        0 |                   4500488192 | 
| NULL | NULL      | memory/innodb/os0event     |     1573559 |          0 |            1573559 |                 214004024 |                        0 |                    214004024 | 
| NULL | NULL      | memory/innodb/hash0hash    |          82 |          6 |                 76 |                 397976480 |                227067024 |                    170909456 | 
| NULL | NULL      | memory/innodb/log0log      |          10 |          0 |                 10 |                  33565840 |                        0 |                     33565840 | 
| root | localhost | memory/innodb/std          |     3650638 |    3043111 |             607527 |                 160778066 |                141334898 |                     19443168 | 
| NULL | NULL      | memory/mysys/KEY_CACHE     |           3 |          0 |                  3 |                   8390768 |                        0 |                      8390768 | 
| NULL | NULL      | memory/innodb/ut0pool      |           2 |          0 |                  2 |                   4194480 |                        0 |                      4194480 | 
| NULL | NULL      | memory/innodb/sync0arr     |           3 |          0 |                  3 |                   2506184 |                        0 |                      2506184 | 
| NULL | NULL      | memory/innodb/lock0lock    |          33 |          0 |                 33 |                   2245040 |                        0 |                      2245040 | 
| root | localhost | memory/innodb/mem0mem      |     9897784 |    9896793 |                991 |                8845389160 |               8843147749 |                      2241411 | 
+------+-----------+----------------------------+-------------+------------+--------------------+---------------------------+--------------------------+------------------------------+ 
10 rows in set (0.01 sec) 

再看一個Bug #86821的場景，buffer pool占用最大內(nèi)存正常，但是存儲過程占用3GB就比較異常了，存在內(nèi)存泄漏的風險；由此可知，通過內(nèi)存監(jiān)控表，我們可以快速定位內(nèi)存異常占用問題。

mysql> select event_name, current_alloc, high_alloc from memory_global_by_current_bytes where current_count > 0; 
+--------------------------------------------------------------------------------+---------------+-------------+ 
| event_name                                                                     | current_alloc | high_alloc  | 
+--------------------------------------------------------------------------------+---------------+-------------+ 
| memory/innodb/buf_buf_pool                                                     | 7.29 GiB      | 7.29 GiB    | 
| memory/sql/sp_head::main_mem_root                                              | 3.21 GiB      | 3.62 GiB    | 
| memory/innodb/hash0hash                                                        | 210.16 MiB    | 323.63 MiB  | 
| memory/sql/TABLE                                                               | 183.82 MiB    | 190.28 MiB  | 
| memory/sql/Query_cache                                                         | 128.02 MiB    | 128.02 MiB  | 
| memory/mysys/KEY_CACHE                                                         | 64.00 MiB     | 64.00 MiB   | 
| memory/innodb/log0log                                                          | 32.08 MiB     | 32.08 MiB   | 
| memory/innodb/parallel_doublewrite                                             | 30.27 MiB     | 30.27 MiB   | 
| memory/performance_schema/table_handles                                        | 27.19 MiB     | 27.19 MiB   | 
| memory/innodb/mem0mem                                                          | 19.14 MiB     | 20.79 MiB   | 
| memory/performance_schema/events_statements_history_long                       | 13.66 MiB     | 13.66 MiB   | 
| memory/performance_schema/events_statements_summary_by_digest.tokens           | 9.77 MiB      | 9.77 MiB    | 

另外，如果我們在內(nèi)存監(jiān)控表，看見一些比較陌生的event，可以翻閱官方文檔或源碼，繼續(xù)進一步解讀，例如

memory/innodb/os0event

/** @file include/os0event.h 
  The interface to the operating system condition variables 
  
  Created 2012-09-23 Sunny Bains (split from os0sync.h) 
  *******************************************************/ 

memory/innodb/hash0hash

/** @file include/hash0hash.h 
  The simple hash table utility 
  
  Created 5/20/1997 Heikki Tuuri 
  *******************************************************/ 

四、總結(jié)

總的來說，只要我們的操作系統(tǒng)/數(shù)據(jù)庫有一個相對合理的配置(NUMA、swapiness、jemalloc 、innodb_buffer_pool_size等等)，大多數(shù)情況是不需要關(guān)注內(nèi)存問題的； 如果非常不幸運地碰到內(nèi)存占用異常問題，可以通過官方提供的實時監(jiān)控工具——內(nèi)存監(jiān)控表，快速進行定位； 不過需要注意的是，開啟內(nèi)存采集器也會帶來一些問題，比如額外的內(nèi)存占用和性能損耗，一般建議是在系統(tǒng)出現(xiàn)內(nèi)存問題之后，再重啟實例啟用，并等待復現(xiàn)。