Właściwe dobranie wartości parametru maxmemory w Redis: rezerwy pamięci na dane i działanie systemu

Co faktycznie ogranicza wartość maxmemory

maxmemory umieszcza w Redis Open Source plik Próg eksmisji Nie ma sztywnego limitu dla procesu Redis ani jego kontenera. Gdy zużycie pamięci istotne z punktu widzenia zarządzania pamięcią osiągnie próg, Redis próbuje usunąć klucze w zależności od wybranej polityki. W przypadku polityki bez usuwania danych (eviction) polecenia zapisu powodujące zwiększenie zużycia pamięci mogą zamiast tego zakończyć się niepowodzeniem.

Wskaźnik used_memory obejmuje pamięć zajmowaną przez Redis za pośrednictwem jego alokatora. Obejmuje to nie tylko same wartości Twojej aplikacji, ale także struktury administracyjne i inne obszary pamięci Redis. Kto wyznacza limit wyłącznie na podstawie szacowanego rozmiaru danych użytkowych, nie uwzględnia tego obciążenia dodatkowego.

Część z used_memory jest wyłączone z egzaminu Eviction: mem_not_counted_for_evict zawiera w szczególności tymczasowe bufory replikacji i AOF. Bufory te i tak wymagają pamięci fizycznej. Wartość ta jest już zawarta w used_memory jest już uwzględniona w tym wskaźniku i dlatego nie można jej dodawać do niego po raz drugi bez sprawdzenia.

Nie oznacza to jednak, że wszystkie pamięci klienckie lub replikacyjne są wyłączone z obliczeń dotyczących usuwania danych. Pojedyncze duże polecenie może ponadto tymczasowo znacznie przekroczyć ten próg. Jeśli ustawisz maxmemory przy pełnym limicie kontenerów nie pozostaje żadna pewna rezerwa na takie wahania i dodatkowe zużycie zasobów procesowych.

W związku z tym podczas planowania należy osobno odpowiedzieć na dwa pytania: ile miejsca zajmują zestaw danych i obciążenie Redis w ramach zarządzania pamięcią? I ile dodatkowej rezerwy potrzebuje całe środowisko uruchomieniowe? Dopiero połączenie obu tych perspektyw pozwala stwierdzić, czy wybrana wartość poniżej rzeczywistego limitu pamięci jest realistyczna.

RSS, alokator i szczyty trwałości

Po wystąpieniu szczytowego obciążenia może used_memory spadają, podczas gdy used_memory_rss pozostaje wysoki: Redis co prawda zwolnił pamięć za pośrednictwem alokatora, ale nie została ona koniecznie natychmiast zwrócona do systemu operacyjnego. RSS opisuje pamięć rezydentną procesu z punktu widzenia systemu operacyjnego i dlatego stanowi inny poziom obserwacji.

Załóżmy, że podczas jakiejś operacji pamięć podręczna znacznie się powiększa, a po jej zakończeniu wygasa wiele kluczy. Mniejsza wartość pamięci Redis nie oznacza automatycznie, że kontener natychmiast odzyskuje odpowiednią ilość wolnej pamięci. W związku z tym przy kolejnym szczycie obciążenia ważniejszy jest przebieg rzeczywistego zużycia niż założenie, że zwolniona pamięć natychmiast znika.

Również mem_fragmentation_ratio nie jest to wyłącznie wskaźnik procentowy fragmentacji. Wskaźnik ten obejmuje również inne elementy procesu; w celu przeprowadzenia analizy przyczyn należy go rozpatrywać łącznie z dostępnymi allocator_*-wskaźniki oraz historię obciążenia. Na podstawie pojedynczego wskaźnika nie można określić ogólnie obowiązującej rezerwy.

W przypadku migawek RDB i przepisywania plików AOF Redis tworzy proces potomny. Poprzez Kopiowanie przy zapisie Może zaistnieć dodatkowe zapotrzebowanie na fizyczne strony pamięci, jeśli podczas cyklu utrwalania strony ulegną zmianie. Im większe i bardziej rozłożone w czasie jest obciążenie zapisem w tym okresie, tym ważniejsze jest uwzględnienie tej fazy podczas planowania pojemności.

Administracja Redis podaje, że w skrajnych przypadkach aplikacje intensywnie wykorzystujące operacje zapisu mogą wymagać nawet dwukrotnie większej ilości pamięci niż zwykle. Jest to ostrzeżenie dotyczące niekorzystnych warunków obciążenia, a nie ogólny mnożnik. Nie należy również po prostu sumować wartości RSS procesów nadrzędnych i podrzędnych: wspólnie używane strony byłyby liczone wielokrotnie; istotne jest odpowiednie monitorowanie hosta lub kontenera.

Repliki wymagają osobnych budżetów

Replika zasadniczo przechowuje kopię zbioru danych i wymaga do tego własnej pamięci RAM. Serwer główny i replika są zatem oddzielnymi konsumentami pamięci: rezerwa na serwerze głównym nie zwalnia miejsca w kontenerze repliki. Należy planować każdy element sieci w oparciu o jego własne ograniczenia i obserwowane zużycie.

Domyślnie replika ignoruje skonfigurowane maxmemory w przypadku własnych operacji usuwania. Serwer główny podejmuje decyzję o usunięciu kluczy i replikuje operacje usuwania. Niemniej jednak stany pamięci mogą się różnić, na przykład z powodu rozbieżności w buforach lub strukturach danych; ta sama wartość progowa nie gwarantuje zatem identycznego obciążenia.

W przypadku Promocja dawna replika przejmuje rolę serwera głównego. Należy zatem sprawdzić nie tylko, czy jako kopia odczytowa dysponuje wystarczającą ilością miejsca, ale także czy jej limit pamięci i konfiguracja pozwalają na działanie w roli serwera głównego. Obejmuje to w szczególności obciążenie zapisem, połączenia replikacyjne oraz obowiązujące wówczas zasady usuwania danych.

Od wersji Redis 7.0 bufor replikacji i lista zadań do replikacji współdzielą pamięć. mem_clients_slaves może zatem wskazywać wartość zerową, mimo że replikacja zajmuje pamięć. Nie należy interpretować tego pola w oderwaniu od kontekstu ani bez sprawdzenia sumować zaległości i bufora replikacji jako całkowicie odrębnych obszarów.

Oprócz zużycia pamięci istotne znaczenie dla działania ma również szybkość przesyłania danych: opóźnienie ma inny charakter niż wielkość bufora. Jak można sklasyfikować stan replikacji i zaległość, wyjaśnia artykuł poświęcony Przesunięcie replikacji Redis. Jednak dla rezerwy pamięci decydujące znaczenie mają rzeczywiste krzywe zużycia każdej instancji.

Rejestrowanie pamięci na trzech poziomach

Do wymiarowania potrzebne są wartości z Redis oraz ze środowiska, w którym działa instancja. Te poziom obserwacji decyduje o tym, co oznacza dana liczba: przydział pamięci przez alokator, RSS procesu i zużycie kontenerów to różne wielkości, których nie da się po prostu zsumować.

Z INFO memory odczytujesz między innymi wartości przechowywane w Redis oraz skonfigurowaną politykę. MEMORY STATS uzupełnia szczegóły dotyczące alokacji pamięci. Oba polecenia mają charakter odczytowy; to, które pola są dostępne, zależy od wersji Redis, uprawnień oraz oferty hostingowej.

Aby sprawdzić zgodność czasową, sprawdź również INFO persistence na aktywność trwałościową i dostępne wartości Copy-on-Write. INFO replication wyświetla rolę i stan replikacji. Należy wprowadzić te dane oddzielnie dla serwera głównego i repliki, aby podczas analizy można było rozróżnić zmianę roli od synchronizacji.

Pojedyncza wartość nie odzwierciedla ani typowego obciążenia, ani niezbędnej rezerwy na szczytowe obciążenia. Dlatego należy gromadzić szeregi czasowe dotyczące normalnej pracy, szczytów zapisu oraz procesów działających w trybie ciągłym i przypisywać do nich zużycie zasobów przez hosty lub kontenery obserwowane w tym samym czasie. W ten sposób można również rozpoznać, czy wysoka wartość RSS towarzyszy aktualnemu obciążeniu, czy też utrzymuje się po wcześniejszym szczycie.

Obliczenie realistycznego budżetu na pamięć masową

Punktem wyjścia jest faktycznie obowiązująca Limit pamięci: W przypadku kontenera może ona być mniejsza niż ilość pamięci RAM hosta. Sprawdź, jakie inne procesy i komponenty systemu wykorzystują ten sam limit. To, co jest dla nich zarezerwowane, nie jest dostępne dla Redis do przechowywania danych ani obsługi szczytowego obciążenia.

Następnie odjąć rezerwy na dodatkowe efekty RSS i alokatora, bufory nie uwzględnione w procesie eviccji, szczyty trwałości oraz margines bezpieczeństwa. Wynikiem jest wstępna wartość maxmemory-Budżet, a nie równanie wewnętrzne Redis. Rezerwy muszą odpowiadać temu samemu limitowi oraz realistycznym, występującym jednocześnie stanom obciążenia.

Przykład obliczeniowy, nie jest to pomiar: Z limitu kontenera wynoszącego 8 GiB odlicza się 0,5 GiB dla innych odbiorców, 0,5 GiB na dodatkowe efekty RSS, 0,5 GiB na bufory wyłączone z obliczeń dotyczących usuwania, 1 GiB na szczytowy wzrost zapotrzebowania na pamięć oraz 0,5 GiB na margines bezpieczeństwa. Jako wartość wstępną pozostaje 5 GiB na maxmemory.

Liczby te nie stanowią zalecenia dotyczące konkretnej instancji. Przykład ten zakłada, że przypisane rezerwy opisują dodatkowe, niepokrywające się wkłady do granicy kontenera. Zwłaszcza w przypadku operacji typu persistence wspólne strony pamięci i mechanizm copy-on-write mogą utrudniać przyporządkowanie; zwykłe zsumowanie wartości RSS procesu nadrzędnego i podrzędnego byłoby w tym przypadku nieodpowiednie.

Unikaj Podwójne zliczenia: mem_not_counted_for_evict jest już zawarte w used_memory. Jeśli opierasz się na całkowitym zużyciu RSS lub kontenerów, nie wolno ci ponownie dodawać tej części bufora bez sprawdzenia. W pozostałym budżecie evicji musi zmieścić się zarówno zbiór danych, jak i uwzględnione obciążenie Redis; następnie sprawdź to podejście przy porównywalnym obciążeniu.

Porównanie praktycznego stosowania polityk eksmisyjnych

Die Polityka eksmisji określa, w jaki sposób Redis reaguje na polecenia zapisu w przypadku niedoboru pamięci. Nie zastępuje to planowania pojemności: nawet odpowiednia polityka wymaga rezerw wykraczających poza obliczenia dotyczące usuwania danych. Decyzja zależy przede wszystkim od tego, które klucze mogą zostać utracone oraz od tego, jak aplikacja reaguje na błędy.

W przypadku samej pamięci podręcznej można allkeys-lru są odpowiednie, jeśli usunięte wpisy można odtworzyć z innego źródła. W Redis algorytm LRU stanowi przybliżenie, a nie dokładne globalne sortowanie. Częste usuwanie wpisów może powodować większą liczbę dostępów do zaplecza; dlatego ważne są nie tylko wolne bajty, ale także współczynnik trafień w pamięci podręcznej oraz wydajność zaplecza.

W przypadku danych, których nie można dowolnie usunąć, noeviction Inna decyzja: aplikacja musi umieć radzić sobie z nieudanymi operacjami zapisu, zamiast domyślnie zakładać, że zapis przebiegł pomyślnie. Ta zasada nie dotyczy ani trwałości danych, ani ochrony przed błędem OOM na poziomie systemu operacyjnego lub kontenera.

W przypadku zbiorów mieszanych należy Dyscyplina TTL kluczowe: Jedno volatile-*-Polityka może wybierać wyłącznie klucze z określonym czasem wygaśnięcia. Jeśli jest zbyt mało odpowiednich kandydatów, sam parametr TTL nie chroni przed błędami zapisu. Należy zatem sprawdzić, czy pamięć podręczna i ważne dane rzeczywiście powinny korzystać z tej samej instancji i tej samej strategii obsługi błędów.

Dane dotyczące sesji uwidaczniają konflikt celów: usunięcie wpisu może oznaczać dla użytkowników utratę stanu sesji, nawet jeśli aplikacja nadal działa pod względem technicznym. Przed wyborem polityki należy ocenić konsekwencje i możliwość przywrócenia danych; dodatkowe informacje na ten temat można znaleźć w artykule poświęconym Zarządzanie sesjami za pomocą Redis i innych systemów pamięci.

Sprawdzić rezerwę pod obciążeniem

Wartość obliczona dla maxmemory To na razie punkt wyjścia. Przetestuj to w izolowanym środowisku z podobną wersją Redis, strukturą danych i limitem pamięci. Obciążenie powinno odzwierciedlać nie tylko zwykłą pracę, ale także szczyty zapisu oraz fazy, w których jednocześnie aktywne są funkcje trwałości danych i replikacji.

Zwróć przy tym uwagę na Zużycie pojemników lub odpowiednią metrykę hosta, a także wartości przechowywane w Redis. Należy odnotować, kiedy trwa tworzenie migawki lub przepisywanie pliku AOF oraz czy replika jest synchronizowana. Kluczowe znaczenie ma to, jak duża jest różnica w stosunku do rzeczywistego limitu podczas nakładających się zdarzeń, a nie tylko w okresie bezczynności po ich zakończeniu.

Za pomocą polecenia odczytu INFO stats Rejestrujesz między innymi licznik wyrzucania. Analizuj zmiany tych wartości w poszczególnych przedziałach czasowych: sam wysoki poziom historyczny nie wskazuje, czy w danym momencie klucze są wyrzucane. Porównaj rosnącą liczbę wyrzucanych elementów z trafieniami w pamięci podręcznej i obciążeniem serwera, o ile Twoja aplikacja udostępnia te dane.

Ponadto należy rejestrować w aplikacji odpowiedzi Redis OOM oraz zdarzenia związane z pamięcią w kontenerach na platformie. Oba rodzaje błędów mogą wystąpić przy podobnym obciążeniu, ale dotyczą różnych limitów. Dlatego system alarmowy powinien uwzględniać zarówno dostępną rezerwę, jak i zaobserwowane błędy oraz ich przebieg w czasie.

Po wprowadzeniu zmian w zestawie danych, obciążeniu zapisem lub mechanizmach trwałości i replikacji należy powtórzyć ocenę. Również awans zmienia rolę repliki, a tym samym profil obciążenia, który należy sprawdzić. Wyniki uzyskane w środowisku izolowanym nie zastępują ciągłej obserwacji instancji produkcyjnych.

Precyzyjne zawężanie zakresu problemów z pamięcią

Czy wartość RSS procesu rośnie, podczas gdy used_memory jeśli tak się stanie, najpierw sprawdź przebieg i poprzednie obciążenie. Zwolniona pamięć nie musi od razu wracać do systemu operacyjnego. Wskaźniki alokatora z INFO memory pomagają w interpretacji; sam współczynnik fragmentacji nie świadczy ani o wycieku pamięci, ani o jego przyczynie.

Następnie sprawdź, czy wzrost ten zbiega się czasowo z przebiegiem persystencyjnym lub synchronizacją. Służą do tego INFO persistence oraz INFO replication. Pojedyncza wartość dla bufora nieobjętego procedurą eviction opisuje jedynie aktualny stan. Aby oszacować rezerwę, potrzebne są pomiary z różnych faz obciążenia i zakłóceń.

W przypadku Odpowiedź Redis OOM Sprawdź skonfigurowaną politykę oraz to, czy dostępne są odpowiednie klucze do usunięcia danych. W szczególności polecenie zapisu może zakończyć się niepowodzeniem, jeśli Redis nie będzie w stanie zwolnić wystarczającej ilości miejsca zgodnie z obowiązującą polityką. Aplikacja musi obsłużyć ten błąd, zamiast zakładać, że operacja zapisu zakończy się powodzeniem.

W przypadku przerwania działania kontenera z powodu braku pamięci należy natomiast przeanalizować zdarzenia platformy oraz zużycie w porównaniu z limitem kontenera. Należy uwzględnić szczytowe obciążenia związane z trwałością danych oraz inne procesy zużywające pamięć w kontenerze. Błąd OOM w Redis i błąd OOM w kontenerze nie są tożsame: limit pamięci zewnętrznej może zostać osiągnięty nawet bez uprzedniej odpowiedzi OOM z Redis.

maxmemory-clients może dodatkowo ograniczyć ilość pamięci zajmowanej przez klientów. Jeśli pamięć danego klienta przekroczy skonfigurowany próg, Redis może rozłączyć klientów o wysokim zużyciu pamięci; aplikacje muszą radzić sobie z przerwami w połączeniu. Ustawienie to nie ogranicza wszystkich połączeń replikacyjnych i nie zastępuje ani ogólnego limitu, ani monitorowania szczytów obciążenia bufora.

Rozważenie opcji hostingu i architektury Redis

Jeśli obserwowana rezerwa przy reprezentatywnym obciążeniu okazuje się niewystarczająca, rozsądnym rozwiązaniem może być zwiększenie pamięci RAM, o ile zbiór danych i obciążenie mają zasadniczo pozostać na jednej instancji. Dodatkowa pojemność musi jednak mieścić się w faktycznie obowiązującym limicie hosta lub kontenera. Sam większy limit Redis nie zapewnia dodatkowej pamięci fizycznej.

Alternatywnie można Rozkład obciążenia rozłożyć zapotrzebowanie na pamięć i operacje zapisu na kilka instancji. Wymaga to odpowiedniego podziału danych oraz osobnego budżetu dla każdej z zaangażowanych instancji. Repliki nie są przy tym równoznaczne z podziałem zbioru danych: zasadniczo przechowują one kopię i wymagają do tego własnej pamięci RAM.

Pomocna może być również zmiana architektury, na przykład oddzielenie pamięci podręcznej tolerującej straty od danych o bardziej rygorystycznych wymaganiach. Pozwala to na niezależny dobór zasad i pojemności. Jednak ani to oddzielenie, ani zwiększenie pamięci RAM, ani rozłożenie obciążenia nie gwarantują, że w przyszłości nie wystąpią szczyty związane z trwałością danych, replikacją i zapisem.

Porównując Ograniczenia dostawców Należy ustalić, czy podana wartość odnosi się do limitu kontenera, limitu instancji czy też innego limitu zdefiniowanego w bazie danych. Należy również zapytać, jakie wskaźniki i polecenia diagnostyczne są dostępne, czy repliki są uwzględnione w zarezerwowanej przestrzeni dyskowej oraz jaki wpływ ma promocja na dostępne zasoby.

Redis Open Source, oprogramowanie Redis i Redis Cloud należy traktować oddzielnie. W przypadku oprogramowania Redis obowiązuje udokumentowany limit bazy danych obejmujący zarówno fragmenty główne, jak i replikacyjne; nie wynika z tego żadna odpowiednia zasada dotycząca pojedynczej instancji Redis OSS. W przypadku Redis Cloud i innych ofert hostingowych należy sprawdzić konkretne warunki danego produktu, zamiast bezkrytycznie przyjmować tę definicję.