【入門編】 jemallocのチューニング – Redis

こんにちは！ Redisのメモリ管理の奥深い世界へようこそ。

今回は、Redisが裏側で使っている「jemalloc（ジェイマロック）」というメモリ管理の仕組みと、実務で絶対に避けて通れない「メモリ断片化（フラグメンテーション）」の対策についてお話しします。

「メモリ管理とかチューニングって、なんだか難しそう……」と思いましたか？
大丈夫です！専門用語をできるだけ使わず、日常の例えを交えながら、優しく、そして本質的なところまで一緒に紐解いていきましょう。ここをクリアすれば、Redisのメモリまわりの動きはバッチリマスターできますよ！

—

1. Redisと「jemalloc」の関係：バックステージの優秀なマネージャー

まず、Redisの最大の特徴を覚えていますか？そう、データをすべて「メインメモリ（RAM）」の上に保持することです。だからこそ、Redisは爆速で動作します。

しかし、ここで一つ疑問が湧きませんか？
「プログラムがデータを記憶したり消したりするとき、メモリってどうやって割り当てられているんだろう？」

ここで登場するのが、メモリ割り当てライブラリ（アロケーター）です。
Redisは、OSが標準で用意しているものではなく、「jemalloc」という特別なアロケーターを標準で採用しています。

🏠 例え話：シェアハウスの部屋割り

想像してください。Redisを「巨大なシェアハウス」、メモリを「その建物全体の部屋」とします。
住人（＝データ）が次々と引っ越してきては、退去していきます。

普通のマネージャー（標準アロケーター）：

空いた部屋があればとりあえず誰かを入れますが、部屋の掃除や組み合わせを考えないので、あちこちに「歯抜けの空き部屋」ができてしまいます。新しい大きな家族（大きなデータ）が入ってきたとき、空き部屋の合計は十分なのに、ひと続きの部屋がないために「入れない！」と断られてしまうことがあります。これがメモリの断片化です。

優秀なマネージャー（jemalloc）：

jemallocは、部屋のサイズを上手にグループ分けし、効率よくパズルを組み合わせるようにスペースを管理します。「ここにこの大きさの荷物を置けば、ムダな隙間ができないな」と計算して配置してくれる、非常に優秀な管理人です。

Redisがこれほど安定して高速に動作するのは、このjemallocという優秀なバックステージのマネージャーが支えているからなのです。

—

2. なぜ「メモリ断片化」が起きるのか？

jemallocがどれほど優秀でも、Redisの「データを頻繁に書き換える・消す」という激しい動きの中では、どうしても「断片化（メモリの隙間だらけの状態）」が少しずつ発生してしまいます。

実務でよくあるシナリオを見てみましょう。
1. Redisに10GB分のデータを保存しました。
2. その後、データの半分（5GB分）を削除しました。
3. OSから見ると、「Redisはまだ10GBのメモリを占有している」状態になっています。

「あれ？ 5GB空いたはずなのに、OS上のメモリ使用量が減らないぞ？」
これが現場でエンジニアが頭を抱える「メモリ断片化の罠」です。データは消えたのに、jemallocが確保した区画の都合上、OSにメモリをきれいにお返しできていない状態なんですね。

—

3. 解決策：環境変数と設定でjemallocを手なずける

この断片化を放置すると、物理メモリが足りなくなってOSが強制終了（OOM Killer発動）させたり、スワップが発生してRedisが急激に遅くなったりします。

ここで私たちが使える、実務で必須の武器がいくつかあります。

① Redisの設定（`redis.conf`）で自動掃除をさせる

Redisには、断片化がひどくなったときに自動で掃除（パージ）をしてくれる機能があります。

断片化が100MB以上、かつ全体の比率が10%を超えたら自動でメモリを整理する
activedefrag yes
active-defrag-ignore-bytes 100mb
active-defrag-threshold-lower 10

※実務では、サーバーの負荷を見ながらこの閾値を微調整します。

② 環境変数でjemallocの挙動をコントロールする

実はjemallocは、プログラムを動かす前の環境変数によって、その性格を微調整できます。
例えば、Linuxの起動スクリプトやsystemdの設定ファイルで、以下のような環境変数を渡すことがあります。

jemallocのパージ（お片付け）アグレッシブさを調整する例
export MALLOC_CONF=”dirty_decay_ms:1000,muzzy_decay_ms:1000″

どういう意味？

「データが消えたあと、使わなくなったメモリの区画をどれくらい早くOSにお返しするか」のタイマー設定です。
ミリ秒単位で指定でき、例えば `1000` と指定すると「使われなくなって1秒経ったら、すぐに掃除してOSに返還してね」とjemallocに指示できます。

これにより、メモリがムダに居座り続けるのを防ぎ、断片化の芽を早めに摘むことができます。

—

4. 現場のシニアからのアドバイス：モニタリングを怠るな

ここまでjemallocと断片化について見てきましたが、最後に一番大切なことをお伝えします。

それは、「自分の目で（数字で）状態を常に見守ること」です。
RedisのCLIから以下のコマンドを打ってみてください。

127.0.0.1:6379> INFO memory
実行結果の抜粋
used_memory: 104857600 (Redisが実際にデータに使っているサイズ / 約100MB)
used_memory_rss: 157286400 (OSから実際に割り当てられているサイズ / 約150MB)
mem_fragmentation_ratio: 1.50 (断片化の倍率)

この `mem_fragmentation_ratio`（断片化率）をチェックしてください。

1.0 〜 1.5 くらい： 正常範囲です。優秀なjemallocがうまくやってくれています。
1.5 を大きく超えている（2.0以上など）： 要注意です！断片化が進行しています。先ほどの自動デフラグ機能を有効にするか、メンテナンス時間にRedisの再起動を検討するサインです。

—

まとめ

Redisは、メモリ管理のプロである「jemalloc」のおかげで高速に動いている。
しかし、データの出し入れを繰り返すと「メモリの断片化（隙間だらけの状態）」が起きる。
環境変数や設定ファイル（`activedefrag`など）を使いこなすことで、この断片化をスマートに抑制できる。
日頃から `INFO memory` で `mem_fragmentation_ratio` を監視することが、プロのエンジニアの第一歩。

メモリ管理の仕組みが分かると、Redisがぐっと身近な存在になり、愛着も湧いてきますよね。
ここをクリアしたあなたなら、もうRedisのメモリまわりで迷うことはありません。自信を持って、実務の現場や開発に活かしてください！