すべてのプロダクト
Search
ドキュメントセンター

Tair (Redis® OSS-Compatible):インスタンスにおける高メモリ使用量のトラブルシューティング

最終更新日:Mar 28, 2026

Tair (Redis OSS-compatible) のメモリ不足は、キーのエビクション、応答時間の増加、秒間クエリ数 (QPS) の不安定化を引き起こし、ワークロードに中断をもたらします。本トピックでは、高メモリ使用量の 3 つの異なるシナリオ、それぞれの特定方法、および対処方法について説明します。

該当するシナリオにジャンプ:

該当するシナリオの特定

高メモリ使用量は、以下の 3 つのパターンのいずれかに該当します:

  • 一貫して高い — メモリ使用量が長期間にわたり高水準で推移しています。95 % を超える場合は、直ちに対応してください。

  • 突然の急増 — 通常は低水準であるメモリ使用量が、急激に上昇し、場合によっては 100 % に達します。

  • データノードのスキュー — インスタンス全体のメモリ使用量は低いものの、特定のデータノードの使用率が 100 % 近くに達しています。

一貫して高いメモリ使用量へのソリューション

  1. 不要なキーを削除します。 既存のキーを業務要件と照らし合わせて確認し、不要となったキーを削除します。

  2. オフラインキー分析でキーの分布を分析します。 オフラインキー分析機能 を使用して、以下の 2 つのディメンションを調査します:

    • TTL 分布 — 有効期限が設定されていないキーを特定し、クライアント側で適切な生存時間 (TTL) を設定します。図 4. キーの TTL 分布例 Key的过期时间分布示例

    • 大規模キー分析 — 大規模なキーを特定し、クライアント側で分割します。図 5. 大規模キー分析例 大Key分析示例

  3. 立ち退きポリシーを設定します。 アクセスパターンに応じて、maxmemory-policy パラメーターを構成します。デフォルトポリシーは volatile-lru です。立ち退き動作の詳細については、「Tair (Redis OSS-compatible) のデフォルトのデータ立ち退き動作とは?」をご参照ください。構成手順については、「インスタンスパラメーターの構成」をご参照ください。

  4. バックグラウンドタスクの実行頻度を調整します。 hz を 100 未満の値に設定します。値を高くすると CPU 使用率が上昇します。メジャーバージョン 5.0 以降を実行中のインスタンスでは、代わりに動的周波数制御を有効化します。詳細については、「バックグラウンドタスクの実行頻度の調整」および「バックグラウンドタスクの動的周波数制御の有効化」をご参照ください。

  5. インスタンスをスペックアップします。 上記の手順を実施後もメモリ使用量が依然として高い場合は、インスタンスのメモリ容量を増加させます。スペックアップ前に、ワークロード要件を満たす仕様であることを検証するために従量課金インスタンスを購入し、テスト後にリリースします。詳細については、「インスタンスの構成変更」および「従量課金インスタンスのリリース」をご参照ください。

メモリ使用量の突然の急増へのソリューション

原因

メモリ使用量の突然の急増は、以下の 4 つの原因のいずれかに起因します:

  • 短時間に大量の新規データが書き込まれた

  • 多数の新規接続が同時に確立された

  • ネットワーク帯域幅を超えるトラフィックバーストにより、入力および出力バッファーにキューが発生した

  • クライアント側の処理遅延により、出力バッファーにキューが発生した

以下に示す各原因を順次確認し、根本原因を特定して適切な対処を行ってください。

大量のデータ書き込みが急増の原因かどうかを確認する

特定方法: パフォーマンスモニタリングページで、インバウンドトラフィック および 書き込み QPS のトレンドをメモリ使用量と比較します。3 つすべてが同時に上昇している場合、急増は書き込みによるものです。

対処方法:

  1. 不要になったデータを自動的に有効期限切れにするためにキーに TTL を設定するか、古くなったキーを手動で削除します。

  2. インスタンスのアップグレードにより、メモリ容量を増加させます。詳細については、「インスタンスの構成を変更する」をご参照ください。

  3. インスタンスがスタンダードインスタンスであり、容量を増加させた後もメモリ圧力が解消されない場合は、クラスターインスタンスにスペックアップします。これにより、データが複数のシャードに分散され、シャード単位のメモリ圧力が軽減されます。詳細については、「インスタンスの設定を変更する」をご参照ください。

接続数の急増が急増の原因かどうかを確認する

特定方法: パフォーマンスモニタリングページで、接続数 を確認します。接続数がメモリ使用量と同調して増加している場合、急増は接続によるものです。

対処方法:

  1. アプリケーション内の接続リークを確認します。

  2. アイドル接続を自動的に閉じるには、接続タイムアウトを設定します。詳細については、「クライアント接続のタイムアウト期間を指定する」をご参照ください。

トラフィックバーストが入力および出力バッファーを満たしているかどうかを確認する

特定方法:

  1. パフォーマンスモニタリングページで、インバウンドおよびアウトバウンドトラフィックの使用率が 100 % に達しているかどうかを確認します。

  2. redis-cli で MEMORY STATS コマンドを実行し、clients.normal の値を確認します。

    説明

    clients.normal は、すべての通常クライアント接続における入力および出力バッファーが消費する合計メモリを示します。この値は、クライアントが範囲ベースの操作を実行したり、低スループットで大規模なキーを送受信したりした際に増加します。clients.normal の値が増加すると、データストレージに利用可能なメモリが減少し、メモリ不足 (OOM) エラーが発生する可能性があります。

対処方法:

  1. トラフィックバーストの根本原因を特定し、対処します。

  2. インスタンスのネットワーク帯域幅を増加させます。詳細については、「インスタンスの帯域幅を手動で増加させる」および「帯域幅の自動スケーリングを有効化する」をご参照ください。

  3. インスタンスの仕様をアップグレードして、入力および出力バッファーに十分な余裕を確保します。詳細については、「インスタンスの構成を変更する」をご参照ください。

クライアント側のボトルネックがアウトプットバッファーを満たしているかどうかを確認する

特定方法: redis-cli で MEMORY DOCTOR コマンドを実行します。big_client_buf の値が 1 に設定されている場合、少なくとも 1 つのクライアントの出力バッファーが過大となり、多量のメモリを消費しています。

対処方法: CLIENT LIST コマンドを実行し、omem 値が大きいクライアントを特定した後、そのクライアントアプリケーションにパフォーマンスボトルネックがないかを調査します。

データノードにおけるメモリスキューへのソリューション

症状

クラスターインスタンスの場合、メモリスキューは以下のいずれかのサインで検知できます:

  • CloudMonitor のアラートで、特定のデータノードのメモリ使用量が設定されたしきい値を超えていることが通知される。

  • インスタンス診断レポートで、メモリ使用量のスキューが指摘される。

  • パフォーマンスモニタリングページで、インスタンス全体のメモリ使用量は低いが、特定のデータノードのメモリ使用量が高い。

メモリスキューとは、インスタンス全体のメモリ使用量は低いものの、1 つまたは複数の個別のデータノードの使用率がほぼ満杯に近い状態を指します。

大規模キーの対処

大規模キーの特定を、オフラインキー分析機能を使用するか、大規模キーおよびホットキーの特定と処理のガイドに従って行います。

大規模キーの分割はクライアント側で実施します。例えば、数万のメンバーを持つハッシュを、適切なメンバー数で構成された複数の小さなハッシュに分割します。クラスターインスタンスでは、これらの小さなハッシュを異なるスロットに分散させることで、シャード間のメモリ圧力を均等化できます。

不均等なハッシュタグの分散の対処

キーにハッシュタグを使用している場合、単一のハッシュタグを複数のハッシュタグに分割することで、データをデータノード間により均等に分散させることができます。

インスタンス仕様のアップグレード

各シャードに割り当てるメモリを増加させることは、短期的なスキュー緩和策となります。詳細については、「インスタンスの構成変更」をご参照ください。

重要
  • インスタンス仕様を変更する際、システムはデータスキューの事前チェックを実行します。選択したインスタンスタイプが既存のスキューに対応できない場合、システムはエラーを返します。より高仕様のインスタンスタイプを選択して再試行してください。

  • アップグレード後、メモリスキューは緩和される可能性がありますが、帯域幅や CPU リソースにスキューが移行する可能性があります。

付録:Redis コマンドによるメモリ使用量の確認

MEMORY STATS

redis-cli で MEMORY STATS コマンドを実行すると、メモリ消費の詳細な内訳が表示されます。インスタンスのメモリは以下の 2 つのカテゴリに分類されます:

  • 業務データ — 実際のデータが消費するメモリ。これは主に分析対象となる領域です。

  • 非業務オーバーヘッド — レプリケーションバックログバッファーおよび Redis プロセス初期化が消費するメモリ。

すべてのサイズはバイト単位です。以下のサンプル出力は、各フィールドとその意味を示しています:

 1) "peak.allocated"         // Redis プロセス起動以降の最高メモリ使用量
 2) (integer) 79492312
 3) "total.allocated"        // 現在の合計メモリ使用量(Redis プロセスに割り当てられたバイト数)
 4) (integer) 79307776
 5) "startup.allocated"      // Redis 起動時のメモリ消費量
 6) (integer) 45582592
 7) "replication.backlog"    // レプリケーションバックログバッファーのサイズ
 8) (integer) 33554432
 9) "clients.slaves"         // すべてのレプリカノードの読み書きバッファー
10) (integer) 17266
11) "clients.normal"         // すべての非レプリカクライアント接続の読み書きバッファー
12) (integer) 119102
13) "aof.buffer"             // AOF(追記専用ファイル)永続化および AOF 再書き込み操作のキャッシュ
14) (integer) 0
15) "db.0"
16) 1) "overhead.hashtable.main"    // 現在のデータベースにおけるハッシュテーブルのメモリ(メタデータ格納用)
    2) (integer) 144
    3) "overhead.hashtable.expires" // 期限切れキーのメタデータ格納用メモリ
    4) (integer) 0
17) "overhead.total"         // = startup.allocated + replication.backlog + clients.slaves + clients.normal + aof.buffer + db.X
18) (integer) 79273616
19) "keys.count"             // インスタンス内のキー総数
20) (integer) 2
21) "keys.bytes-per-key"     // キーあたりの平均メモリ:(total.allocated - startup.allocated) / keys.count
22) (integer) 16862592
23) "dataset.bytes"          // 業務データが消費するメモリ
24) (integer) 34160
25) "dataset.percentage"     // 業務データの割合:dataset.bytes × 100 / (total.allocated - startup.allocated)
26) "0.1012892946600914"
27) "peak.percentage"        // 現在の使用率のピーク比:total.allocated × 100 / peak.allocated
28) "99.767860412597656"
29) "fragmentation"          // メモリ断片化比率
30) "0.45836541056632996"

MEMORY DOCTOR

redis-cli で MEMORY DOCTOR コマンドを実行すると、メモリ診断に関する推奨事項が表示されます。

図 3. 診断結果の例 诊断结果示例

このコマンドは、以下の診断フラグを評価します:

int empty = 0;          /* インスタンスが空またはほぼ空である。 */
int big_peak = 0;       /* メモリピークが使用メモリより大幅に大きい。 */
int high_frag = 0;      /* 断片化率が高い。 */
int high_alloc_frag = 0;/* アロケータの断片化率が高い。 */
int high_proc_rss = 0;  /* プロセス RSS オーバーヘッドが高い。 */
int high_alloc_rss = 0; /* RSS オーバーヘッドが高い。 */
int big_slave_buf = 0;  /* レプリカバッファーが大きすぎる。 */
int big_client_buf = 0; /* クライアントバッファーが大きすぎる。 */
int many_scripts = 0;   /* スクリプトキャッシュに過剰な数のスクリプトが保持されている。 */

MEMORY USAGE

redis-cli で MEMORY USAGE <key> コマンドを実行すると、特定のキーが消費するメモリ量(バイト単位)を確認できます。

MEMORY USAGE Key0089393003

期待される出力:

(integer) 1000072

Tair (Redis OSS-compatible) におけるメモリの割り当て

インスタンスのメモリは、以下の 3 つの部分に分けられます:

コンポーネント説明
リンク関連操作入力バッファー、出力バッファー、JIT オーバーヘッド、Fake Lua Link、キャッシュ済み Lua スクリプト。消費量は動的に変化します。INFO コマンドを実行し、Clients セクションで現在の値を確認できます。クライアントが範囲ベースの操作を実行したり、低スループットで大規模なキーを送受信したりした場合、入力および出力バッファーの使用量が増加し、データストレージに利用可能なメモリが減少して OOM エラーを引き起こす可能性があります。
データストレージ保存されたフィールド値が消費するメモリ。高メモリ使用量のトラブルシューティング時に主に分析対象となる領域です。
管理オーバーヘッドハッシュテーブル、レプリケーションバッファー、AOF バッファー。通常条件下では、このコンポーネントは 32 MB ~ 64 MB の範囲で安定しています。数百億に及ぶ非常に多数のキーがある場合、このコンポーネントの消費量が増加することがあります。
説明

ほとんどの OOM 問題は、動的に割り当てられるメモリの非効率な管理に起因します。例えば、速度制限によるリクエストキューの発生は、動的に取得されたメモリの急激な増加を招きます。また、複雑または不適切に記述された Lua スクリプトも OOM を引き起こす可能性があります。Tair (Enterprise Edition) では、動的に割り当て・解放されるメモリに対する強化されたメモリ管理機能が提供されています。詳細については、「概要」をご参照ください。

次のステップ