Redisメモリ最適化のメモリ淘汰ポリシー
6402 ワード
会社のサービスはリアルタイム計算のスパンが大きすぎるため、前述したようにredisで状態管理を行う必要があると述べており、データ修正が発見されていないがexpire時間を変更しないやり方であるため、記録されたデータはすべて期限切れ時間を設定していない.スクリプトと大きなkeyで毎日未明にredisの前日の状態データをクリーンアップする計画であるが、24時間の実行中にデータ量が大きすぎる可能性がある.メモリ消費が大きすぎるという問題を引き起こし、業務がtop 100の記録を記録するだけであることを考慮すると、top 100はいわゆるホットスポットデータであると理解でき、ホットスポットデータではなくメモリが不足している場合に解放を選択することができ、Redisメモリ淘汰戦略を調べたところ、具体的な淘汰戦略は以下の通りである.
1>Redis 4.0以前 noeviction:データの淘汰を行わず、メモリが上限に達して十分なメモリを申請できない場合に直接エラーを報告します. volatile-lru:有効期限が設定されているすべてのkeyから、最近最も使用されているデータを選択して淘汰します. volatile-ttl:有効期限が設定されているkeyについては、有効期限に従ってフィルタリングし、有効期限が切れるデータを選択して淘汰します. volatile-random:有効期限が設定されているデータからランダムに淘汰します. allkeys-lru:すべてのkey(有効期限を設定するかどうかにかかわらず)から、最近最も少ないものを選択して淘汰します. allkeys-random:すべてのkeyからランダムに淘汰される.
2>Redis 4.0以降の追加 allkeys-lfu:lruとは異なり、lruは最近最も少ない使用で淘汰されていますが、ある日ある時間帯に不活発(不活発スパンがクリーンアップ間隔を超えている)になる可能性があり、実際には一日中データ量の大きいデータがある可能性がありますが、ある時間帯にデータアクセスがないため前の記録がクリアされ、結果に悪影響を及ぼす可能性があります.したがって4.0以降に加わるこのLFUはこのような需要をよく補っており、LFUは記録ごとのアクセス頻度と理解できる.もちろん、このアクセス頻度は時間とともに関係しているが、データが変わらなければ、時間とともに増加するにつれてこの頻度値は減少し、ある時間帯にあるデータ量のアクセスが極めて頻繁で、途中でデータアクセスがない時間があるが、そのアクセス頻度は実際には高い.したがって、あるクリーンアップサイクル中にアクセスレコードがなくても、必ずしもクリーンアップされるとは限らず、top 100クラスのビジネスの実現が良好に保障されます. volatile-lfu:有効期限が設定されているkeyに基づいてLFUアルゴリズムを用いて淘汰する.
ここではtop 100にとって、ここでは長期にわたってアクティブなデータと理解できるが、top 100以外のデータについては、基本的にいわゆる最もあまり使用されないデータに属するため、allkeys-lfuポリシーを用いてデータクリーンアップを行うことを選択する.設定方法は次のとおりです.
もちろんここで注意すべき点は、上述のいわゆるLRUは厳密な意味でのLRUアルゴリズム実装ではなく、アルゴリズムメモリ消費の観点から、淘汰サンプルを選択する際に、すべてのデータを一度にフィルタ・ソートして最適な淘汰サンプルを見つけるのではなく、全体のデータ・セットで小部分サンプリング(サンプリング個数制御パラメータ:
補足点:
LFUに関する2つのパラメータlfu-log-factorは個人的にcounter数値の各1値がカバーするアクセス周波数の範囲の大きさと理解されている.すなわち、lfu-log-factorが大きいほど、counterが1を増加するたびに対応する周波数が高くなることを示している.すなわち、counterの1がカバーする周波数密度は相対的に低く(区間が低い)、例えばlfu-log-factor=0の場合、counterは1値を増加するたびにデータクリック率を10回増加させる必要がある.一方、lfu-log-factor=10の場合、counterは1値増加ごとにデータクリック率を1000回追加する必要があるため、lfu-log-factor=0、counter=10の場合、counter=10の場合、counter=10の場合、counter=10の場合、counter=10の場合、counter=10の場合、counter=10の場合のクリック頻度は[n,n+1000]であるため、このlfu-log-factorは周波数密度とカバーする最大周波数範囲を比較する制御パラメータである.業務データの周波数が高くないが密度範囲に高い感度があり、例えば周波数10回と20回の区別が要求される場合、lfu-log-factorの設定を低くする必要がある.そうしないと、10回と20回の周波数データのcounter値が異なる.そうしないと、lfu-log-factorの設定が大きすぎると、10回と20回の2つのデータが最終的に得られるcounter値は同じで、区別できない.もちろん、周波数範囲が大きい場合、例えば最高周波数が100 M回に達し、0~100 M回の周波数範囲をサポートしたい場合は、lfu-log-factorパラメータを大きくする必要があります.そうしないと、lfu-log-factorが時間が経つと、1 M回の周波数の記録と100 M回の記録の最終的なcounter値は同じになります.もちろん、通常、システムのデフォルトのlfu-log-factor=10値を採用すれば、私たちのニーズの大部分を満たすことができます.
知識点を伸ばすLFUホットスポットkey
LFUアルゴリズムによれば、keyへの読み書きアクセスのたびに、24 bitsドメイン代表のアクセス時間とcounterが更新されるので、counter代表のアクセス頻度でどのkeyがホットスポットkeyであるかがわかり、redis自体が対応するアクセス方法を提供します.
もちろん、メモリデータクリーンアップメカニズムをallkeys-lfuまたはvolatile-lfuに設定する必要があります.lfuに基づいてのみ、対応するkeyへのアクセス頻度が取得されるためです.
参照先:
https://redis.io/topics/lru-cache
https://yq.aliyun.com/articles/278922
https://yq.aliyun.com/articles/257459?spm=a2c4e.11153940.blogcont278922.8.5b914914Pnf5A5
1>Redis 4.0以前
2>Redis 4.0以降の追加
ここではtop 100にとって、ここでは長期にわたってアクティブなデータと理解できるが、top 100以外のデータについては、基本的にいわゆる最もあまり使用されないデータに属するため、allkeys-lfuポリシーを用いてデータクリーンアップを行うことを選択する.設定方法は次のとおりです.
redis-cli config set maxmemory-policy allkeys-lfu
もちろんここで注意すべき点は、上述のいわゆるLRUは厳密な意味でのLRUアルゴリズム実装ではなく、アルゴリズムメモリ消費の観点から、淘汰サンプルを選択する際に、すべてのデータを一度にフィルタ・ソートして最適な淘汰サンプルを見つけるのではなく、全体のデータ・セットで小部分サンプリング(サンプリング個数制御パラメータ:
maxmemory-samples)を行うたびに、次に、このローカルサンプルの内部で、LRUを介して淘汰する必要があるサンプルを選択し、このようにループサンプリングしてデータ淘汰を行う.したがって、本物のLRUとは少し区別されていますが、3.0以降、Redis内部では淘汰サンプルプールが維持されます.つまり、使用量の少ないデータの一部を選択してサンプルプールを構成し、このサンプルプールでLRUを使用してサンプル淘汰を行うことで、サンプル淘汰の正確性を向上させることができると理解できます.補足点:
LFUに関する2つのパラメータlfu-log-factorは個人的にcounter数値の各1値がカバーするアクセス周波数の範囲の大きさと理解されている.すなわち、lfu-log-factorが大きいほど、counterが1を増加するたびに対応する周波数が高くなることを示している.すなわち、counterの1がカバーする周波数密度は相対的に低く(区間が低い)、例えばlfu-log-factor=0の場合、counterは1値を増加するたびにデータクリック率を10回増加させる必要がある.一方、lfu-log-factor=10の場合、counterは1値増加ごとにデータクリック率を1000回追加する必要があるため、lfu-log-factor=0、counter=10の場合、counter=10の場合、counter=10の場合、counter=10の場合、counter=10の場合、counter=10の場合、counter=10の場合のクリック頻度は[n,n+1000]であるため、このlfu-log-factorは周波数密度とカバーする最大周波数範囲を比較する制御パラメータである.業務データの周波数が高くないが密度範囲に高い感度があり、例えば周波数10回と20回の区別が要求される場合、lfu-log-factorの設定を低くする必要がある.そうしないと、10回と20回の周波数データのcounter値が異なる.そうしないと、lfu-log-factorの設定が大きすぎると、10回と20回の2つのデータが最終的に得られるcounter値は同じで、区別できない.もちろん、周波数範囲が大きい場合、例えば最高周波数が100 M回に達し、0~100 M回の周波数範囲をサポートしたい場合は、lfu-log-factorパラメータを大きくする必要があります.そうしないと、lfu-log-factorが時間が経つと、1 M回の周波数の記録と100 M回の記録の最終的なcounter値は同じになります.もちろん、通常、システムのデフォルトのlfu-log-factor=10値を採用すれば、私たちのニーズの大部分を満たすことができます.
知識点を伸ばすLFUホットスポットkey
LFUアルゴリズムによれば、keyへの読み書きアクセスのたびに、24 bitsドメイン代表のアクセス時間とcounterが更新されるので、counter代表のアクセス頻度でどのkeyがホットスポットkeyであるかがわかり、redis自体が対応するアクセス方法を提供します.
./redis-cli --hotkeys
# Scanning the entire keyspace to find hot keys as well as
# average sizes per key type. You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).
[00.00%] Hot key '394cee9e41b3639e2b474e20625f6824f9575ad5_status' found so far with counter 5
[00.01%] Hot key '9f93b1c5694c5ebf880a12f56970d96997c562a4' found so far with counter 7
[00.01%] Hot key '5365aa52d43d3c53a023bc8bfdf2f1fa8f4c3abb' found so far with counter 5
[00.01%] Hot key '522e2c1fe2320956a02223bc9decac32c55942e9_status' found so far with counter 5
[00.01%] Hot key '9f00824926d424d1fc9cf7b492927b6e0087fa8c_status' found so far with counter 5
...
[04.51%] Hot key 'd7fb6b1a965a32b507dd9deeb46aca9dda1fe09e' found so far with counter 9
[05.21%] Hot key '2b99cb7c2eab96a9051ef4b4b717fc91f4f10ef1' found so far with counter 9
[10.49%] Hot key 'd8ae3b65d53539011563ddb53be307550b9761db' found so far with counter 9
[11.09%] Hot key 'c81ebe273b1bf947579bcae3034929442e512b57' found so far with counter 9
[31.41%] Hot key 'openfreetystvip.migu.cn4_' found so far with counter 14
[46.57%] Hot key 'cache.ott.ystenvod.itv.cmvideo.cn4_' found so far with counter 14
[49.35%] Hot key 'live.hcs.cmvideo.cn4_' found so far with counter 17
[62.08%] Hot key '3dbbe9a97c499839a3c2c7a21343a694b1324870' found so far with counter 10
[65.15%] Hot key '0d6199ba69f89f91cc6a19a7e7473ac79e28e34e' found so far with counter 10
[67.50%] Hot key 'all_join_url_domains' found so far with counter 255
[69.84%] Hot key 'wlanwm.12530.com4_' found so far with counter 10
[73.89%] Hot key 'freevod.nf.migu.cn4_' found so far with counter 14
[97.20%] Hot key 'ggv.cmvideo.cn4_' found so far with counter 18
-------- summary -------
Sampled 147878 keys in the keyspace!
hot key found with counter: 255 keyname: all_join_url_domains
hot key found with counter: 18 keyname: ggv.cmvideo.cn4_
hot key found with counter: 17 keyname: live.hcs.cmvideo.cn4_
hot key found with counter: 14 keyname: openfreetystvip.migu.cn4_
hot key found with counter: 14 keyname: cache.ott.ystenvod.itv.cmvideo.cn4_
hot key found with counter: 14 keyname: freevod.nf.migu.cn4_
hot key found with counter: 10 keyname: 3dbbe9a97c499839a3c2c7a21343a694b1324870
hot key found with counter: 10 keyname: 0d6199ba69f89f91cc6a19a7e7473ac79e28e34e
hot key found with counter: 10 keyname: wlanwm.12530.com4_
hot key found with counter: 9 keyname: 3cc24eceaaa143a8f8e264159226cd5f8b47504e
hot key found with counter: 9 keyname: a83149516404bb5a3357703bdb852d294fe2b177
hot key found with counter: 9 keyname: 14e41d6c72a0bc696c8a1d71b7f01b6e33e4e593
hot key found with counter: 9 keyname: 9cb88cee017fe11826a7745aaf1c26e8cac65047
hot key found with counter: 9 keyname: b1d0ae060c0c1041b1463835bf356ec7473d3b0f
hot key found with counter: 9 keyname: 92ef5bf31db3c5f4b61339aa8b0d8cd3dbc491ec
もちろん、メモリデータクリーンアップメカニズムをallkeys-lfuまたはvolatile-lfuに設定する必要があります.lfuに基づいてのみ、対応するkeyへのアクセス頻度が取得されるためです.
参照先:
https://redis.io/topics/lru-cache
https://yq.aliyun.com/articles/278922
https://yq.aliyun.com/articles/257459?spm=a2c4e.11153940.blogcont278922.8.5b914914Pnf5A5