MySQL 5.7を使っているシステムで週単位で徐々にメモリ使用量が増え続けているという現象に遭遇したのでこれなんでだろうと思って調べてみたメモ
MySQLのメモリ管理
MySQLがどのようにメモリを使用しているかの話。innodb_buffer_pool_sizeにデータ載せて色々やるよという感じ。innodb_buffer_pool_sizeだけ気にしておけばよいかと思いきやkey_buffer_size、 tokudb_cache_size、 query_cache_size、 table_cache、 table_open_cacheについても考える必要があるらしい。innodb_buffer_poolとは別のところでメモリの確保/開放が行われる領域がある。ちなみにinnodb_buffer_pool_sizeは起動時に領域を確保するとのことなのでVSZは起動するタイミングで上がるみたいな感じなのだろうか
MySQLが使いうる最大のメモリーサイズ
いい感じの確認クエリが上記の記事に出ていた。innodb_buffer_pool_sizeやらスレッドバッファなどを足し合わせた数値を出してくれるもの。じゃあこれで出た結果が最大サイズだ！とはそんな簡単にはいかないのが現状の問題。上記で出た計算で例えば3GBと出てもLinux上でpsとかで見ると4GBとかがRSSに出ていたりしてしまっているという現状。
なぜ計算した値よりも多くのメモリを必要とするかの推測
MySQLくらい大きなOSSになるとメモリアロケータあたりも自前実装なんだろうなと思ったらどうやら今は違うらしくOSの方のものを使うとのことだった。となるとGlibc mallocが登場してくる。
You can control whether InnoDB uses its own memory allocator or an allocator of the operating system, by setting the value of the system configuration parameter innodb_use_sys_malloc in the MySQL option file (my.cnf or my.ini)
Glibc mallocで有名な話としてfree()を呼び出してもプロセスの管理下から消えるだけで実際にメモリをOSに戻すわけではないというものがある。MySQL的にはfreeを呼び出した時点でメモリは返されたものとして認識するがメモリアロケータが実は返していない(再利用性の観点から)状態になる。(こんな感じでこの話題についてのやりとりなんかもあったりした)。OSに返さないメリットは次回プロセスがメモリ割り当てを要求したとき、malloc()はカーネルへの要求をせずにメモリを返せるので高速だよねというからくり。
innodb_buffer_poolは起動時に予約した領域を使うとのことなのでここで起きうるのは一時テーブルやコネクション用スレッドの生成/破棄処理あたりで発生するであろうfree()呼び出し。の先でMySQLが管理してないメモリが生まれて使用量が増え続けるんじゃないかという予想。再利用されにくい感じの使い方を続けていくことで解放されないメモリが溜まり続けてこういう現象が起きてるんじゃないかなと思う(が実際は全くわからない...)
MySQLがメモリが使っているメモリが増え続けてる問題は結構色々なところで出ていて多くの記事ではGoogleが出しているgoogle/tcmallocを使っていたりjemalloc/jemallocなどを使用して回避したというものが多そうであった。メモリ割り当てに使用するライブラリは起動オプションで変更可能
どうすると良いのだろう
メモリアロケータを変えて再起動するのが良さそうだなと思った。公式でも結構話題になってるしそれでいけそう。あとはスレッドバッファが解放されずにメモリアロケータが溜め込んでいるならスレッドキャッシュを0とかにして接続のたびにclone(2)してスレッド生成するとかでもいいじゃない感と思った(パフォーマンス面で微妙かもだけど...)
In short, this has nothing to do with our software and is not a bug at all ......
この手の問い合わせが大量にあるの大変そうだなぁと思ったり...関係ないとはいえね...
