首页 > 数据库技术 > 详细

检查MySQL内存使用情况

时间:2019-01-10 23:49:30      阅读:60      评论:0      收藏:0      [点我收藏+]

标签:present   ive   mar   epo   start   earch   trigger   指标   级别   

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

#启用收集内存指标
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:
另外,我们想要鸟瞰什么吃掉了内存,我们可以获得每个事件更高级别活动的总体报告。

检查MySQL内存使用情况

标签:present   ive   mar   epo   start   earch   trigger   指标   级别   

原文:https://www.cnblogs.com/moss_tan_jun/p/10252904.html

(0)
(0)
   
举报
评论 一句话评论(0
0条  
登录后才能评论!
© 2014 designnerd.net 版权所有 鲁ICP备09046678号-4
打开技术之扣,分享程序人生!
             

鲁公网安备 37021202000002号