Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Bug Analysis of MySQL memory

2025-03-01 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >

Share

Shulou(Shulou.com)05/31 Report--

This article introduces the relevant knowledge of "bug Analysis of MySQL memory". Many people will encounter such a dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

All customers supported by percona are eligible for bug repair, but they also have different options. For example, vip customers can get the hotfiix version before the software patch is officially released, and advanced customers don't even need to use percona software, and we can push the patch upstream for them. But for percona products, all support levels are entitled to bug fixes.

Even so, this does not mean that we will fix all unexpected situations, even if we accept it as a valid bug. One of the reasons for such a decision may be that although this unexpected situation is clearly wrong, it is indeed a product requirement for the percona product itself.

As a bug of a learning case

A recent good case is that the bug of PS-5312-- can be reproduced upstream and recorded in bugs.mysql.com/95065.

This report describes a situation where access to InnoDB's full-text index can lead to an increase in memory usage. This occurs in some full-text indexed queries, where memory continues to grow until it reaches its maximum and will not be released for a long time.

Yura Sorokin research from the Percona engineering team shows that this situation does not fall into the category of memory leaks.

When InnoDB parses a full-text query, it creates a memory heap in the fts_query_phrase_search function that may grow to 80m. In addition, this process uses a large number of memory fragments resulting from discontiguous blocks (mem_block_t).

At the function exit, these memory heaps are released. InnoDB does this for each block it allocates. At the end of function execution, a free () operation in a memory allocator library, such as malloc or jemalloc, is called. From the point of view of MySQL itself, this is all fine, there is no memory leak.

However, it is true that the free () function should free memory when called, but it does not need to be returned to the operating system. If the memory allocator finds that these memory blocks need to be used soon, they will be reserved for use in the mysqld process. This explains why mysqld takes up a lot of memory after the work is done and the memory is freed.

This is not a big problem in actual production and should not cause any accidents according to reason. But if you need to return memory to the operating system faster, you can try an unconventional memory allocator, like jemallolc. It has been proved to solve the problem of PS-5312.

Another factor that improves memory management is the number of cpu cores: in tests, the more cpu cores, the faster the memory will be returned to the operating system. This may be because you have multiple CPU, and one of them can be used specifically as a memory allocator to release memory to the operating system.

Repair method

We have two ways to fix this problem:

1. Modify the implementation of InnoDB full-text index

two。 Use custom memory libraries, such as jemalloc

Both methods have their own advantages and disadvantages.

Method 1 means that we introduce the risk of incompatibility with the upstream of the software, which may lead to unknown errors in the new version. It also means completely rewriting part of the code for InnoDB full-text indexing, which is risky in the version of GA that users use.

Method 2 means that we may hit bug in some jemalloc libraries designed for performance but not the safest memory allocation.

So we have to choose one of these two imperfect methods.

Given that method one may lead to incompatibility between percona services and upstream, we prefer to use method two to solve the problem and look forward to upstream fixing the bug.

This is the end of "bug Analysis of MySQL memory". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Database

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report