web-dev-qa-db-ja.com

ElastiCache Redisでのスワップの回避

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

Redis ElastiCache BytesUsedForCache and Swap

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 |キャッシュクラスター| 2015年9月20日（日）11:13:05 GMT-400 |キャッシュノード0001が再起動されました

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

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

cache-instance-id |キャッシュクラスター| 2015年9月15日05:02:35 GMT-400 |キャッシュノード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が発生してメモリ使用量が増えることはないと考えています。

Cache.r3.2xlargeのmaxmemoryキャップは62495129600バイトですが、上限に達しましたが、reserved-memory）すぐに、Amazonが何らかの理由でOSスワップの設定を調整しない限り、ホストオペレーティングシステムがここで大量のスワップを使用するようにプレッシャーを感じるようになるのは奇妙に思えます。 ElastiCache/Redisでこれほど多くのスワップを使用する理由や、試してみる回避策はありますか？

memory-usageswapredisamazon-elasticache
14
Josh Kupershmidt

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

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

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

BytesUsedForCache

メモリ使用量の鋸歯状の低下は、cronジョブの時間に対応します。この2週間で、スワップの使用量は約45 MBに達しました（再起動する前に約5 GBに達しています）。また、ElastiCacheの[キャッシュイベント]タブは、これ以上のキャッシュ再起動イベントを報告しません。

はい、これは、ユーザーが自分で行う必要はなく、Redisが自分でこのクリーンアップを処理するのに十分スマートである必要があるという考えのようです。では、なぜこれが機能するのでしょうか。まあ、Redisは有効期限が切れたキーのクリーニングをほとんど行わず、代わりに GET中の期限切れのキーの削除 に依存しています。または、Redisがメモリがいっぱいであることを認識した場合、新しいSETごとにキーの削除を開始しますが、私の理論では、その時点でRedisはすでにホースされています。

7
Josh Kupershmidt

これが古い可能性があることは知っていますが、awsのドキュメントでこれに遭遇しました。

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

https://docs.aws.Amazon.com/AmazonElastiCache/latest/red-ug/ParameterGroups.Redis.html 彼らは、システムの最大メモリが62GBであると述べています（これは、maxmemory-policyが有効になるときです） ）変更できないこと。 AWSのRedisで何を交換しても、私たちは交換するようです。

1
tlindhardt