2025/04/12 22:15 Battle of the Mallocators
やあ、ロボ子。今日のITニュースは、RocksDBのメモリ管理についてじゃ。
RocksDBですね。どのような内容でしょうか？
RocksDBを使うときは、メモリ不足（OOM）を避けるために、glibc mallocじゃなくてjemallocかtcmallocを使うのがおすすめらしいぞ。
glibc mallocだと何か問題があるんですか？
RocksDBは、データを読み込むときにmallocをたくさん呼んで、不要になったらfreeするから、アロケータに負担がかかりやすいんじゃ。glibc mallocだと、ブロックのキャッシュ期間が長くなって、予想以上にメモリを食っちゃうらしい。
なるほど。jemallocとtcmallocはその点、優れているんですね。
そうじゃ。jemallocとtcmallocは、メモリを無駄遣いせずに、このアロケーションパターンに対応できるってわけじゃ。
記事によると、InnoDBでは事情が異なるようですね。
InnoDBは起動時にバッファプール用に大きなメモリを確保するから、RocksDBみたいに頻繁にmalloc/freeを繰り返さないんじゃ。だから、同じ問題は起こりにくい。
MySQLの専門家であるDimitri Kravtchukさんの主張も紹介されていますね。
Dimitriさんは、InnoDBとjemallocを使うとメモリが大きくなりすぎると言ってるみたいじゃが、この記事の筆者は再現できなかったらしいぞ。
VSZ（仮想メモリサイズ）が大きくなるのはjemallocの特性によるもの、と。
そういうことじゃ。問題ないって言ってるぞ。RSS（実メモリ使用量）はtcmallocと同程度らしい。
実際にOOMが発生したケースも紹介されていますね。
glibc mallocを使ったとき、RocksDBのバッファプールが50GBで、128GBのRAMを積んだサーバーでOOMになったらしい。バッファプールを小さくすれば回避できたかもじゃが。
MyRocksでは通常、jemallocと100GBのバッファプールを使用しているんですね。
ピーク時のRSSについても比較があるぞ。InnoDBだと、どのアロケータを使ってもほぼ同じくらいじゃが、MyRocksだとjemallocが一番小さくて、glibc mallocがめちゃくちゃ大きくなる。
MyRocksでglibc mallocを使うと、バッファプールの3.62倍もメモリを消費するんですね。
そういうことじゃ。パフォーマンスはどうじゃろう？
jemallocとtcmallocを使った方が、glibc mallocより少しQPS（1秒あたりのクエリ数）が良いみたいです。
InnoDBだと2.5%から3.5%くらい、MyRocksだと3%から5.1%くらいQPSが向上するみたいじゃな。
マイクロベンチマークの結果も興味深いですね。
細かい条件によって、jemallocとtcmallocの優劣が入れ替わるみたいじゃな。でも、全体的にはjemallocの方が良い結果が出てるみたいじゃ。
今回の記事から、RocksDBを使う際はjemallocかtcmallocを検討することが重要だとわかりました。
そういうことじゃ。メモリ管理をしっかりして、快適なデータベースライフを送るのじゃ！
はい、博士！ ちなみに、博士の部屋のメモリもそろそろ整理が必要かもしれませんね。
む、うるさいぞ！ 私の部屋は最適化されているんじゃ！ たぶん…。
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。