This story is about a bug。
一切percona所支撑的客户都有取得bug修正的资历，但他们也有不同的选择。比方，vip客户在软件补丁正式发布之前就能够取得hotfiix版别，高档客户乃至不需要运用percona的软件，咱们也能够为他们把补丁推到上游。但关于与percona产品来说，一切支撑等级都有权得到bug修正。
即便如此，这并不意味着咱们会修正一切的意外状况，即使咱们接受这种状况为一个有效bug。做出这样的决定的原因之一可能是这个意外状况尽管很明确是过错的，但关于percona产品自身来说确实一个产品需求
A good recent example of such a case is PS-5312 – the bug is repeatable with upstream and reported at 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.
Yura Sorokin from the Percona Engineering Team investigated if this is a memory leak and found that it is not.
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.
fts_query_phrase_search函数中创立一个内存堆，这个堆可能增加到80M。另外，这个过程还会运用到很多非连续块(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.
free()操作，比方jemalloc。从MySQL自身来看，这都是没问题的，不存在内存走漏。
然而，free()函数被调用时确实应该开释内存，但不需要将其回来给操作系统。假如内存分配器发现这些内存块马上还需要被用到，则会将他们保留住持续用于mysqld进程。这就解说了为什么mysqld在完成工作及开释内存都结束后还会占用很多内存。
这个在实践生产中并不是一个大问题，按道理不应该造成任何事端。可是假如你需要更快地将内存回来给操作系统，你能够测验非传统的内存分配器，相似Another factor which improves memory management is the number of CPU cores: the more we used for the test, the faster the memory was returned to the operating system. This, probably, can be explained by the fact that if you have multiple CPUs, then the memory allocator can dedicate one of them just for releasing memory to the operating system.
The very first implementation of InnoDB full text indexes introduced this flaw. As our engineer Yura Sorokin found:
The very first 5.6 commit which introduces Full Text Search Functionality for InnoDB WL#5538: InnoDB Full-Text Search Support – https://dev.mysql.com/worklog/task/?id=5538
Implement WL #5538 InnoDB Full-Text Search Support, merge – https://github.com/mysql/mysql-server/commit/b6169e2d944 – also has this problem.
Yura Sorokin所发现的一样，下面两点论述了InnoDB全文索引的早期完成引进了这个缺点：
修正办法
Change implementation of InnoDB fulltext index
Use custom memory library like jemalloc
咱们有两种办法来修正这个问题：
2.运用自定义内存库，例如A8站源码交易平台这两种办法都有各自的优缺点。
办法1 意味着咱们引进了与软件上游不兼容性的危险，这可能会导致新版别中出现未知的过错。也意味着完全重写InnoDB全文索引部分代码，这在用户们运用的GA版别中是有危险的。
办法2 则意味着咱们可能会命中一些jemalloc库中专门为性能设计但不是最安全的内存分配的bug。A8站源码交易平台
Since option 1 may lead to a situation when Percona Server will be incompatible with upstream, we prefer option 2and look forward for the upstream fix of this bug.
鉴于办法一可能导致percona服务与上游的不兼容，咱们更倾向于用办法二来解决问题，并期待着上游修正这个bug。
If you are seeing a high memory usage by the mysqld process, it is not always a symptom of a memory leak. You can use memory instrumentation in Performance Schema to find out how allocated memory is used. Try alternative memory libraries for better processing of allocations and freeing of memory. Search the user manual for LD_PRELOADto find out how to set it up at these pages here and here.
<p font-size:16px;color:#4d4d4d;background-color:#ffffff;"="" style="word-wrap: break-word; font-family: "sans serif", tahoma, verdana, helvetica; font-size: 12px; white-space: normal;">
