Open6
Redisの運用
dehio3CPUUtilization
- 一般的には90%が閾値
- Redisはシングルスレッドのため、90%/コア数が実際の閾値
- 4個以上のvCPUを持つノードタイプでは
EngineCPUUtilizationを使用する -
EngineCPUUtilizationはRedisエンジンスレッドのCPU使用率
dehio3SwapUsage
- 50 MB を超えてはいけない
- バックアップやフェイルオーバー時のクラスタへの書き込み操作を記録するために追加のメモリが、ノードの利用可能なメモリを超えるとSwapが使われる
バックアップやフェイルオーバーを行う際、Redisはクラスタのデータが.rdbファイルに書き込まれる間、クラスタへの書き込み操作を記録するために追加のメモリを使用します。この追加のメモリ使用量がノードの利用可能なメモリを超えると、過剰なページングとSwapUsageのために処理が遅くなることがあります。このため、予約メモリを使用することをお勧めします。リザーブドメモリとは、バックアップやフェイルオーバーなどの処理に対応するために確保されたメモリのことです。詳しくは、「リザーブドメモリーの管理」をご覧ください。
予約メモリとは？
- 予約メモリは、データ以外の用途のために確保されたメモリです。
- バックアップやフェイルオーバーを実行するとき、Redisはクラスタのデータが.rdbファイルに書き込まれている間、クラスタへの書き込み操作を記録するために利用可能なメモリを使用します。
- すべての書き込みに十分なメモリが利用できない場合、処理は失敗します。
バックアップ
- バックアップは、クラスター内の全データとクラスターのメタデータで構成
- すべてのバックアップは、S3に書き込まれる
- Redis 2.8.22 バージョンからは、使用可能なメモリに基づいてバックアップ方法が選択
- 十分な利用可能なメモリがある場合は、キャッシュのバックアップ中にすべての変更をキャッシュの予約メモリに書き込む子プロセスが生成
- バックアッププロセス中のキャッシュへの書き込み回数に応じて、この子プロセスはすべての予約メモリを消費
- バックアップエラーの原因は、たいてい利用可能なメモリの不足
- バックアップを試行する前に、十分な予約メモリがあることを確認
- メモリが不足している場合は、一部のキーを削除するか、reserved-memory-percent の値を増やす
- バックアップパフォーマンスの向上
- reserved-memory-percent パラメータを設定する
- リードレプリカからバックアップを作成する
バックアップウィンドウ
18:30-19:30 UTC（03:30-04:30 JST）
バックアップの動き
dehio3
cache.r5.large
- redis_version：5.0.6
- メモリ：13.07 GiB
- reserved-memory-percent：25
- maxmemor：10,527,885,773
# Memory
# Memory
used_memory:9270235880
used_memory_human:8.63G
used_memory_rss:10664402944
used_memory_rss_human:9.93G
used_memory_peak:10530916048
used_memory_peak_human:9.81G
used_memory_peak_perc:88.03%
used_memory_overhead:324153302
used_memory_startup:4263592
used_memory_dataset:8946082578
used_memory_dataset_perc:96.55%
allocator_allocated:9270977824
allocator_active:10491838464
allocator_resident:10673037312
used_memory_lua:37888
used_memory_lua_human:37.00K
used_memory_scripts:0
used_memory_scripts_human:0B
number_of_cached_scripts:0
maxmemory:10527885773
maxmemory_human:9.80G
maxmemory_policy:volatile-lru
allocator_frag_ratio:1.13
allocator_frag_bytes:1220860640
allocator_rss_ratio:1.02
allocator_rss_bytes:181198848
rss_overhead_ratio:1.00
rss_overhead_bytes:-8634368
mem_fragmentation_ratio:1.15
mem_fragmentation_bytes:1394104296
mem_not_counted_for_evict:0
mem_replication_backlog:1048576
mem_clients_slaves:17130
mem_clients_normal:168324
mem_aof_buffer:0
mem_allocator:jemalloc-5.1.0
active_defrag_running:0
lazyfree_pending_objects:0
チューニング
セッションの圧縮
分析
redis-rdb-tools
RedisInsight
--bigkeysオプション
dehio3キーの削除
maxmemory_policy
- maxmemory の値を超えるデータの追加が発生した場合の振る舞い
-
volatile-lru: LRU アルゴリズムに従って古いキーの値が優先的に破棄 -
volatile-ttl: expire のタイムスタンプをみて、タイムスタンプがより過去のものから順に破棄- 常にタイムスタンプの最も古いキーが削除されるわけではない。 ランダムに数個のキーを選びその中で最も古いものを削除対象として選ぶアルゴリズムになっている。