MySQL內存的bug分析

本篇內容介紹了“MySQL內存的bug分析”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

所有percona所支持的客戶都有獲得bug修復的資格，但他們也有不同的選擇。比如，vip客戶在軟件補丁正式發布之前就可以獲得hotfiix版本，高級客戶甚至不需要使用percona的軟件，我們也可以為他們把補丁推到上游。但對于與percona產品來說，所有支持等級都有權得到bug修復。

即便如此，這并不意味著我們會修復所有的意外情況，即使我們接受這種情況為一個有效bug。做出這樣的決定的原因之一可能是這個意外情況雖然很明確是錯誤的，但對于percona產品本身來說確實一個產品需求

作為學習案例的一個bug

最近一個很好的案例是 PS-5312<鏈接3>——這個bug可在上游復現并被記錄在bugs.mysql.com/95065<鏈接4>。

這個報告闡述了一種情況，當訪問InnoDB的全文索引的時候會導致內存使用量增長。這種情況出現在一些全文索引的查詢，內存會持續增長直到達到最大值，并且很長時間不會釋放。

來自Percona工程團隊的Yura Sorokin研究表明，這種情況并不屬于內存泄漏范疇。

當InnoDB解析一個全文查詢時，它會在fts_query_phrase_search函數中創建一個內存堆，這個堆可能增長到80M。另外，這個過程還會使用到大量非連續塊(mem_block_t)進而產生的內存碎片。

在函數出口，這些內存堆會被釋放。InnoDB會為其分配的每一個塊做這個操作。在函數執行結束時，調用一個內存分配器庫中的free()操作，比如malloc或者jemalloc。從MySQL本身來看，這都是沒問題的，不存在內存泄漏。

然而，free()函數被調用時確實應該釋放內存，但不需要將其返回給操作系統。如果內存分配器發現這些內存塊馬上還需要被用到，則會將他們保留住繼續用于mysqld進程。這就解釋了為什么mysqld在完成工作及釋放內存都結束后還會占用大量內存。

這個在實際生產中并不是一個大問題，按道理不應該造成任何事故。但是如果你需要更快地將內存返回給操作系統，你可以嘗試非傳統的內存分配器，類似jemallolc。它被證明可以解決PS-5312<鏈接5>的問題。

另一個改善內存管理的因素是cpu內核數量：在測試中，cpu核數越多，內存返回給操作系統的速度會越快。這可能是你擁有多個CPU，而其中一個可專門用作內存分配器釋放內存給操作系統。

修復方法

我們有兩種方法來修復這個問題：

1.修改InnoDB全文索引的實現

2.使用自定義內存庫，例如jemalloc

這兩種方法都有各自的優缺點。

方法1 意味著我們引入了與軟件上游不兼容性的風險，這可能會導致新版本中出現未知的錯誤。也意味著徹底重寫InnoDB全文索引部分代碼，這在用戶們使用的GA版本中是有風險的。

方法2 則意味著我們可能會命中一些jemalloc庫中專門為性能設計但不是最安全的內存分配的bug。

因此我們不得不在這兩個并不完美的方法中選擇一個。

鑒于方法一可能導致percona服務與上游的不兼容，我們更傾向于用方法二來解決問題，并期待著上游修復這個bug。

“MySQL內存的bug分析”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！