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:

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ć?

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.

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.