ApsaraDB for Redis:ApsaraDB for Redisインスタンスの高メモリ使用量のトラブルシューティング

高いメモリ使用量の症状

高メモリ使用率は、次の3つのシナリオで現れます。

• メモリ使用量は長期間高いままです。 メモリ使用量が95% を超える場合は、タイムリーに対応する必要があります。

• メモリ使用量は一貫して低いですが、突然急上昇して高レベルになり、100% に達します。

• インスタンスの全体的なメモリ使用量は少ないですが、特定のデータノードのメモリ使用量はほぼ100% です。

特定のシナリオに基づいて、メモリ使用量を削減するための適切な対策を講じてください。

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

1. 既存のキーがビジネス要件を満たしているかどうかを確認し、不要なキーをタイムリーに削除します。

2. キャッシュ分析機能を使用して、大きなキーの分布とキーの有効期限 (TTL) を分析します。 詳細については、「オフラインキー分析機能の使用」をご参照ください。

   1. キーに適切なTTL値が設定されているかどうかを確認します。

      説明

      次の例では、キーにTTL値が設定されていません。 ビジネス要件に基づいて、クライアントで適切なTTL値を設定することを推奨します。

      図4. キーTTLの配布例

   2. クライアントで大きなキーを評価し、大きなキーを分割します。

      図5. 大きなキー分析の例

3. 適切な削除ポリシーを設定するか、ビジネス要件に基づいてmaxmemory-policyパラメーターの値を変更します。 詳細は、「インスタンスパラメーターの設定」をご参照ください。

   説明

   volatile-lruは、ApsaraDB for Redisのデフォルトの削除ポリシーです。 詳細については、「」をご参照ください。ApsaraDB for Redisのデフォルトの削除ポリシーは何ですか?

4. 期限切れのキーを削除する頻度を適切な値に設定するか、ビジネス要件に基づいてhzパラメーターの値を変更します。 詳細については、「バックグラウンドタスクの頻度の調整」をご参照ください。

   説明

   hzパラメーターを100より小さい値に設定することを推奨します。 この値が大きい場合、CPU使用率が影響を受けます。 メジャーバージョンが5.0のインスタンスに動的周波数制御を設定することもできます. 詳細については、「バックグラウンドタスクの動的周波数制御の有効化」をご参照ください。

5. 上記の手順を実行してもメモリ使用量が多い場合は、より多くのデータに対応し、全体的なパフォーマンスを向上させるために、インスタンスをより大きなメモリサイズにアップグレードすることを検討してください。 詳細については、「インスタンスの設定の変更」をご参照ください。

   説明

   ApsaraDB for Redisインスタンスをアップグレードする前に、従量課金インスタンスを購入して、アップグレード先の仕様がワークロードの要件を満たしているかどうかをテストできます。 テストの完了後、従量課金インスタンスをリリースできます。 詳細については、「従量課金インスタンスのリリース」をご参照ください。

メモリ使用量の急増に対する解決策

発生原因

次の理由により、メモリ使用量が突然増加することがあります。

• 大量の新しいデータが短時間で書き込まれる。

• 短時間で多数の新しい接続が確立されます。

• バーストアクセスでは、ネットワーク帯域幅を超える大量のトラフィックが生成され、その結果、入力バッファと出力バッファにバックログが発生します。

• クライアントは Tairの処理速度に追いつくことができず、出力バッファーにバックログが発生します。

ソリューション

メモリ使用量の突然の増加の原因を特定し、提案されたソリューションを使用して問題を解決します。

大量の新しいデータが書き込まれているかどうかを確認する

トラブルシューティング方法:

パフォーマンスモニターページで、 Tairインスタンスのインバウンドトラフィックと1秒あたりの書き込みクエリ (QPS) を確認します。 インバウンドトラフィックと書き込みQPSがメモリ使用量と同じ傾向にある場合、メモリ使用量の急激な増加は、大量の書き込みデータが原因です。

解決策:

1. キーに適切な有効期間 (TTL) 値を設定して、不要になったキーを自動的に削除したり、不要なキーを手動で削除したりします。

2. メモリ使用量の急激な増加を緩和するために、メモリ容量を増やしてインスタンス仕様をアップグレードします。 詳細については、「インスタンスの設定の変更」をご参照ください。

3. インスタンスが標準インスタンスで、メモリ容量を増やした後もメモリ使用量が多い場合は、インスタンスをクラスターインスタンスにアップグレードできます。 これにより、複数のデータシャードにデータを分散して、個々のデータシャードのメモリ負荷を軽減できます。 詳細については、「インスタンスの設定の変更」をご参照ください。

大量の新しい接続が作成されているかどうかの確認

トラブルシューティング方法:

パフォーマンスモニターページで、 Tairインスタンスへの接続数を表示します。 接続数が突然増加し、メモリ使用量と同じ傾向に従う場合、メモリ使用量の突然の増加は、多数の新しい接続が原因です。

解決策:

1. 接続リークが存在するかどうかを確認します。

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

突然のトラフィックスパイクが入力バッファと出力バッファのバックログにつながるかどうかを確認する

トラブルシューティング方法:

1. インスタンスのインバウンドトラフィックとアウトバウンドトラフィックの使用量が100% に達しているかどうかを確認します。

2. MEMORY STATSコマンドを実行して、clients.normalが過剰なメモリを占有しているかどうかを確認します。

   説明

   clients.normalは、すべての通常のクライアント接続で入力バッファと出力バッファによって使用されるメモリの総量を反映します。

解決策:

1. トラフィックバーストの原因を確認します。

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

3. インスタンス仕様をアップグレードして、入力バッファと出力バッファの最適な使用を確保します。 詳細については、「インスタンスの設定の変更」をご参照ください。

クライアント側のパフォーマンスの問題が出力バッファのバックログにつながるかどうかを確認します

トラブルシューティング方法:

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

解決策:

CLIENT LISTコマンドを実行して、大量のメモリ (omem) を消費する大容量の出力バッファがあるクライアントを確認します。 クライアントアプリケーションにパフォーマンスの問題があるかどうかを確認します。

特定のデータノードの高メモリ使用量に対するソリューション

症状

ApsaraDB for Redisインスタンスがクラスターインスタンスの場合、次の症状に基づいて、特定のデータシャードのメモリ使用量が多いことがわかります。

• CloudMonitorからメモリ使用量アラートを受信します。 アラートメッセージは、特定のデータノードのメモリ使用量がしきい値を超えたことを示します。

• インスタンス診断レポートは、メモリ使用量のスキューが発生したことを示します。

• [パフォーマンスモニター] ページでは、インスタンスの全体的なメモリ使用量は高くありませんが、特定のデータノードのメモリ使用量は高くなっています。

発生原因

インスタンスのメモリ使用量が少ないが、データノードのメモリ使用量が多い場合、メモリ使用量のスキューが発生します。

ソリューション

大きいキーが存在し、大きいキーを分割するチェック

大きなキーの識別

オフラインキー分析機能を使用して、大きなキーを識別できます。 詳細については、「オフラインキー分析機能の使用」「」をご参照ください。

大きなキーの識別方法については、「大きなキーとホットキーの識別と処理」をご参照ください。「」をご参照ください。

分割大きなキー

たとえば、数万のメンバーを含むHASHキーを、適切な数のメンバーを持つ複数のHASHキーに分割できます。 Tairクラスターアーキテクチャでは、大きなキーを分割するとデータシャード間のメモリバランスが大幅に向上します。

ハッシュタグが使用されているかどうかの確認

ハッシュタグを使用する場合は、ビジネス要件に基づいてハッシュタグを複数のハッシュタグに分割することを検討してください。 このようにして、データは異なるデータノードにわたって均等に分散される。

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

各シャードに割り当てられるメモリを増やしてインスタンス仕様をアップグレードすることは、メモリスキューを防ぐための一時的な解決策として役立ちます。 詳細については、「インスタンスの設定の変更」をご参照ください。

付録1: ApsaraDB for Redisのメモリ使用量

ApsaraDB for Redisのメモリ使用量は3つの部分に分かれています。 メモリ使用量を次の表に示します。

付録2: メモリ使用量を確認するその他の方法

1) "peak.allocated" //The highest amount of memory that the Redis process has consumed since it was started. 
 2) (integer) 79492312
 3) "total.allocated" //The total number of bytes that are allocated to run the Redis process. This is the current total memory usage. 
 4) (integer) 79307776
 5) "startup.allocated" //The memory consumed by the Redis process at startup. 
 6) (integer) 45582592
 7) "replication.backlog" //The size of the replication backlog buffer. 
 8) (integer) 33554432
 9) "clients.slaves" //The size of the read and write buffer in all replica nodes for master-replica replication. 
10) (integer) 17266
11) "clients.normal" //The size of the read and write buffers in other clients that are connected to all data nodes except replica nodes. 
12) (integer) 119102
13) "aof.buffer" //The cache used for AOF persistence and the cache generated during AOF rewrite operations. 
14) (integer) 0
15) "db.0"  //The number of databases. 
16) 1) "overhead.hashtable.main" //The total memory consumed by the hash tables in the current database. This is the memory consumed to store metadata. 
    2) (integer) 144
    3) "overhead.hashtable.expires" //The memory consumed to store expired keys. 
    4) (integer) 0
17) "overhead.total" //The value of the overhead.total parameter is calculated based on the following formula: overhead.total = startup.allocated + replication.backlog + clients.slaves + clients.normal + aof.buffer + db. X. 
18) (integer) 79273616
19) "keys.count" //The total number of keys in the current ApsaraDB for Redis instance.
20) (integer) 2
21) "keys.bytes-per-key" //The average size per key in the current ApsaraDB for Redis instance. Formula: (total.allocated-startup.allocated)/keys.count. 
22) (integer) 16862592
23) "dataset.bytes" //The memory consumed by business data. 
24) (integer) 34160
25) "dataset.percentage" //The percentage of the memory consumed by business data. Formula: dataset.bytes × 100/(total.allocated - startup.allocated). 
26) "0.1012892946600914"
27) "peak.percentage" //The percentage of the current total memory usage to the historical peak memory usage. Formula: total.allocated × 100/peak.allocated. 
28) "99.767860412597656"
29) "fragmentation" //The memory fragmentation rate. 
30) "0.45836541056632996"

    int empty = 0;     /* Instance is empty or almost empty. */
    int big_peak = 0;       /* Memory peak is much larger than used mem. */
    int high_frag = 0;      /* High fragmentation. */
    int high_alloc_frag = 0;/* High allocator fragmentation. */
    int high_proc_rss = 0;  /* High process rss overhead. */
    int high_alloc_rss = 0; /* High rss overhead. */
    int big_slave_buf = 0;  /* Slave buffers are too big. */
    int big_client_buf = 0; /* Client buffers are too big. */
    int many_scripts = 0;   /* Script cache has too many scripts. */

MEMORY USAGE Key0089393003

(integer) 1000072