MySQL运行内存不足时应采取的措施

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

I hope those simple steps can help troubleshoot MySQL crashes due to running out of memory.
我希望这些简单的步骤可以帮助解决由于内存溢出导致的MySQL崩溃问题。

MySQL运行内存不足时应采取的措施

标签：spec   表示   Plan   ssr   too   tor   comm   post   tail