Unikanie zamiany na ElastiCache Redis

Mamy ciągłe problemy z wymianą instancji ElastiCache Redis. Wydaje się, że Amazon ma pewne surowe wewnętrzne monitorowanie, które zauważa skoki użycia wymiany i po prostu restartuje instancję ElastiCache (tracąc w ten sposób wszystkie nasze buforowane elementy). Oto wykres BytesUsedForCache (niebieska linia) i SwapUsage (pomarańczowa linia) w naszym wystąpieniu ElastiCache z ostatnich 14 dni:

Redis ElastiCache BytesUsedForCache i Swap

Widać wzorzec rosnącego użycia wymiany, który zdaje się wyzwalać ponowne uruchomienie instancji ElastiCache, w której tracimy wszystkie nasze buforowane elementy (BytesUsedForCache spada do 0).

Karta „Zdarzenia pamięci podręcznej” naszego pulpitu nawigacyjnego ElastiCache zawiera odpowiednie wpisy:

ID źródła | Wpisz | Data | Zdarzenie

cache-instance-id | klaster pamięci podręcznej | Wt 22 września 07:34:47 GMT-400 2015 | Węzeł pamięci podręcznej 0001 został zrestartowany

cache-instance-id | klaster pamięci podręcznej | Wt 22 września 07:34:42 GMT-400 2015 | Błąd podczas ponownego uruchamiania silnika pamięci podręcznej w węźle 0001

cache-instance-id | klaster pamięci podręcznej | Niedz. 20 wrz 11:13:05 GMT-400 2015 | Węzeł pamięci podręcznej 0001 został zrestartowany

cache-instance-id | klaster pamięci podręcznej | Cz 17 Wrz 22:59:50 GMT-400 2015 | Węzeł pamięci podręcznej 0001 został zrestartowany

cache-instance-id | klaster pamięci podręcznej | Śr. 16 wrz 10:36:52 GMT-400 2015 | Węzeł pamięci podręcznej 0001 został zrestartowany

cache-instance-id | klaster pamięci podręcznej | Wt 15 września 05:02:35 GMT-400 2015 | Węzeł pamięci podręcznej 0001 został zrestartowany

(wycinaj wcześniejsze wpisy)

Amazon twierdzi :

SwapUsage - w normalnym użyciu ani Memcached, ani Redis nie powinny wykonywać swapów

Nasze odpowiednie (inne niż domyślne) ustawienia:

Rodzaj wystąpienia: cache.r3.2xlarge
maxmemory-policy: allkeys-lru (wcześniej używaliśmy domyślnego volatile-lru bez większych różnic)
maxmemory-samples: 10
reserved-memory: 2500000000
Sprawdzam polecenie INFO w instancji, widzę mem_fragmentation_ratiomiędzy 1,00 a 1,05

Skontaktowaliśmy się z obsługą AWS i nie otrzymaliśmy wiele przydatnych porad: zasugerowali zwiększenie pamięci zarezerwowanej jeszcze wyżej (domyślnie jest 0, a mamy 2,5 GB zarezerwowanej). Nie mamy skonfigurowanych replikacji ani migawek dla tej instancji pamięci podręcznej, więc uważam, że nie powinny wystąpić żadne BGSAVE, powodujące dodatkowe użycie pamięci.

maxmemoryCap o cache.r3.2xlarge jest 62495129600 bajtów, i mimo, że nasz hit cap (minus nasz reserved-memory) szybko, wydaje mi się dziwne, że system operacyjny hosta czułby się zmuszony użyć tyle zamianę tutaj, i tak szybko, chyba Amazon z jakiegoś powodu poprawił ustawienia zamiany systemu operacyjnego. Jakieś pomysły, dlaczego powodujemy tak duże użycie wymiany w ElastiCache / Redis, lub obejście, które możemy wypróbować?

— Josh Kupershmidt
źródło

Odpowiedzi:

Ponieważ nikt inny nie miał tutaj odpowiedzi, pomyślałem, że podzielę się jedyną rzeczą, która dla nas zadziałała. Po pierwsze, te pomysły nie zadziałały:

większy typ instancji pamięci podręcznej: miał ten sam problem w mniejszych instancjach niż pamięć podręczna. r3.2xlarge, którego używamy teraz
poprawianie maxmemory-policy: ani lotne-lru, ani małpy-lru nie miały znaczenia
podskakuje maxmemory-samples
podskakuje reserved-memory
zmuszając wszystkich klientów do ustawienia czasu wygaśnięcia, zwykle najwyżej 24 godziny z kilkoma rzadkimi osobami dzwoniącymi, co pozwala na maksymalnie 7 dni, ale zdecydowana większość osób dzwoniących używa okresu ważności 1-6 godzin.

Oto, co w końcu bardzo pomogło: uruchamianie zadania co dwanaście godzin, które uruchamia SKANOWANIE na wszystkich kluczach we fragmentach ( COUNT) 10.000. Oto BytesUsedForCache tej samej instancji, wciąż instancja cache.r3.2xlarge przy jeszcze większym użyciu niż wcześniej, z takimi samymi ustawieniami jak wcześniej:

Zmniejszenie zużycia pamięci przez piłokształtne odpowiada czasowi pracy crona. W ciągu dwóch tygodni nasze zużycie wymiany osiągnęło poziom ~ 45 MB (zostało uzupełnione o ~ 5 GB przed ponownym uruchomieniem). Karta Zdarzenia pamięci podręcznej w ElastiCache nie zgłasza więcej zdarzeń ponownego uruchomienia pamięci podręcznej.

Tak, wydaje się to kłopotem, którego użytkownicy nie powinni robić sami, i że Redis powinna być wystarczająco inteligentna, aby sama poradzić sobie z tym oczyszczaniem. Dlaczego to działa? Cóż, Redis nie robi dużo ani uprzedzającego czyszczenia wygasłych kluczy, zamiast tego polega na eksmisji wygasłych kluczy podczas GET-ów . Lub, jeśli Redis zorientuje się, że pamięć jest pełna, zacznie eksmitować klucze dla każdego nowego ZESTAWU, ale moja teoria jest taka, że w tym momencie Redis jest już ukryty.

— Josh Kupershmidt
źródło

Josh, zastanawiasz się, czy masz jakieś postępy w pracy nad tym problemem? Napotykamy na podobną sytuację. Czy nadal używasz tego samego rozwiązania, co wcześniej?

— Andrew C

@AndrewC nadal mamy tę samą instancję pamięci podręcznej, z podobnym zachowaniem piłokształtnych ze skanów SCAN i tylko kilkoma skokowymi skokami użycia wymiany w ciągu ostatnich 3 miesięcy - nie jest tak źle, jak napisałem w pytaniu, głównie z powodu odciążenia aktywność poza tym wystąpieniem, a SCANpraca w odpowiedzi wciąż prowokuje porządki. AWS oferuje teraz funkcje klastra Redis, które założę się, że pomogłyby w przypadku intensywnego użytkowania.

— Josh Kupershmidt

dobrze słyszeć; zastosowaliśmy podobne podejście do odciążania pamięci podręcznej na osobne pamięci podręczne. Jaka jest twoja hipoteza na temat tego, w jaki sposób klastrowanie pomogłoby zmniejszyć wykorzystanie swapów? Tylko poprzez zmniejszenie całkowitego obciążenia?

— Andrew C

@JoshKupershmidt twój mój bohater.

— Moriarty,

Wiem, że to może być stare, ale natknąłem się na to w dokumentacji aws.

https://aws.amazon.com/elasticache/pricing/ Twierdzą, że r3.2xlarge ma 58,2 GB pamięci.

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/ParameterGroups.Redis.html Stwierdzają, że maksymalna pamięć systemowa wynosi 62 GB (wtedy zaczyna się polityka maxmemory) i nie można jej zmienić . Wydaje się, że bez względu na to, co z Redis w AWS wymienimy.

— tlindhardt
źródło

AWS ma rację - mówią, że maxmemory to 62495129600bajty, czyli dokładnie 58,2 GiB. Strona z cenami, którą podłączyłeś, ma pamięć w jednostkach GiB, a nie GB. maxmemoryParametr nie jest przypuszczalnie modyfikowalny ponieważ istnieją lepsze gałki przewidziane przez Redis, takie jak reserved-memory(mimo, że nie udało mi pomóc ...), które można modyfikować, a AWS nie chce Błędna konfiguracja węzła przez np mówienie Redis do używają więcej pamięci niż faktycznie ma maszyna wirtualna Elasticache.

— Josh Kupershmidt