MySQL內(nèi)存的bug分析

本篇內(nèi)容介紹了“MySQL內(nèi)存的bug分析”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

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

即便如此，這并不意味著我們會(huì)修復(fù)所有的意外情況，即使我們接受這種情況為一個(gè)有效bug。做出這樣的決定的原因之一可能是這個(gè)意外情況雖然很明確是錯(cuò)誤的，但對(duì)于percona產(chǎn)品本身來說確實(shí)一個(gè)產(chǎn)品需求

作為學(xué)習(xí)案例的一個(gè)bug

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

這個(gè)報(bào)告闡述了一種情況，當(dāng)訪問InnoDB的全文索引的時(shí)候會(huì)導(dǎo)致內(nèi)存使用量增長。這種情況出現(xiàn)在一些全文索引的查詢，內(nèi)存會(huì)持續(xù)增長直到達(dá)到最大值，并且很長時(shí)間不會(huì)釋放。

來自Percona工程團(tuán)隊(duì)的Yura Sorokin研究表明，這種情況并不屬于內(nèi)存泄漏范疇。

當(dāng)InnoDB解析一個(gè)全文查詢時(shí)，它會(huì)在fts_query_phrase_search函數(shù)中創(chuàng)建一個(gè)內(nèi)存堆，這個(gè)堆可能增長到80M。另外，這個(gè)過程還會(huì)使用到大量非連續(xù)塊(mem_block_t)進(jìn)而產(chǎn)生的內(nèi)存碎片。

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

然而，free()函數(shù)被調(diào)用時(shí)確實(shí)應(yīng)該釋放內(nèi)存，但不需要將其返回給操作系統(tǒng)。如果內(nèi)存分配器發(fā)現(xiàn)這些內(nèi)存塊馬上還需要被用到，則會(huì)將他們保留住繼續(xù)用于mysqld進(jìn)程。這就解釋了為什么mysqld在完成工作及釋放內(nèi)存都結(jié)束后還會(huì)占用大量?jī)?nèi)存。

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

另一個(gè)改善內(nèi)存管理的因素是cpu內(nèi)核數(shù)量：在測(cè)試中，cpu核數(shù)越多，內(nèi)存返回給操作系統(tǒng)的速度會(huì)越快。這可能是你擁有多個(gè)CPU，而其中一個(gè)可專門用作內(nèi)存分配器釋放內(nèi)存給操作系統(tǒng)。

修復(fù)方法

我們有兩種方法來修復(fù)這個(gè)問題：

1.修改InnoDB全文索引的實(shí)現(xiàn)

2.使用自定義內(nèi)存庫，例如jemalloc

這兩種方法都有各自的優(yōu)缺點(diǎn)。

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

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

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

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

“MySQL內(nèi)存的bug分析”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！