有哪些數(shù)據(jù)庫內(nèi)存知識點(diǎn)

248次閱讀

共計(jì) 7152 個(gè)字符，預(yù)計(jì)需要花費(fèi) 18 分鐘才能閱讀完成。

本篇內(nèi)容介紹了“有哪些數(shù)據(jù)庫內(nèi)存知識點(diǎn)”的有關(guān)知識，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓丸趣 TV 小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

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

遇到內(nèi)存問題，可以先通過 free、vmstat、top 等命令，進(jìn)行檢查。free 命令，可以獲取系統(tǒng)內(nèi)存的總體使用情況；vmstat 命令，可以實(shí)時(shí)觀察內(nèi)存的變化情況；top 命令，可以進(jìn)行排序，獲取內(nèi)存占用大的進(jìn)程。這里簡單介紹一下 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)存大小，這是一個(gè)預(yù)估值，對應(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)會(huì)最大限度利用內(nèi)存，空閑內(nèi)存 free 少，不代表系統(tǒng)內(nèi)存不夠用了。個(gè)人建議，一方面需要觀察內(nèi)存增長的整體趨勢是否逐漸趨于平穩(wěn)、以及 used 和 buff/cache 的變化情況；另一方面需要觀察是否頻繁使用到交換分區(qū) swap，當(dāng)然了，這里要避免 NUMA 和 swapiness 設(shè)置不正確帶來的干擾。

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

在 MySQL 中，內(nèi)存占用主要包括以下幾部分，全局共享的內(nèi)存、線程獨(dú)占的內(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 已被移除

線程獨(dú)占

1. thread_stack：每個(gè)線程分配的堆棧大小

2. sort_buffer_size：排序緩沖的大小

3. join_buffer_size：連接緩沖的大小

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

5. read_rnd_buffer_size：MyISAM 隨機(jī)讀緩沖的大小、MRR 緩沖的大小

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

7. binlog_cache_size：二進(jìn)制日志緩沖的大小

內(nèi)存分配器

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

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

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

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

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

實(shí)例啟動(dòng)時(shí)開啟

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

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

禁用方法如下：

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

實(shí)例運(yùn)行時(shí)開啟

我們也可以選擇，在實(shí) 例運(yùn) 行時(shí)，動(dòng)態(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/%

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

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

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

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

memory_summary_by_host_by_event_name：主機(jī)緯度的內(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：當(dāng)前分配的內(nèi)存，通過 COUNT_ALLOC-COUNT_FREE 計(jì)算得到

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

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 的最大值

接下來，讓我們看一個(gè)正常運(yùn)行實(shí)例的內(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)

再看一個(gè) Bug #86821 的場景，buffer pool 占用最大內(nèi)存正常，但是存儲(chǔ)過程占用 3GB 就比較異常了，存在內(nèi)存泄漏的風(fēng)險(xiǎn)；由此可知，通過內(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ù)進(jìn)一步解讀，例如

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

“有哪些數(shù)據(jù)庫內(nèi)存知識點(diǎn)”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注丸趣 TV 網(wǎng)站，丸趣 TV 小編將為大家輸出更多高質(zhì)量的實(shí)用文章！

正文完