成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

如何解決由觸發(fā)器導(dǎo)致 MySQL 內(nèi)存溢出?

數(shù)據(jù)庫 MySQL
根據(jù)官方的解釋可以了解到,如果有許多大的觸發(fā)器,參數(shù) table_open_cache_instances 的默認(rèn)值可能會造成內(nèi)存使用過多。比如 table_open_cache_instances 設(shè)置為 16,那么表緩存會劃分為 16 個 table instance。當(dāng)并發(fā)訪問大時,最多的情況下一個表的緩存信息會出現(xiàn)在每一個 table instance 里面。

作者:龔唐杰,愛可生 DBA 團(tuán)隊成員,主要負(fù)責(zé) MySQL 技術(shù)支持,擅長 MySQL、PG、國產(chǎn)數(shù)據(jù)庫。

1問題現(xiàn)象

一臺從庫服務(wù)器的內(nèi)存使用率持續(xù)上升,最終導(dǎo)致 MySQL 服務(wù)被 kill 了。

內(nèi)存監(jiān)控視圖如下:

圖片圖片

內(nèi)存使用率 92.76%

從圖中可以看出,在 00:00 左右觸發(fā)了 kill,然后又被 mysqld_safe 進(jìn)程拉起,然后內(nèi)存又會持續(xù)上升。

2排查過程

基本信息

  • 數(shù)據(jù)庫版本:MySQL 5.7.32
  • 操作系統(tǒng)版本:Ubuntu 20.04
  • 主機(jī)配置:8C64GB
  • innodb_buffer_pool_size:8G

由于用戶環(huán)境未打開內(nèi)存相關(guān)的監(jiān)控,所以在 my.cnf 配置文件中配置如下:

performance-schema-instrument = 'memory/% = COUNTED'

打開內(nèi)存監(jiān)控等待運行一段時間后,相關(guān)視圖查詢?nèi)缦拢?/p>

圖片圖片

圖片圖片

從上述截圖可以看到,MySQL 的 buffer pool 大小分配正常,但是 memory/sql/sp_head::main_mem_root 占用了 8GB 內(nèi)存。

查看 源代碼[1] 的介紹:

圖片圖片

sp_head:sp_head represents one instance of a stored program.It might be of any type (stored procedure, function, trigger, event).

根據(jù)源碼的描述可知,sp_head 表示一個存儲程序的實例,該實例可能是存儲過程、函數(shù)、觸發(fā)器或者定時任務(wù)。

查詢當(dāng)前環(huán)境存儲過程與觸發(fā)器數(shù)量:

圖片圖片

圖片圖片

當(dāng)前環(huán)境存在大量的觸發(fā)器與存儲過程。

查詢 MySQL 相關(guān) bug[2],這里面提到一句話:

圖片圖片

Tried to tweak table_open_cache_instances to affect this?

查詢此參數(shù)描述:

圖片圖片

A value of 8 or 16 is recommended on systems that routinely use 16 or more cores. However, if you have many large triggers on your tables that cause a high memory load, the default setting for table_open_cache_instances might lead to excessive memory usage. In that situation, it can be helpful to set table_open_cache_instances to 1 in order to restrict memory usage.

根據(jù)官方的解釋可以了解到,如果有許多大的觸發(fā)器,參數(shù) table_open_cache_instances 的默認(rèn)值可能會造成內(nèi)存使用過多。

比如 table_open_cache_instances 設(shè)置為 16,那么表緩存會劃分為 16 個 table instance。當(dāng)并發(fā)訪問大時,最多的情況下一個表的緩存信息會出現(xiàn)在每一個 table instance

再有每次將表信息放入表緩存時,所有關(guān)聯(lián)的觸發(fā)器都被放入 memory/sql/sp_head::main_mem_root 中,table_open_cache_instances 設(shè)置的越大其所占內(nèi)存也就越大,以及存儲過程也會消耗更多的內(nèi)存,所以導(dǎo)致內(nèi)存一直上升最終導(dǎo)致 OOM。

下面簡單驗證一下觸發(fā)器對內(nèi)存的影響。

當(dāng) table_open_cache_instances 為 8 時:
#清空緩存

mysql> flush tables;
Query OK, 0 rows affected (0.00 sec)

[root@test ~]# cat test.sh
for i in `seq 1 1 8`
do
mysql -uroot -p test -e "select * from test;"
done

[root@test ~]# sh test.sh

mysql> show variables like '%table_open_cache_instances%';
+----------------------------+-------+
| Variable_name | Value |
+----------------------------+-------+
| table_open_cache_instances | 8 |
+----------------------------+-------+
1 row in set (0.00 sec)

mysql> SELECT current_alloc FROM sys.memory_global_by_current_bytes WHERE event_name='memory/sql/sp_head::main_mem_root';
+---------------+
| current_alloc |
+---------------+
| 119.61 KiB |
+---------------+
1 row in set (0.00 sec)

在該表上創(chuàng)建一個觸發(fā)器。

mysql> \d|
mysql> CREATE TRIGGER trigger_test BEFORE INSERT ON test FOR EACH ROW BEGIN SIGNAL SQLSTATE '45000' SET message_text='Very long string. MySQL stores table descriptors in a special memory buffer, calle
'> at holds how many table descriptors MySQL should store in the cache and table_open_cache_instances t
'> hat stores the number of the table cache instances. So with default values of table_open_cache=4000
'> and table_open_cache_instances=16, you will have 16 independent memory buffers that will store 250 t
'> able descriptors each. These table cache instances could be accessed concurrently, allowing DML to u
'> se cached table descriptors without locking each other. If you use only tables, the table cache doe
'> s not require a lot of memory, because descriptors are lightweight, and even if you significantly increased the value of table_open_cache, it would not be so high. For example, 4000 tables will take u
'> p to 4000 x 4K = 16MB in the cache, 100.000 tables will take up to 390MB that is also not quite a hu
'> ge number for this number of open tables. However, if your tables have triggers, it changes the gam
'> e.'; END|
Query OK, 0 rows affected (0.00 sec)

#清空緩存

mysql> flush tables;
Query OK, 0 rows affected (0.00 sec)

然后訪問表,查看緩存。

[root@test ~]# cat test.sh
for i in `seq 1 1 8`
do
mysql -uroot -p test -e "select * from test;"
done

[root@test ~]# sh test.sh

mysql> SELECT current_alloc FROM sys.memory_global_by_current_bytes WHERE event_name='memory/sql/sp_head::main_mem_root';
+---------------+
| current_alloc |
+---------------+
| 438.98 KiB |
+---------------+
1 row in set (0.00 sec)

可以發(fā)現(xiàn) memory/sql/sp_head::main_mem_root 明顯增長較大。如果有很多大的觸發(fā)器,那么所占內(nèi)存就不可忽視(現(xiàn)場環(huán)境觸發(fā)器里面很多是調(diào)用了存儲過程)。

當(dāng) table_open_cache_instances 為 1 時:
mysql> flush tables;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like '%table_open_cache_instances%';
+----------------------------+-------+
| Variable_name | Value |
+----------------------------+-------+
| table_open_cache_instances | 1 |
+----------------------------+-------+
1 row in set (0.00 sec)

SELECT current_alloc FROM sys.memory_global_by_current_bytes WHERE event_name='memory/sql/sp_head::main_mem_root';
+---------------+
| current_alloc |
+---------------+
| 119.61 KiB |
+---------------+
1 row in set (0.00 sec)

mysql> #訪問表

mysql> system sh test.sh

mysql> SELECT current_alloc FROM sys.memory_global_by_current_bytes WHERE event_name='memory/sql/sp_head::main_mem_root';
+---------------+
| current_alloc |
+---------------+
| 159.53 KiB |
+---------------+
1 row in set (0.00 sec)

可以發(fā)現(xiàn) memory/sql/sp_head::main_mem_root 所占內(nèi)存增長較小。

由于大量觸發(fā)器會導(dǎo)致表緩存和 memory/sql/sp_head::main_mem_root 占用更多的內(nèi)存,根據(jù)實際環(huán)境,嘗試把該從庫的 table_open_cache_instances 修改為 1 后觀察情況。

圖片圖片

可以看到內(nèi)存值趨于穩(wěn)定,未再次出現(xiàn)內(nèi)存使用率異常的問題。

3總結(jié)

  1. MySQL 中不推薦使用大量的觸發(fā)器以及復(fù)雜的存儲過程。
  2. table_open_cache_instances 設(shè)置為 1 時,在高并發(fā)下會影響 SQL 的執(zhí)行效率。本案例的從庫并發(fā)量不高,其他場景請根據(jù)實際情況進(jìn)行調(diào)整。
  3. 觸發(fā)器越多會導(dǎo)致 memory/sql/sp_head::main_mem_root 占用的內(nèi)存越大,存儲過程所使用的內(nèi)存也會越大。
  4. 本文只是給出了解決內(nèi)存溢出的一個方向,具體的底層原理請自行探索。

參考資料

[1]sp_head: https://dev.mysql.com/doc/dev/mysql-server/latest/classsp__head.html#details

[2]86821: https://bugs.mysql.com/bug.php?id=86821

本文關(guān)鍵字:#MySQL# #內(nèi)存# #觸發(fā)器# #OOM#

關(guān)于 SQLE

SQLE 是一款全方位的 SQL 質(zhì)量管理平臺,覆蓋開發(fā)至生產(chǎn)環(huán)境的 SQL 審核和管理。支持主流的開源、商業(yè)、國產(chǎn)數(shù)據(jù)庫,為開發(fā)和運維提供流程自動化能力,提升上線效率,提高數(shù)據(jù)質(zhì)量。

責(zé)任編輯:武曉燕 來源: 愛可生開源社區(qū)
相關(guān)推薦

2024-09-09 09:41:03

內(nèi)存溢出golang開發(fā)者

2010-05-18 15:58:39

MySQL觸發(fā)器

2010-10-12 10:10:55

mysql觸發(fā)器

2024-10-24 16:51:08

2021-07-30 10:33:57

MySQL觸發(fā)器數(shù)據(jù)

2010-05-31 18:06:07

MySQL 觸發(fā)器

2010-10-12 10:04:15

MySQL觸發(fā)器

2010-10-12 10:24:58

mysql觸發(fā)器

2011-05-20 14:06:25

Oracle觸發(fā)器

2010-05-26 17:57:44

MySQL 觸發(fā)器

2010-05-18 15:36:44

MySQL觸發(fā)器

2010-10-11 14:52:43

Mysql觸發(fā)器

2013-06-26 16:14:26

Android加載圖片內(nèi)存溢出

2010-10-12 09:41:26

mysql觸發(fā)器

2010-10-12 10:38:29

mysql觸發(fā)器

2009-09-18 14:31:33

CLR觸發(fā)器

2011-03-28 10:05:57

sql觸發(fā)器代碼

2011-04-14 10:53:00

MySQLSQL觸發(fā)器

2010-05-19 09:40:05

MySQL觸發(fā)器

2023-06-11 16:09:49

觸發(fā)器MySQL
點贊
收藏

51CTO技術(shù)棧公眾號

主站蜘蛛池模板: 久久av网站 | 亚洲va欧美va天堂v国产综合 | 国产在线二区 | 国产在线精品一区二区 | 精品毛片在线观看 | 中文一区 | 欧美激情精品久久久久久 | 日本免费在线 | 久久这里只有精品首页 | 亚洲福利一区 | 在线激情视频 | 久久精品性视频 | 免费黄色在线观看 | 国产乱肥老妇国产一区二 | 精品国产18久久久久久二百 | 午夜寂寞影院列表 | 国产精品久久久久久久久久久久久 | 免费毛片网站在线观看 | 中文字幕av第一页 | 久久久精 | 亚洲久久一区 | 国产91在线播放 | 久久成人精品视频 | 国产成人精品999在线观看 | 日日夜夜精品视频 | 久久1区| 中文字幕成人av | 国产精品国产精品国产专区不片 | 日韩精品免费视频 | 亚洲福利一区 | 中文字幕日本一区二区 | 亚洲综合精品 | 伊人中文字幕 | 亚洲精品视频一区 | 一道本不卡视频 | 国产在线成人 | 久久99蜜桃综合影院免费观看 | 国产精品毛片一区二区三区 | 亚洲黄色一级毛片 | 久久精品伊人 | av在线一区二区 |