Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Redisのメモリ溢れと戦った話 / tech-meetup2_akechi

Recruit
January 21, 2022

Redisのメモリ溢れと戦った話 / tech-meetup2_akechi

2022/01/20_RECRUIT TECH MEETUP #2での、明智の講演資料になります

Recruit

January 21, 2022
Tweet

More Decks by Recruit

Other Decks in Technology

Transcript

  1. アジェンダ 1. Redisの導入 2. メモリ溢れの発生 3. メモリ溢れの再発 4. 恒久対応の検討 5.

    OSメモリの枯渇 6. 恒久対応の実施(不十分) 7. 突然のF/O 8. 恒久対応の実施
  2. RAFTEL LB Redisのシステム構成 Application VIP(write/read) healthchecker healthchecker healthchecker sentinel sentinel

    sentinel Master Slave Slave replication healthcheck healthcheckで確認 ・Redis自体の生存 ・RedisがMasterであること ・stopfileがないこと load balance
  3. アジェンダ 1. Redisの導入 2. メモリ溢れの発生 3. メモリ溢れの再発 4. 恒久対応の検討 5.

    OSメモリの枯渇 6. 恒久対応の実施(不十分) 7. 突然のF/O 8. 恒久対応の実施
  4. 対応:Redisのメモリ上限を引き上げ • 引き上げるメモリのサイジング ◦ 24日で16GBに到達したので、1日で0.67GB増えている ◦ 0.67(GB/日) * 30(日) *

    1.3(安全率) = 27GB • スペックがメモリ32GBだったので、同期に必要なメモリを確保するためにメ モリ64GBのサーバにスケールアップ
  5. Slaveへの同期の仕組み healthchecker healthchecker healthchecker sentinel sentinel sentinel Master Slave Slave

    replication ①Masterノードでダンプファイ ルを出力する (バックグラウンド実行) ②出力したダンプファイルを Slaveノードに転送する ③Slaveノードでダンプファイル をメモリにロードする
  6. Slaveに同期されなかった理由 healthchecker healthchecker healthchecker sentinel sentinel sentinel Master Slave Slave

    replication ①Masterノードでダンプファイ ルを出力する (バックグラウンド実行) ②出力したダンプファイルを Slaveノードに転送する ③Slaveノードでダンプファイル をメモリにロードする cannot allocate memory
  7. アジェンダ 1. Redisの導入 2. メモリ溢れの発生 3. メモリ溢れの再発 4. 恒久対応の検討 5.

    OSメモリの枯渇 6. 恒久対応の実施(不十分) 7. 突然のF/O 8. 恒久対応の実施
  8. “ Note that maxmemory should be set calculating the overhead

    that Redis has, other than data, and the fragmentation overhead. So if you think you have 10GB of free memory, set it to 8 or 9.” —Redisの公式ドキュメント https://redis.io/topics/admin ➡OSのfree memoryの8~9割に  設定すべきと解釈
  9. 対応:Redisのメモリ上限を引き上げ(再) • 引き上げるメモリのサイジング ◦ Redisが確保しているメモリは33GB ◦ OSのfree memoryは17GB ◦ free

    memory(33+17) * 0.9 = 45GB • Slaveへの同期にはRedisと同じメモリ量が必要になるため、 swap領域も拡張
  10. アジェンダ 1. Redisの導入 2. メモリ溢れの発生 3. メモリ溢れの再発 4. 恒久対応の検討 5.

    OSメモリの枯渇 6. 恒久対応の実施(不十分) 7. 突然のF/O 8. 恒久対応の実施
  11. Redisに格納されているデータの分析結果 • infoはキーの登録数・データ量がともに最も多く占めている • Redisのメモリ使用量とダンプデータのサイズが大きく乖離している セッション名 有効 期間 登録数 データ量

    件数 割合(%) サイズ(GB) 割合(%) memory 短期 58883 0.08 0.11 0.60 token 短期 5082154 6.22 3.41 18.77 permanentdb 長期 966779 1.18 0.79 4.34 info 長期 75551260 92.52 13.86 76.28 合計 81659079 100 18.17 100 有効期限切れのキーが 削除されていない?
  12. Redisの有効期限切れキーの削除アルゴリズム • passive wayとactive wayの2つの方法で有効期限切れキーの 削除を行う • active way:1秒間に10回下記の処理を実行する 1.

    有効期限が設定されているキーを20個サンプリングする 2. サプリングしたキーの中で有効期限切れキーを削除する 3. 有効期限切れキーが25%(5個)より多ければステップ1に戻る →有効期限切れキーの割合は25%以下になるはず
  13. アジェンダ 1. Redisの導入 2. メモリ溢れの発生 3. メモリ溢れの再発 4. 恒久対応の検討 5.

    OSメモリの枯渇 6. 恒久対応の実施(不十分) 7. 突然のF/O 8. 恒久対応の実施
  14. 対応:有効期限切れキーを削除 • 有効期限切れキーを削除することで、Redisが使用するメモリ量を 削減する ◦ scanコマンドを使ったpassive wayで削除する • コンテプラン 1.

    overcommit_memoryを有効化する a. Redisの推奨設定だが、OOM Killerによるプロセス強制削除の リスクがある 2. セッションデータを全て破棄する a. 最悪の場合に備えて事業調整
  15. アジェンダ 1. Redisの導入 2. メモリ溢れの発生 3. メモリ溢れの再発 4. 恒久対応の検討 5.

    OSメモリの枯渇 6. 恒久対応の実施(不十分) 7. 突然のF/O 8. 恒久対応の実施
  16. アジェンダ 1. Redisの導入 2. メモリ溢れの発生 3. メモリ溢れの再発 4. 恒久対応の検討 5.

    OSメモリの枯渇 6. 恒久対応の実施(不十分) 7. 突然のF/O 8. 恒久対応の実施
  17. アジェンダ 1. Redisの導入 2. メモリ溢れの発生 3. メモリ溢れの再発 4. 恒久対応の検討 5.

    OSメモリの枯渇 6. 恒久対応の実施(失敗) 7. 突然のF/O 8. 恒久対応の実施