最近大家都在讨论2022年01月08日整理发布：闲谈MySQL内存管理内存分配器和操作系统相关的事情，对此小编也是非常的感应兴趣，那么这件事具体又是怎么回事呢？下面就是小编搜索到的关于2022年01月08日整理发布：闲谈MySQL内存管理内存分配器和操作系统事件的相关信息，我们一起来看看吧！

我们来聊聊MySQL内存管理，内存分配器，操作系统。相信朋友们也应该密切关注这个话题。现在给朋友们聊一聊MySQL内存管理、内存分配器、操作系统。边肖还收集了关于MySQL内存管理、内存分配器和操作系统聊天的相关信息。我希望你看到后会喜欢。

推荐(免费):mysql视频教程

(资料图片)

当用户遇到任何软件(包括MySQL)的内存问题时，我们的第一反应就是内存泄漏。正如本文所示，情况并非总是如此。

本文描述了一个关于内存的错误。

所有Percona支持客户都有资格获得错误修复，但他们的选择各不相同。例如，对于带有补丁的软件的公开发布，高级1客户可以获得热修复构建优先权。link 2高级客户甚至不必使用。Percona软件：我们可能会为他们将补丁移植到上游。但是对于Percona产品，所有支持级别都有权进行修复。

percona支持的所有客户都有资格获得错误修复，但他们也有不同的选择。例如，vip客户可以在软件补丁正式发布之前获得hotfiix版本。高级客户甚至不需要使用percona的软件。我们也可以为他们把补丁往上游推。但是对于带有percona的产品，所有支持级别都有权修复错误。

即便如此，这并不意味着我们将修复每一个意想不到的行为，即使我们接受该行为是一个有效的bug。做出这一决定的原因之一可能是，尽管Percona产品的行为显然是错误的，但这仍然是一个功能请求。

即使如此，这并不意味着我们将修复所有意外情况，即使我们接受这种情况是一个有效的bug。做出这一决定的原因之一可能是，虽然这种意想不到的情况显然是错误的，但确实是对percona产品本身的产品需求。

作为一个学习案例的bug

最近的一个很好的例子是PS-5312，这种错误在上游是可重复的，并在bugs.mysql.com/95065报告

最近一个很好的案例是PS-5312链接——。这个bug可以在上游复制，并记录在bugs.mysql.com/95065链接4中。

这报告了访问InnoDB全文索引导致内存使用量增长的情况。当有人查询全文索引时，它开始增长，直到达到最大值，并且很长一段时间都没有释放。

此报告描述了访问InnoDB全文索引时内存使用增加的情况。当某些全文索引的查询内存将继续增长，直到达到最大值，并且长时间不会释放时，就会出现这种情况。

Percona工程团队的Yura Sorokin调查了这是否是内存泄漏，发现不是。

Percona工程团队Yura Sorokin的研究表明，这种情况不属于内存泄漏的范畴。

当InnoDB解析全文查询时，它会在函数fts _ query _短语_search中创建一个内存堆。这个堆可能会增长到80MB。此外，它还有大量的块(mem_block_t)

当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本身来看这都是没问题的不存在内存泄漏。

However while free should release memory when called, it is not required to return it back to the operating system. If the memory allocator decides that the same memory blocks will be required soon, it may still keep them for the mysqld process. This explains why you might see that mysqld still uses a lot of memory after the job is finished and all de-allocations are done.

然而free函数被调用时确实应该释放内存但不需要将其返回给操作系统。如果内存分配器发现这些内存块马上还需要被用到则会将他们保留住继续用于mysqld进程。这就解释了为什么mysqld在完成工作及释放内存都结束后还会占用大量内存。

This in practice is not a big issue and should not cause any harm. But if you need the memory to be returned to the operating system quicker, you could try alternative memory allocators, such as jemalloc. The latter was proven to solve the issue with PS-5312.

这个在实际生产中并不是一个大问题按道理不应该造成任何事故。但是如果你需要更快地将内存返回给操作系统你可以尝试非传统的内存分配器类似jemallolc。它被证明可以解决PS-5312<链接5>的问题。

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.

另一个改善内存管理的因素是cpu内核数量：在测试中cpu核数越多内存返回给操作系统的速度会越快。这可能是你拥有多个CPU而其中一个可专门用作内存分配器释放内存给操作系统。

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全文索引的早期实现引入了这个缺陷：

5.6版本MySQL最早对InnoDB WL全文索引功能引入的介绍：#5538: InnoDB全文搜索支持 – https://dev.mysql.com/worklog/task/?id=5538

实现WL #5538 InnoDB全文搜索支持与合并 - https://github.com/mysql/mysql-server/commit/b6169e2d944 - 也存在同样的问题问题

修复方法

We have a few options to fix this:

Change implementation of InnoDB fulltext index

Use custom memory library like jemalloc

Both have their advantages and disadvantages.

我们有两种方法来修复这个问题：

1.修改InnoDB全文索引的实现

2.使用自定义内存库例如jemalloc

这两种方法都有各自的优缺点。

Option 1 means we are introducing an incompatibility with upstream, which may lead to strange bugs in future versions. This also means a full rewrite of the InnoDB fulltext code which is always risky in GA versions, used by our customers.

方法1 意味着我们引入了与软件上游不兼容性的风险这可能会导致新版本中出现未知的错误。也意味着彻底重写InnoDB全文索引部分代码这在用户们使用的GA版本中是有风险的。

Option 2 means we may hit flaws in the jemalloc<链接5> library which is designed for performance and not for the safest memory allocation.

方法2 则意味着我们可能会命中一些jemalloc库中专门为性能设计但不是最安全的内存分配的bug。

So we have to choose between these two not ideal solutions.

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.

如果发现mysqld进程占用内存很高并不代表一定是内存泄漏。我们可以在Performance Schema中使用内存检测来了解进程是如何使用已分配的内存。也可以尝试替换内存库来更好地处理内存分配与释放。关于LD_RELOAD如何配置请查阅MySQL用户手册对应页面 mysqld-safe<链接6>和using-system<链接7>。

更多编程相关知识请访问：编程教学！！

以上就是闲谈 MySQL内存管理内存分配器和操作系统的详细内容！

来源：php中文网