【入門編】 jemalloc統計の確認 – Redis

こんにちは！Redisの奥深い世界へようこそ。
あなたが今、「Redisってなんだか速くて便利そうだけど、裏側でメモリをどれくらい食べてるんだろう？」、「なんだかメモリが減らない気がする…」という疑問を持ったなら、それはエンジニアとして非常に鋭い着眼点です。

実は、Redisのメモリ管理の心臓部には「jemalloc（ジェイマロック）」という強力な仕組みが隠されています。
ここをクリアすれば、あなたも立派なRedisマスター。今日は、先輩である私と一緒に、Redisの裏側をのぞき見してみましょう！

—

1. Redisのメモリ管理って、どうなっているの？

まず、例え話をさせてください。

あなたは今、人気の雑貨屋さんを経営しています。お客さんから預かった荷物（データ）を、バックヤード（メモリ）の棚にどんどん置いていくと想像してください。

素朴な管理方法： 荷物を置くたびに「これくらいの大きさの段ボール箱をください」と、その都度お店の外へ買いに行きます。これだと、時間がかかるし、段ボールの隙間が無駄になりますよね。
Redis（jemalloc）のやり方： 最初にごっそりと大きなスペースを確保しておき、その中で「Sサイズ」「Mサイズ」「Lサイズ」のような綺麗に整理された棚を用意します。そして、荷物の大きさに合わせてピタリと収まる棚へ素早く配置していくのです。

この「綺麗に整理された棚（メモリプール）」を管理しているのが、jemallocというメモリの管理人です。
Redisは、OSから直接メモリをもらうのではなく、このjemallocという優秀な管理人に「うまい具合にメモリをやりくりして！」と全権を委任しています。

—

2. `MEMORY STATS` で、管理人の懐をのぞき見する

さて、このjemalloc管理人が、今どれくらいメモリを使っていて、どこにどれだけの余裕があるのか。それを丸裸にする魔法のコマンドが `MEMORY STATS` です。

さっそく、ターミナルを開いてRedisにこのコマンドを打ってみたとしましょう。
（※実際の出力はJSONのような形式でたくさん出てきますが、要点をギュッと絞って解説しますね）

127.0.0.1:6379> MEMORY STATS
1) “peak.allocated” # 今までに記録した「最高潮のメモリ使用量」
2) “10485760” # （例：約10MB）
3) “total.allocated” # 「現在」使っている実際のメモリ量
4) “5242880” # （例：約5MB）
5) “jemalloc.stats.allocated” # jemallocが「実際にデータ用に確保した」サイズ
6) “4900000”
7) “jemalloc.stats.active” # jemallocが「OSからキープしている」総サイズ
8) “8388608” # （例：約8MB）
9) “jemalloc.stats.mapped” # OSと直接やり取りした仮想メモリのサイズ
10) “12582912”

「うわ、数字がいっぱい並んでいて難しそう……」と思いましたか？
大丈夫、ここが今日のハイライトです。一番大切な「3つの数字のパズル」を解いていきましょう。

—

3. ここが本質！「allocated」「active」「mapped」の正体

jemallocの統計データを見る上で、以下の3つの関係性だけは絶対に押さえておいてください。

1. `allocated`（実際にデータが使っている量）

例え：段ボール箱の中に入っている、本当の荷物の量。

2. `active`（管理人が手元にキープしている量）

例え：バックヤードの棚に並んでいる、空き箱も含めたスペースの総量。

3. `mapped`（OSから借りパク…じゃなくて、確保している量）

例え：お店全体として、大家さん（OS）から借りているテナントの広さ。

ここで、鋭いあなたなら気づくはずです。
「あれ？ `active`（8MB）の方が、`allocated`（約5MB）より大きくない？その差の3MBは一体どこへ消えたの？」と。

素晴らしい疑問です！この「差額」こそが、メモリ最適化の鍵を握る「断片化（メモリの隙間）」や「管理人の予備スペース」なのです。

隙間ができる理由（断片化）

例えば、Mサイズの棚に、Sサイズの荷物を入れたとします。そうすると、棚の中にちょっとした「隙間」が生まれますよね。
また、データを急に大量に消去したとき、jemalloc管理人は「いつかまたすぐ荷物が来るかもしれないから、この棚のキープはもう少し持っておこう」と、すぐにOSにスペースを返しません。

この「手元に残しているけど今は使っていないスペース」が大きくなりすぎると、「Redisは少ししかデータを入れていないのに、OSのメモリをめちゃくちゃ消費している！」という現象（メモリ断片化）が起きます。

—

4. 実務でどう活かす？（先輩からのアドバイス）

実務の現場では、この `MEMORY STATS`（あるいは簡易版の `INFO memory`）を監視ツール（PrometheusやDatadogなど）で常時モニタリングします。

もし、以下のような状態を見つけたら赤信号です。

`total.allocated`（データの大きさ）は小さいのに、`jemalloc.stats.active`（キープしている大きさ）が異常に膨れ上がっている。
メモリ使用率のグラフが右肩上がりで、OSの限界値に近づいている。

そんな時は、Redisに備わっている「メモリ断片化の自動解消機能（Active Defragmentation）」を有効にするか、どうしてもダメなら計画的な再起動や、jemallocの特性に合わせたチューニングを行います。

—

まとめ

お疲れ様でした！
今日の話をまとめると、以下のようになります。

Redisのメモリ管理の裏側では、jemallocという優秀な管理人が働いている。
`MEMORY STATS` コマンドを使うことで、その管理人の懐事情（データの量、キープしている量、OSから借りている量）を丸裸にできる。
「データ量」と「キープしている量」のギャップを知ることが、メモリあふれを防ぐプロへの第一歩。

ここをクリアすれば、あなたのRedisに関する解像度は劇的に上がります。実務で「メモリが足りない！」とパニックになった時も、慌てず騒がず `MEMORY STATS` を叩いて原因を冷静に切り分けられるはずです。

明日からも、自信を持ってコードを書いていきましょう。あなたのエンジニアライフを、私はいつも応援しています！