Redisはシステムキャッシングを行います。歴史的なキャッシング戦略とキャッシュコンテンツは、増加するビジネスボリュームにうまく適合していません。dbaを顔につけたさまざまなdissNの後、彼はゾンビの波をクリーンアップすることにしました。
しかし、不要なキーを削除した後、実際のメモリリリースはありません。Redis関連のドキュメントを確認してください。メモリを解放するコマンドはありません。ダッシュボードの割合を見ると頭が痛いです。。。
次の日を理解するためにいくつかの情報をチェックしてから、dbaの大物に相談しました。。。
当局は、
https：
//redis.io/topics/memory-optimizationがいくつかの点を要約した特定の理由を述べています：
これはRedis自体の問題ではなく、Redis自体がこれらのメモリを解放することをフリーと呼んでいます。これは、使用されている基になるCランタイムの問題です。
キーが削除されても、Redisは必ずしもメモリをオペレーティングシステムに解放（返却）するわけではありません。これはRedisにとって特別なことではありませんが、ほとんどのmalloc（）実装はこのように機能します。
たとえば、インスタンスには5 GBのデータがあり、2 GBのデータに相当するものを削除しても、used_memory_rssは約5 GBのままです。これは、基礎となるアロケータがメモリを簡単に解放できないためです。たとえば、削除されたキーのほとんどは、通常、まだ存在する他のキーと同じページに割り当てられます。
ただし、アロケータはスマートで、空きブロックのメモリを再利用できるため、5 GBのデータセットのうち2 GBを解放した後、キーを再び増やし始めると、used_memory_rssはあまり増加せずに安定していることがわかります。アロケータは基本的に、以前に（論理的に）解放された2GBのメモリを再利用しようとしています。
glibcに関する限り、128kを超えるメモリを割り当てる場合はmmapが使用され、ヒープに小さなメモリを割り当てる場合はbrk / sbrkが使用されます。mmapを通じて適用されたメモリは、freeを呼び出した直後にシステムに戻すことができますが、解放されたメモリがヒープ内の連続した大きなブロックでない限り、ヒープ内のメモリは必ずしも必要ではありません。
Redis自体にはメモリ管理メカニズムがありません。使用量の統計関数のみです。オブジェクトを作成する必要があるたびに、mallocを直接呼び出します。Redisのオブジェクトは基本的に小さいので、基本的にはヒープのメモリ内にあります。
解決策
は理由によって知ることができ、実際に注意を払う必要はありません。
特に、maxmemoryとmaxmemory_policyを定義した後は、メモリがいっぱいになった場合でも、redisは削除メカニズムスキームに従って不要なキーをいくつかクリアし、新しいキーを保存します。
ただし、システムのメモリ使用量が影響を受けている場合は、3つのオプションがあります。
- MEMORY PURGEコマンドを使用して、メモリを編成できます。（即座に、それはrssメモリ空間を少し解放することができます）
- アクティブデフラグ、ホットデフラグを開きます。（CPUを占有し、メインスレッドで実行し、CPU占有率を設定できます）
- 再起動します。
ソリューションを読んでから、dbaに相談してください。。。。