MySQL内存管理，内存分配器和操作系统
154 浏览量
2020-12-14
19:37:56
上传
评论
收藏 179KB PDF 举报
MySQL内存管理，内存分配器和操作系统内存管理，内存分配器和操作系统
导读
作者：Sveta Smirnova
翻译：郑志江
校对：徐晨亮
原文 ：MySQL Memory Management, Memory Allocators and Operating System
本文涉及链接在文末展示本文涉及链接在文末展示
When users experience memory usage issues with any software, including MySQL®, their first response is to
think that it’s a symptom of a memory leak. As this story will show, this is not always the case.
This story is about a bug
当用户使用任何软件(包括MySQL)碰到内存问题时，我们第一反应就是内存泄漏。正如这篇文章所示，其实并不总
是这样。
这篇文章阐述一个关于内存的bug。
All Percona Support customers are eligible for bug fixes, but their options vary. For example, Advanced+
customers are offered a HotFix build prior to the public release of software with the patch. Premium customers
do not even have to use Percona software: we may port our patches to upstream for them. But for Percona
products all Support levels have the right to have a fix.
所有percona所支持的客户都有获得bug修复的资格，但他们也有不同的选择。比如，vip客户在软件补丁正式发布
之前就可以获得hotfiix版本，高级客户甚至不需要使用percona的软件，我们也可以为他们把补丁推到上游。但对
于与percona产品来说，所有支持等级都有权得到bug修复。
Even so, this does not mean we will fix every unexpected behavior, even if we accept that behavior to be a valid
bug. One of the reasons for such a decision might be that while the behavior is clearly wrong for Percona
products, this is still a feature request.
即便如此，这并不意味着我们会修复所有的意外情况，即使我们接受这种情况为一个有效bug。做出这样的决定的
原因之一可能是这个意外情况虽然很明确是错误的，但对于percona产品本身来说确实一个产品需求
作为学习案例的一个bug
A good recent example of such a case is PS-5312 – the bug is repeatable with upstream and reported
at bugs.mysql.com/95065
最近一个很好的案例是 PS-5312——这个bug可在上游复现并被记录在bugs.mysql.com/95065。
This reports a situation whereby access to InnoDB fulltext indexes leads to growth in memory usage. It starts
when someone queries a fulltext index, grows until a maximum, and is not freed for quite a long time.
这个报告阐述了一种情况，当访问InnoDB的全文索引的时候会导致内存使用量增长。这种情况出现在一些全文索
引的查询，内存会持续增长直到达到最大值，并且很长时间不会释放。
Yura Sorokin from the Percona Engineering Team investigated if this is a memory leak and found that it is not.
来自Percona工程团队的Yura Sorokin研究表明，这种情况并不属于内存泄漏范畴。
When InnoDB resolves a fulltext query, it creates a memory heap in the function fts_query_phrase_search This
heap may grow up to 80MB. Additionally, it has a big number of blocks ( mem_block_t ) which are not always
used continuously and this, in turn, leads to memory fragmentation.
当InnoDB解析一个全文查询时，它会在fts_query_phrase_search函数中创建一个内存堆，这个堆可能增长到80M。另
外，这个过程还会使用到大量非连续块(mem_block_t)进而产生的内存碎片。
In the function exit , the memory heap is freed. InnoDB does this for each of the allocated blocks. At the end of
the function, it calls free() which belongs to one of the memory allocator libraries, such as malloc or jemalloc.
From the mysqld point of view, everything is done correctly: there is no memory leak.
在函数出口，这些内存堆会被释放。InnoDB会为其分配的每一个块做这个操作。在函数执行结束时，调用一个内
存分配器库中的free()操作，比如malloc或者jemalloc。从MySQL本身来看，这都是没问题的，不存在内存泄漏。
资源评论
