检查mysql内存使用率_检查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在很多地方分配内存，尤其：

表缓存

Performance_schema(运行:show engine performance_schema status 然后看最后一行)，这可能在系统RAM比较少(1G或更少)时的可能原因。

InnoDB(运行show engine innodb status 检查 buffer pool部分,为buffer pool及相关缓存分配的内存)

内存中的临时表(查看所有内存表:select * from information_schema.tables where engine='MEMORY')

预处理语句，当他们没有被释放时(通过运行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:

另外，我们想要鸟瞰什么吃掉了内存，我们可以获得每个事件更高级别活动的总体报告。