檢查MySQL內存使用狀況

=========================================================================================================================

#啓用收集內存指標
UPDATE setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'memory/%';

#查看運行sys schema裏面內存分配的報告
select event_name,current_alloc,high_alloc from sys.memory_global_by_current_bytes where current_count > 0;

#得到每一個事件更高級別活動的整體報告
select substring_index(substring_index(event_name,'/',2),'/',-1) as event_type,
round(sum(current_number_of_bytes_used) / 1024/1024, 2) as MB_CURRENTLY_USED
from performance_schema.memory_summary_global_by_event_name
group by event_type
having
mb_currently_used >0

=========================================================================================================================

如今咱們能夠檢查MySQL內部的東西來尋找潛在的MySQL內存泄漏狀況:
MySQL在不少地方分配內存，尤爲：

1. 表緩存

2. Performance_schema(運行:show engine performance_schema status 而後看最後一行)，這可能在系統RAM比較少(1G或更少)時的可能緣由。

3. InnoDB(運行show engine innodb status 檢查 buffer pool部分,爲buffer pool及相關緩存分配的內存)

4. 內存中的臨時表(查看全部內存表:select * from information_schema.tables where engine='MEMORY')

5. 預處理語句，當他們沒有被釋放時(經過運行show global status like 'Com_prepare_sql'和show global status like 'Com_dealloc_sql'來檢查經過deallocate命令釋放的預處理語句)

The good news is: starting with MySQL 5.7 we have memory allocation in performance_schema. Here is how we can use it.
好消息是，從5.7開始咱們能夠經過performance_schema查看內存的分配狀況。下面就展現如何使用它：

• First, we need to enable collecting memory metrics. Run:

UPDATE setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'memory/%';

• Run the report from sys schema:

select event_name, current_alloc, high_alloc from sys.memory_global_by_current_bytes where current_count > 0;

• Usually this will give you the place in code when memory is allocated. It is usually self-explanatory. In some cases we can search for bugs or we might need to check the MySQL source code.

• 首先，咱們須要啓用收集內存指標，運行以下語句：

UPDATE setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'memory/%';

• 運行sys schema裏面的報告

select event_name,current_alloc,high_alloc from sys.memory_global_by_current_bytes where current_count > 0;

• 一般，這將在分配內存時爲你提供代碼，它一般是不言自明的。在某些狀況下，咱們能夠搜索錯誤，或者咱們可能須要檢查MySQL源代碼。

For example, for the bug where memory was over-allocated in triggers (https://bugs.mysql.com/bug.php?id=86821) the select shows:

 

例如，有一個過分爲觸發器分配內存的bug：

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

查詢的顯示以下：

 

The largest chunk of RAM is usually the buffer pool but ~3G in stored procedures seems to be too high.
分配最大一塊內存一般是buffer pool，可是約3G的存儲過程彷佛有點過高了.

According to the MySQL source code documentation, sp_head represents one instance of a stored program which might be of any type (stored procedure, function, trigger, event). In the above case we have a potential memory leak.
根據MySQL source code documentation,sp_head表示存儲程序裏面的一個實例(好比存儲過程、函數、觸發器，及事件)。在上面的例子，咱們有潛在的內存泄漏的風險。

In addition we can get a total report for each higher level event if we want to see from the birds eye what is eating memory:另外，咱們想要鳥瞰什麼吃掉了內存，咱們能夠得到每一個事件更高級別活動的整體報告。