ElastiCache Redisでのスワップの回避

ElastiCache Redisインスタンスのスワッピングで継続的な問題が発生しています。Amazonには、スワップ使用率の急上昇に気付き、ElastiCacheインスタンスを単純に再起動する粗雑な内部監視機能が備わっているようです（これにより、キャッシュされたすべてのアイテムが失われます）。過去14日間のElastiCacheインスタンスのBytesUsedForCache（青い線）とSwapUsage（オレンジ色の線）のグラフは次のとおりです。

ElastiCacheインスタンスのリブートをトリガーするように見えるスワップ使用量の増加パターンを見ることができます。キャッシュされたすべてのアイテムが失われます（BytesUsedForCacheが0に低下します）。

ElastiCacheダッシュボードの[キャッシュイベント]タブには、対応するエントリがあります。

ソースID | タイプ| 日付| イベント

cache-instance-id | キャッシュクラスター| 2015年9月22日火曜日07:34:47 GMT-400 2015 | キャッシュノード0001が再起動しました

cache-instance-id | キャッシュクラスター| 2015年9月22日火曜日07:34:42 GMT-400 2015 | ノード0001でのキャッシュエンジンの再起動エラー

cache-instance-id | キャッシュクラスター| 日9月20日11:13:05 GMT-400 2015 | キャッシュノード0001が再起動しました

cache-instance-id | キャッシュクラスター| 木9月17 22:59:50 GMT-400 2015 | キャッシュノード0001が再起動しました

cache-instance-id | キャッシュクラスター| 2015年9月16日10:36:52 GMT-400 2015 | キャッシュノード0001が再起動しました

cache-instance-id | キャッシュクラスター| 2015年9月15日火曜日05:02:35 GMT-400 2015 | キャッシュノード0001が再起動しました

（以前のエントリを抜粋）

Amazonの主張：

SwapUsage-通常の使用では、MemcachedもRedisもスワップを実行するべきではありません

関連する（デフォルトではない）設定：

• インスタンスタイプ： cache.r3.2xlarge
• maxmemory-policy：allkeys-lru（以前は大きな違いなくデフォルトのvolatile-lruを使用していました）
• maxmemory-samples：10
• reserved-memory：2500000000
• インスタンスのINFOコマンドを確認するmem_fragmentation_ratioと、1.00〜1.05の間に表示されます

AWSサポートに連絡しましたが、あまり有益なアドバイスは得られませんでした。予約メモリをさらに高くすることを提案しました（デフォルトは0で、2.5 GBが予約されています）。このキャッシュインスタンスにはレプリケーションまたはスナップショットが設定されていないため、BGSAVEが発生してメモリ使用量が増えることはないと考えています。

maxmemorycache.r3.2xlargeのキャップは、62495129600バイトであり、そして我々はキャップを打つ（マイナス私たちがreserved-memory）すぐに、それがない限り、こんなに早くホストオペレーティングシステムがここにそんなにスワップを使用してプレッシャーを感じるだろうと私には奇妙に思えるし、 Amazonは、何らかの理由でOSのスワップ可能性の設定を上げました。ElastiCache / Redisでこれほど多くのスワップを使用する理由や、回避策を試してみてください。

ここには他に誰も答えがなかったので、私たちのために働いた唯一のものを共有すると思いました。まず、これらのアイデアはうまくいきませんでした：

• 大きなキャッシュインスタンスタイプ：現在使用しているcache.r3.2xlargeよりも小さなインスタンスで同じ問題が発生していました
• 微調整maxmemory-policy：volatile-lruもallkeys-lruも違いをもたらさない
• ぶつかる maxmemory-samples
• ぶつかる reserved-memory
• すべてのクライアントに有効期限を設定することを強制します。通常は最大24時間で、まれな発信者は最大7日間ですが、大半の発信者は1〜6時間の有効期限を使用します。

これが最終的に多くのことを助けてくれました：12時間ごとにジョブを実行し、10,000のチャンク（）のすべてのキーに対してSCANを実行しますCOUNT。以下は、同じインスタンスのBytesUsedForCacheです。以前と同じ設定で、以前よりもさらに使用量が多いcache.r3.2xlargeインスタンスです。

メモリ使用量のノコギリの低下は、cronジョブの時間に対応しています。この2週間で、スワップの使用量は最大で45 MB（再起動前に最大で5 GB）に達しました。また、ElastiCacheの[キャッシュイベント]タブでは、キャッシュ再起動イベントが報告されなくなりました。

はい、これはユーザーが自分でやる必要がないこと、そしてRedisがこのクリーンアップを単独で処理するのに十分な賢さを持っているべきであるという気がかりのようです。では、なぜこれが機能するのでしょうか？さて、Redisは期限切れのキーの多くまたはプリエンプティブなクリーニングを行わず、代わりにGETの間に期限切れのキーの削除に依存します。または、Redisがメモリがいっぱいであると認識すると、新しいSETごとにキーの削除を開始しますが、私の理論では、その時点でRedisはすでにホースで接続されています。

これは古いかもしれませんが、awsのドキュメントでこれに遭遇しました。

https://aws.amazon.com/elasticache/pricing/ 彼らは、r3.2xlargeに58.2gbのメモリがあると述べています。

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/ParameterGroups.Redis.html 彼らは、システムのmaxmemoryが62gb（これはmaxmemory-policyが起動するとき）であり、変更できないと述べています。 。AWSのRedisを使用して何を交換しようとも..