【実務・中級編】 jemalloc統計の確認 – Redis

現場で使えるRedis超最適化：jemallocの腹の内を覗き、メモリ断片化を制す

おい、設計レビューを始めるぞ。

今、お前たちが組もうとしているRedisのデータ構造、本当にメモリ効率を突き詰めているか？「とりあえず文字列で突っ込んでおけば動く」なんて甘い考えで本番稼働させたら、数ヶ月後にメモリ使用量が右肩上がりになり、OSのOOM Killerにプロセスを屠られて夜中に叩き起こされることになる。

Redisのメモリ管理の真実を語ろう。Redis自体のデータ構造の綺麗さだけを語るエンジニアは二流だ。Redisの下回りを支えるアロケータ「jemalloc」の挙動を支配して初めて、真のRedis使いと言える。

今回は、`MEMORY STATS`コマンドを駆使してjemallocの統計情報を丸裸にし、プロダクション環境で即座に使える堅牢なメモリ設計の極意を伝授する。

—

1. なぜRedisのメモリ管理において「jemalloc」を知るべきなのか？

Redisは、デフォルトで`libc`のmallocではなく、Facebookが開発した汎用メモリ allocator である `jemalloc` を採用してビルドされている。

なぜか？ `libc`のmallocは、マルチスレッド環境や頻繁なフラグメント（断片化）が発生するワークロードにおいて、メモリの断片化（Fragmentation）を引き起こしやすく、OSにメモリを返却する挙動が非効率だからだ。

jemallocは、メモリをサイズクラス（Size Classes）ごとに「チャンク」や「アリーナ」という単位で精緻に管理し、効率よく再利用する。しかし、どれほど優秀なアロケータであっても、アプリケーション側のデータの持ち方（キーのライフサイクル、削除の頻度、巨大なHashやZSetの更新パターン）が悪ければ、内部断片化や外部断片化は容赦なく発生する。

ここで、Redisの `MEMORY STATS` の出番だ。

—

2. `MEMORY STATS` コマンドで何が見えるのか？

まずは、実際にRedisのCLIからこのコマンドを叩いてみる感覚を養おう。出力されるJSONライクなネスト構造の中から、jemalloc由来の重要指標をピックアップして解説する。

127.0.0.1:6379> MEMORY STATS

実行すると、次のような統計情報の嵐が返ってくる（一部抜粋・要約）。

1) “peak.allocated”
# Redisが起動して以来、消費したメモリの「ピーク値」
# キャパシティプランニングの生命線。

1073741824 (1GB)

2) “total.allocated”
# 現在、Redisがデータ格納のために直接割り当てているメモリ量

536870912 (512MB)

3) “startup.allocated”
# 起動直後、設定ファイルを読み込んだ直後のベースラインメモリ

10485760 (10MB)

4) “replication.backlog”
# レプリケーション用のバックログバッファサイズ

1048576

5) “clients.slaves” / “clients.normal”
# 接続中のクライアントバッファが消費しているメモリ

2097152

6) “jemalloc.metadata”
# 【最重要】jemalloc自身が管理メタデータのために消費しているメモリ

15728640 (約15MB)

7) “jemalloc.allocated”
# 【最重要】jemallocがアロケートした総バイト数

550000000

8) “jemalloc.active”
# 【最重要】jemallocがOSから「確保済み（Active）」としている物理メモリの総量

600000000

9) “jemalloc.mapped”
# jemallocが mmap() を通じてOSから直接マッピングした仮想メモリ領域のサイズ

640000000

注目すべき3つの指標（jemalloc三兄弟）

コードレビューの際、私が必ずチェックするのが以下の3つの値のバランスだ。

1. `jemalloc.allocated`: Redisのデータが実際に必要としている正味のサイズ。
2. `jemalloc.active`: jemallocのチャンクプール内に保持されており、いつでも使える（あるいは使われている）サイズ。
3. `used_memory` (INFO memory等で確認できる値): Redisが認識している総メモリ。

この `active` と `allocated` の差分を見てほしい。
`active` が `allocated` に比べて異常に大きい場合、それは「メモリの断片化（Fragmentation）」が起きた証拠だ。

—

3. 悪夢の「メモリ断片化」：なぜ起こり、どう検知するか？

例えば、次のようなアンチパターンを考えてみてほしい。

数MBある巨大なJSON文字列（String）を頻繁に更新・削除する。
有効期限（TTL）がバラバラの膨大なキーが、一斉に期限切れを迎えて消滅する。

jemallocは賢いので、解放されたメモリ領域を再利用しようとするが、サイズクラスの不一致や、OSのページ単位（4KBや巨大ページの場合は2MB）の制約により、「プロセスとしてはOSにメモリを返せていないが、内部の空きスロットが散らばっていて新しいデータが入らない」状態に陥る。

ここで `INFO memory` コマンドに出てくる `mem_fragmentation_ratio` の出番だ。

$$\text{mem\_fragmentation\_ratio} = \frac{\text{used\_memory\_rss} \text{ (OSがプロセスに割り当てている物理メモリ)}}{\text{used\_memory} \text{ (Redisが論理的に使っているメモリ)}}$$

比率が 1.0 未満の場合: メモリがスワップアウトしている危険信号。今すぐ物理メモリを増やすか、データ量を減らせ。
比率が 1.5 〜 2.0 超の場合: 内部断片化が進行している。OS側へのメモリ返却やデフラグメントの検討が必要。

—

4. 現場で使える堅牢な設計パターンと対策

レビューで「断片化率が高い」と検知したとき、プロのエンジニアならどう動くべきか。具体的な処方箋を提示する。

対策①：Redis 2.4以降 / 4.0以降の自動デフラグを有効にする

Redis 4.0から、再起動なしでメモリ断片化を解消する Active Defragmentation（アクティブデフラグ） が導入された。
`redis.conf` または動的設定（`CONFIG SET`）で以下のようにチューニングする。

断片化率が1.4を超え、かつ無駄な空間が100MB以上ある場合にデフラグを発動
activedefrag yes
active-defrag-ignore-bytes 100mb
active-defrag-threshold-lower 10
active-defrag-threshold-upper 100
active-defrag-cycle-min 5
active-defrag-cycle-max 35

ただし注意しろ。アクティブデフラグはCPUを消費する（ポインタの書き換えを裏でゴリゴリやるため）。レイテンシにシビアな高ス負荷システムでは、CPU使用率のスパイクに注意しながら検証環境でパラメータを追い込むこと。

対策②：巨大なデータ構造の分割（Chunking）

1つのHash型に100万件ものフィールドを詰め込むのは設計の敗北だ。
「1つのキーあたりの要素数はせいぜい数千〜1万件程度」に抑え、キーの名前空間を分割しろ（例: `user:profile:{user_id}` のようにハッシュタグやパーティショニングを活用する）。これだけでjemallocのサイズクラスの効率が劇的に改善される。

対策③：適切なメモリ制限（`maxmemory`）とポリシーの設定

何も考えずにメモリを食いつぶさせない。必ず `maxmemory` を設定し、適切な `maxmemory-policy`（`volatile-lru`, `allkeys-lru`, あるいは `noeviction` など）をシステムの特性に合わせて選定しろ。

—

5. チーフアーキテクトからの総括

Redisの運用において、「動けばいい」はプロの言葉ではない。
ピーク時にどれだけのメモリを保持し、jemallocがどれだけの無駄（メタデータや断片化）を抱えているかを `MEMORY STATS` で常時モニタリング・メトリクス収集（Prometheus + Grafanaなどへの統合）できて初めて、プロダクションクオリティと言える。

次の設計レビューまでにお前たちのコードとRedisのメトリクスを見直しておけ。
メモリの無駄遣いは、コストの無駄遣いであり、システム障害への一番の近道だ。以上だ、解散！