由觸發器導致得 OOM 案例分析過程和解決方式。
作者：龔唐傑，愛可生 DBA 團隊成員，主要負責 MySQL 技術支持，擅長 MySQL、PG、國產數據庫。
愛可生開源社區出品，原創內容未經授權不得隨意使用，轉載請聯繫小編並註明來源。
本文約 1500 字，預計閱讀需要 5 分鐘。
問題現象
一臺從庫服務器的內存使用率持續上升，最終導致 MySQL 服務被 kill 了。
內存監控視圖如下：
從圖中可以看出，在 00:00 左右觸發了 kill，然後又被 mysqld_safe 進程拉起，然後內存又會持續上升。
排查過程
基本信息
- 數據庫版本：MySQL 5.7.32
- 操作系統版本：Ubuntu 20.04
- 主機配置：8C64GB
innodb_buffer_pool_size：8G
由於用戶環境未打開內存相關的監控，所以在 my.cnf 配置文件中配置如下：
performance-schema-instrument = 'memory/% = COUNTED'
打開內存監控等待運行一段時間後，相關視圖查詢如下：
從上述截圖可以看到，MySQL 的 buffer pool 大小分配正常，但是 memory/sql/sp_head::main_mem_root 佔用了 8GB 內存。
查看 源代碼 的介紹：
sp_head：sp_head represents one instance of a stored program.It might be of any type (stored procedure, function, trigger, event).
根據源碼的描述可知，sp_head 表示一個存儲程序的實例，該實例可能是存儲過程、函數、觸發器或者定時任務。
查詢當前環境存儲過程與觸發器數量：
當前環境存在大量的觸發器與存儲過程。
查詢 MySQL 相關 bug，這裏面提到一句話：
Tried to tweak table_open_cache_instances to affect this?
查詢此參數描述：
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.
根據官方的解釋可以瞭解到，如果有許多大的觸發器，參數 table_open_cache_instances 的默認至可能會造成內存使用過多。
比如 table_open_cache_instances 設置爲 16，那麼表緩存會劃分爲 16 個 table instance。當併發訪問大時，最多的情況下一個表的緩存信息會出現在每一個 table instance 裏面。
再由於每次將表信息放入表緩存時，所有關聯的觸發器都被放入 memory/sql/sp_head::main_mem_root 中，table_open_cache_instances 設置的越大其所佔內存也就越大，以及存儲過程也會消耗更多的內存，所以導致內存一直上升最終導致 OOM。
下面簡單驗證一下觸發器對內存的影響。
當 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)
在該表上創建一個觸發器。
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)
可以發現 memory/sql/sp_head::main_mem_root* 明顯增長較大。如果有很多大的觸發器，那麼所佔內存就不可忽視（現場環境觸發器裏面很多是調用了存儲過程）。
當 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)
可以發現 memory/sql/sp_head::main_mem_root 所佔內存增長較小。
由於大量觸發器會導致表緩存和 memory/sql/sp_head::main_mem_root 佔用更多的內存，根據實際環境，嘗試把該從庫的 table_open_cache_instances 修改爲 1 後觀察情況。
可以看到內存值趨於穩定，未再次出現內存使用率異常的問題。
總結
- MySQL 中不推薦使用大量的觸發器以及複雜的存儲過程。
table_open_cache_instances設置爲 1 時，在高併發下會影響 SQL 的執行效率。本案例的從庫併發量不高，其他場景請根據實際情況進行調整。- 觸發器越多會導致 memory/sql/sp_head::main_mem_root 佔用的內存越大，存儲過程所使用的內存也會越大。
- 本文只是給出瞭解決內存溢出的一個方向，具體的底層原理請自行探索。
先清空緩存再訪問表，查看緩存
更多技術文章，請訪問：https://opensource.actionsky.com/
關於 SQLE
SQLE 是一款全方位的 SQL 質量管理平臺，覆蓋開發至生產環境的 SQL 審覈和管理。支持主流的開源、商業、國產數據庫，爲開發和運維提供流程自動化能力，提升上線效率，提高數據質量。