ElastiCache Redis'te takastan kaçınma

ElastiCache Redis örnek değişimimizle ilgili sürekli sorun yaşıyoruz. Amazon, takas kullanım artışlarını fark eden ve ElastiCache örneğini yeniden başlatan (böylece önbelleğe alınan tüm öğelerimizi kaybeden) bazı kaba dahili izlemeye sahip gibi görünüyor. ElastiCache örneğimizde son 14 gün içinde BytesUsedForCache (mavi çizgi) ve SwapUsage (turuncu çizgi) grafiği aşağıdadır:

ElastiCache örneğimizin yeniden başlatılmasını tetikleyen görünen takas kullanım modelini görebilirsiniz, burada önbelleğe alınan tüm öğelerimizi kaybederiz (BytesUsedForCache 0'a düşer).

ElastiCache kontrol panelimizin 'Önbellek Olayları' sekmesinde karşılık gelen girişler bulunur:

Kaynak Kimliği | Türü | Tarih | Etkinlik

önbellek örneği kimliği | önbellek kümesi | Sal 22 Eyl 07:34:47 GMT-400 2015 | Önbellek düğümü 0001 yeniden başlatıldı

önbellek örneği kimliği | önbellek kümesi | Sal 22 Eyl 07:34:42 GMT-400 2015 | 0001 düğümünde önbellek motoru yeniden başlatılırken hata oluştu

önbellek örneği kimliği | önbellek kümesi | Paz 20 Eyl 11:13:05 GMT-400 2015 | Önbellek düğümü 0001 yeniden başlatıldı

önbellek örneği kimliği | önbellek kümesi | Perş 17 Eyl 22:59:50 GMT-400 2015 | Önbellek düğümü 0001 yeniden başlatıldı

önbellek örneği kimliği | önbellek kümesi | Çar 16 Eyl 10:36:52 GMT-400 2015 | Önbellek düğümü 0001 yeniden başlatıldı

önbellek örneği kimliği | önbellek kümesi | Sal 15 Eyl 05:02:35 GMT-400 2015 | Önbellek düğümü 0001 yeniden başlatıldı

(önceki girişleri kırp)

Amazon iddia ediyor :

SwapUsage - normal kullanımda, ne Memcached ne de Redis takas gerçekleştirmemelidir

Alakalı (varsayılan olmayan) ayarlarımız:

• Örnek türü: cache.r3.2xlarge
• maxmemory-policy: allkeys-lru (daha önce çok fazla fark olmaksızın varsayılan uçucu-lru kullanıyorduk)
• maxmemory-samples: 10
• reserved-memory: 2500000000
• Örnekteki INFO komutunu kontrol ederken, mem_fragmentation_ratio1.00 ile 1.05 arasında görüyorum

AWS desteğiyle iletişime geçtik ve çok yararlı bir tavsiye almadık: ayrılmış belleği daha da artırmayı önerdiler (varsayılan 0 ve 2,5 GB ayrılmış). Biz bu önbellek örneği için ayarlanmış çoğaltma veya anlık görüntüleri yok, bu yüzden hiçbir BGSAVE olması ve ek bellek kullanımına neden olması gerektiğine inanıyorum.

maxmemoryBir cache.r3.2xlarge kapağı 62495129600 bayt ve bizim kap isabet (eksi bizim rağmen reserved-memory) hızlı, bu sürece çok hızlı bir şekilde ana işletim sistemi burada çok fazla takas kullanmak için baskı hissediyorum bana garip görünüyor ve Amazon bir nedenden dolayı işletim sistemi swappiness ayarlarını başlattı. ElastiCache / Redis'te neden bu kadar çok takas kullanımına neden olacağımız konusunda herhangi bir fikir ya da deneyebileceğimiz bir çözüm var mı?

Kimsenin burada cevabı olmadığı için bizim için işe yarayan tek şeyi paylaşacağımı düşündüm. İlk olarak, bu fikirler mi değil çalışır:

• daha büyük önbellek örneği türü: şu anda kullandığımız cache.r3.2xlarge öğesinden daha küçük örneklerde aynı sorunu yaşıyordu
• tweaking maxmemory-policy: ne uçucu-lru ne de allkeys-lru herhangi bir fark yaratmadı
• Darbe maxmemory-samples
• Darbe reserved-memory
• tüm müşterileri, genellikle 7 güne kadar izin veren birkaç nadir arayanla, ancak 1-6 saatlik sona erme süresini kullanan arayanların büyük çoğunluğuyla, genellikle en fazla 24 saat olan bir sona erme süresi belirlemeye zorlar.

Sonunda çok yardımcı olan şey şuydu: her on iki saatte bir iş yapmak ve bu , 10.000 parçadaki ( ) tüm tuşlar üzerinde bir SCAN çalıştırmak COUNT. İşte aynı örneğin BytesUsedForCache'i, daha öncekiyle aynı ayarlarla, eskisinden bile daha ağır kullanımda hala bir cache.r3.2xlarge örneği:

Bellek kullanımındaki testere dişi düşüşleri cron işinin zamanlarına karşılık gelir. Bu iki haftalık süre zarfında takas kullanımımız ~ 45 MB'da (daha önce yeniden başlamadan önce ~ 5 GB'da) çıktı. Ve ElastiCache'deki Önbellek Olayları sekmesi, artık Önbellek Yeniden Başlatma olayları bildirmez.

Evet, bu, kullanıcıların kendi başlarına yapmaları gerekmediği ve Redis'in bu temizliği kendi başına halledebilecek kadar akıllı olması gerektiği gibi görünüyor. Peki bu neden çalışıyor? Redis, süresi dolmuş anahtarların fazla veya herhangi bir önleyici temizliğini yapmaz, bunun yerine GET'ler sırasında süresi dolmuş anahtarların tahliye edilmesine güvenir . Veya, Redis hafızanın dolu olduğunu fark ederse, her yeni SET için anahtarlar çıkarmaya başlayacaktır, ancak teorim şu anda Redis'e zaten ev sahipliği yapılıyor.

Bunun eski olabileceğini biliyorum ama aws belgelerinde bununla karşılaştım.

https://aws.amazon.com/elasticache/pricing/ r3.2xlarge öğesinin 58.2 gb belleğe sahip olduğunu belirtirler.

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/ParameterGroups.Redis.html Sistemin maksimum belleğinin 62gb olduğunu (bu, maksimum bellek politikasının devreye girdiği zamandır) ve değiştirilemeyeceğini belirtir. . AWS'deki Redis ile ne olursa olsun değiş tokuş yapacağız.