Udostępnij za pośrednictwem

Rozwiązywanie problemów z opóźnieniem i przekroczeniami limitu czasu usługi Azure Cache for Redis

  • Dotyczy: ✅ Azure Cache for Redis

Operacja klienta usługi Azure Cache for Redis, która nie otrzymuje terminowej odpowiedzi, może spowodować duże opóźnienie lub wyjątek przekroczenia limitu czasu. W tym artykule wyjaśniono, jak rozwiązywać typowe problemy, które mogą prowadzić do dużego opóźnienia i przekroczenia limitu czasu.

Operacja może napotkać problemy lub upłynąć limit czasu na różnych etapach. Źródło problemu pomaga określić przyczynę i środki zaradcze. Ten artykuł jest podzielony na problemy po stronie klienta i po stronie serwera.

Problemy po stronie klienta

Problemy po stronie serwera

Rozwiązywanie problemów po stronie klienta

Następujące problemy po stronie klienta mogą mieć wpływ na opóźnienia i wydajność oraz prowadzić do przekroczenia limitu czasu.

Duża liczba połączeń klientów

Żądania klientów dotyczące połączeń klientów poza maksymalną wartością pamięci podręcznej mogą zakończyć się niepowodzeniem. Wysokie połączenia klientów mogą również powodować duże obciążenie serwera podczas przetwarzania powtarzających się ponownych prób nawiązania połączenia.

Wysokie połączenia klienta mogą wskazywać na wyciek połączenia w kodzie klienta. Połączenia mogą nie być ponownie używane lub zamknięte prawidłowo. Przejrzyj kod klienta pod kątem użycia połączeń.

Jeśli duża liczba połączeń jest prawidłowa i wymagane są połączenia klienckie, może być konieczne uaktualnienie pamięci podręcznej do rozmiaru z wyższym limitem połączeń. Sprawdź, czy metryka Maksymalna agregacja dla połączonych klientów jest bliska lub większa niż maksymalna liczba dozwolonych połączeń dla rozmiaru pamięci podręcznej. Aby uzyskać więcej informacji na temat określania rozmiaru na połączenia klienckie, zobacz Wydajność usługi Azure Cache for Redis.

Wysokie użycie procesora CPU na hostach klienckich

Wysokie użycie procesora CPU klienta wskazuje, że system nie może nadążyć za pracą przypisaną do niego. Nawet jeśli pamięć podręczna szybko wyśle odpowiedź, klient może nie przetworzyć odpowiedzi wystarczająco szybko. Najlepiej zachować procesor klienta na poziomie mniejszym niż 80%.

Aby zmniejszyć wysokie użycie procesora klienta:

  • Zbadaj przyczynę skoków użycia procesora.
  • Uaktualnij klienta do większego rozmiaru maszyny wirtualnej przy użyciu większej pojemności procesora CPU.

Monitoruj użycie procesora CPU w całym systemie klienta przy użyciu metryk dostępnych w witrynie Azure Portal lub liczników wydajności na maszynie wirtualnej. Sprawdź metrykę błędów (Typ: UnresponsiveClients), aby określić, czy hosty klienckie mogą przetwarzać odpowiedzi z serwera Redis na czas.

Należy zachować ostrożność, aby nie monitorować użycia procesora procesów, ponieważ pojedynczy proces może mieć niskie zużycie CPU, ale całkowite użycie CPU w systemie może być wysokie. Obserwuj skoki użycia procesora CPU, które odpowiadają przekroczeniom limitu czasu. Wysokie użycie CPU może również powodować wysokie in: XXX wartości w timeoutException komunikatach o błędach. Zobacz sekcję Konfiguracja sieci i puli wątków ruchu , aby zapoznać się z przykładem.

StackExchange.Redis 1.1.603 i nowsze zawierają metrykę local-cpu w komunikatach o błędach timeoutException. Upewnij się, że używasz najnowszej wersji pakietu NuGet StackExchange.Redis, ponieważ błędy są regularnie naprawiane, aby kod był bardziej odporny na przekroczenia limitu czasu. Aby uzyskać więcej informacji, zobacz Analizę timeout wyjątków w StackExchange.Redis.

Duże wartości klucza

Możesz użyć polecenia redis-cli --bigkeys, aby sprawdzić duże klucze w pamięci podręcznej. Aby uzyskać więcej informacji na temat interfejsu wiersza polecenia usługi Redis, zobacz Interfejs wiersza polecenia usługi Redis.

Aby wyeliminować problem:

  • Zwiększ rozmiar maszyny wirtualnej, aby uzyskać większą przepustowość. Większa przepustowość na maszynie wirtualnej klienta lub serwera może skrócić czas transferu danych w przypadku większych odpowiedzi. Porównaj bieżące użycie sieci na obu maszynach wirtualnych z limitami bieżących rozmiarów maszyn wirtualnych. Większa przepustowość tylko na serwerze lub kliencie może nie być wystarczająca.

  • Zwiększ liczbę obiektów połączenia używanych przez aplikację. Użyj podejścia okrężnego, aby wysyłać żądania do różnych obiektów połączenia. Aby uzyskać informacje na temat używania wielu kluczy i mniejszych wartości, zobacz Rozważ więcej kluczy i mniejszych wartości.

Nacisk na pamięć na kliencie Redis

Nacisk na pamięć na kliencie może prowadzić do problemów z wydajnością, które opóźniają przetwarzanie odpowiedzi z pamięci podręcznej. W przypadku wystąpienia ciśnienia pamięci system może stronicować dane na dysku. Ta strona powodująca błędy powoduje znaczne spowolnienie działania systemu.

Aby wykryć presję pamięci na kliencie:

  • Monitoruj użycie pamięci na maszynie wirtualnej, aby upewnić się, że nie przekracza ona dostępnej pamięci.
  • Monitoruj licznik wydajności klienta Page Faults/Sec . Podczas normalnego działania większość systemów ma pewne błędy stron. Skoki błędów strony odpowiadające przekroczeniom limitu czasu żądania mogą wskazywać na wykorzystanie pamięci.

Aby ograniczyć wysokie wykorzystanie pamięci na kliencie:

  • Zbadaj wzorce użycia pamięci, aby zmniejszyć zużycie pamięci na kliencie.
  • Uaktualnij maszynę wirtualną klienta do większego rozmiaru przy użyciu większej ilości pamięci.

Ograniczenie przepustowości sieci na hostach klienckich

W zależności od ich architektury maszyny klienckie mogą mieć ograniczenia dotyczące dostępności przepustowości sieci. Jeśli klient przekroczy dostępną przepustowość przez przeciążenie pojemności sieci, dane nie są przetwarzane po stronie klienta tak szybko, jak serwer go wysyła. Może to prowadzić do przekraczania limitów czasu.

Aby rozwiązać ten problem, zmniejsz zużycie przepustowości sieci lub zwiększ rozmiar maszyny wirtualnej klienta do jednego z większą pojemnością sieci. Aby uzyskać więcej informacji, zobacz Duży rozmiar żądania lub odpowiedzi.

RedisSessionStateProvider retryTimeout

Jeśli używasz polecenia RedisSessionStateProvider, upewnij się, że ustawiono poprawną wartość retryTimeout . Wartość retryTimeoutInMilliseconds powinna być wyższa niż operationTimeoutInMilliseconds wartość. W przeciwnym razie nie ma ponownych prób.

W poniższym przykładzie retryTimeoutInMilliseconds jest ustawione na 3000.

<add 
    name="AFRedisCacheSessionStateProvider"
    type="Microsoft.Web.Redis.RedisSessionStateProvider"
    host="enbwcache.redis.cache.windows.net"
    port="6380"
    accessKey="..."
    ssl="true"
    databaseId="0"
    applicationName="AFRedisCacheSessionState"
    connectionTimeoutInMilliseconds = "5000"
    operationTimeoutInMilliseconds = "1000"
    retryTimeoutInMilliseconds="3000"
>

Ustawienia protokołu TCP dla aplikacji klienckich opartych na systemie Linux

Aplikacje klienckie hostowane w systemie Linux mogą napotykać problemy z łącznością z powodu optymistycznych ustawień TCP w systemie Linux. Aby uzyskać więcej informacji, zobacz Ustawienia PROTOKOŁU TCP dla aplikacji klienckich hostowanych w systemie Linux.

Nagły wzrost ruchu a konfiguracja puli wątków

Nagłe wzrosty ruchu w połączeniu ze złymi ustawieniami ThreadPool mogą spowodować opóźnienia w przetwarzaniu danych już wysłanych przez serwer Redis, ale jeszcze nie wykorzystanych po stronie klienta. Sprawdź metryki Błędy (Typ: Brak odpowiedziKlienci), aby zweryfikować, czy hosty klienckie mogą nadążyć za nagłymi skokami ruchu. Możesz skonfigurować ustawienia puli wątków, aby zapewnić szybkie skalowanie puli wątków w sytuacjach nagłych wzrostów obciążenia.

Możesz użyć timeoutException komunikatów z StackExchange.Redis, aby zbadać to dokładniej.

    System.timeoutException: timeout performing EVAL, inst: 8, mgr: Inactive, queue: 0, qu: 0, qs: 0, qc: 0, wr: 0, wq: 0, in: 64221, ar: 0,
    IOCP: (Busy=6,Free=999,Min=2,Max=1000), WORKER: (Busy=7,Free=8184,Min=2,Max=8191)

Powyższy wyjątek pokazuje kilka problemów.

  • W sekcji IOCP i sekcji WORKER, wartość Busy jest większa niż wartość Min, co oznacza, że te ThreadPool ustawienia wymagają dostosowania.
  • Wartość in: 64221 wskazuje, że 64 221 bajtów zostało odebranych w warstwie gniazda jądra klienta, ale nie jest odczytywane przez aplikację. Ta różnica zwykle oznacza, że aplikacja, na przykład StackExchange.Redis, nie odczytuje danych z sieci tak szybko, jak serwer go wysyła.

StackExchange.Redis 1.1.603 i nowsze zawierają metrykę local-cpu w komunikatach o błędach timeoutException. Upewnij się, że używasz najnowszej wersji pakietu NuGet StackExchange.Redis, ponieważ błędy są regularnie naprawiane, aby kod był bardziej odporny na przekroczenia limitu czasu. Aby uzyskać więcej informacji, zobacz Badanie wyjątków limitu czasu w witrynie StackExchange.Redis.

Rozwiązywanie problemów po stronie serwera

Następujące problemy po stronie serwera mogą mieć wpływ na wydajność i prowadzić do przekroczenia limitu czasu.

Wysokie użycie pamięci

Nacisk pamięciowy na serwerze może prowadzić do różnych problemów z wydajnością, które opóźniają przetwarzanie żądań. W przypadku wystąpienia presji na pamięć system stronicuje dane na dysk, co powoduje znaczne spowolnienie systemu.

Niektóre możliwe przyczyny użycia pamięci polegają na tym, że pamięć podręczna jest wypełniona danymi w pobliżu maksymalnej pojemności lub że serwer Redis ma wysoką fragmentację pamięci.

Fragmentacja jest prawdopodobna, gdy wzorzec obciążenia przechowuje dane o dużym rozmiarze, na przykład gdy dane są rozłożone na rozmiary 1 KB i 1 MB. Gdy klucz 1 KB zostanie usunięty z istniejącej pamięci, klucz o rozmiarze 1 MB nie może zmieścić się w przestrzeni, powodując fragmentację. Podobnie, jeśli klucz 1 MB zostanie usunięty, dodany klucz o rozmiarze 1,5 MB nie może zmieścić się w istniejącej odzyskanej pamięci. Ta nieużywana wolna pamięć powoduje fragmentację.

Jeśli pamięć podręczna jest pofragmentowana i działa pod dużym naciskiem na zasoby pamięci, system wykonuje failover, aby spróbować odzyskać pamięć Resident Set Size (RSS). Redis uwidacznia dwie statystyki, used_memory oraz used_memory_rss, za pomocą polecenia INFO, które może pomóc w zidentyfikowaniu tego problemu. Te metryki można również wyświetlić w witrynie Azure Portal.

Jeśli wartość used_memory_rss jest wyższa niż 1,5 razy metryka used_memory, w pamięci występuje fragmentacja. Fragmentacja może powodować problemy, gdy:

  • Użycie pamięci jest zbliżone do maksymalnego limitu pamięci dla pamięci podręcznej.
  • used_memory_rss Wskaźnik jest wyższy niż maksymalny dopuszczalny poziom pamięci, co może spowodować błąd stron w pamięci.

Możesz wykonać kilka akcji, aby ułatwić zachowanie dobrej kondycji użycia pamięci.

Aby uzyskać więcej zaleceń dotyczących zarządzania pamięcią, zobacz Najlepsze rozwiązania dotyczące zarządzania pamięcią.

Duże obciążenie serwera

Duże obciążenie serwera oznacza, że serwer Redis jest zajęty i nie może nadążyć za żądaniami, co prowadzi do przekroczenia limitu czasu lub wolnych odpowiedzi. Aby wyeliminować duże obciążenie serwera, najpierw zbadaj przyczynę, taką jak długotrwałe polecenia z powodu wysokiego użycia pamięci.

Metryki, takie jak obciążenie serwera, można monitorować w witrynie Azure Portal. Aby sprawdzić metrykę Obciążenia serwera, wybierz Analizy w obszarze Monitorowanie z menu nawigacyjnego po lewej stronie na stronie pamięci podręcznej i wyświetl wykres Obciążenia serwera. Możesz też wybrać pozycję Metryki w obszarze Monitorowanie w menu nawigacji po lewej stronie, a następnie wybierz pozycję Obciążenie serwera w obszarze Metryki.

Obserwuj wzrosty w obciążeniu serwera, które pokrywają się z przekroczeniami czasu. Utwórz alerty dotyczące metryk obciążenia serwera, aby otrzymywać powiadomienia na wczesnym etapie o potencjalnym wpływie.

Skoki obciążenia serwera

W pamięciach podręcznych C0 i C1 mogą wystąpić krótkie skoki obciążenia serwera, które nie są spowodowane wzrostem liczby żądań, podczas gdy wewnętrzne skanowanie usługi Defender jest uruchomione na maszynach wirtualnych. W tych warstwach widoczne jest większe opóźnienie żądań podczas wewnętrznego skanowania usługi Defender.

Pamięci podręczne w warstwach C0 i C1 mają tylko jeden rdzeń odpowiedzialny za wykonywanie wielozadaniowości, dzieląc pracę między obsługę wewnętrznych żądań skanowania w usłudze Defender i obsługę żądań w usłudze Redis. Jeśli dodatkowa latencja z wewnętrznych skanowań Defendera negatywnie wpływa na obciążenie środowiska produkcyjnego w cache C1, możesz zwiększyć skalę do wyższej warstwy z wieloma rdzeniami CPU, takimi jak C2. Aby uzyskać więcej informacji, zobacz Wybieranie odpowiedniej warstwy.

Aby uzyskać więcej informacji na temat szybkich zmian liczby połączeń klienckich, zobacz Unikanie skoków połączeń klienta.

Skalowanie

Możesz skalować w poziomie do większej liczby fragmentów w celu dystrybucji obciążenia w wielu procesach usługi Redis lub skalować w górę do większego rozmiaru pamięci podręcznej przy użyciu większej liczby rdzeni procesora CPU. Operacje skalowania intensywnie korzystają z procesora CPU i pamięci, ponieważ mogą obejmować przenoszenie danych wokół węzłów i zmienianie topologii klastra. Aby uzyskać więcej informacji, zobacz Azure Cache for Redis planning FAQ and Scaling (Planowanie usługi Azure Cache for Redis — często zadawane pytania i skalowanie).

Długotrwałe polecenia

Wykonywanie niektórych poleceń usługi Redis jest bardziej kosztowne. W dokumentacji poleceń usługi Redis przedstawiono złożoność czasu każdego polecenia. Przetwarzanie poleceń usługi Redis jest jednowątkowe. Każde polecenie, które trwa długo, może zablokować inne, które następują po nim.

Przejrzyj polecenia, które wydasz serwerowi Redis, aby zrozumieć ich wpływ na wydajność. Na przykład polecenie KEYS jest często używane bez wiedzy, że jest to operacja Big O Notation (O(N)). Aby zmniejszyć skoki zużycia CPU, można uniknąć KEYS korzystając z SCAN.

Następujące polecenia Redis można uruchomić w konsoli, aby zbadać długo wykonywane i kosztowne polecenia.

  • LISTA KLIENTÓW

    Polecenie CLIENT LIST zwraca informacje i statystyki dotyczące serwera połączeń klienta w formacie głównie czytelnym dla człowieka.

  • INFORMACJI

    Polecenie INFO zwraca informacje i statystyki dotyczące serwera w formacie prostym dla komputerów do analizowania i łatwego odczytywania przez ludzi. Sekcja CPU może być przydatna do analizy użycia CPU. Wartość server_load z 100 (maksymalna wartość) oznacza, że serwer Redis cały czas był zajęty i podczas przetwarzania żądań nie miał ani chwili przestoju.

    W poniższym przykładzie przedstawiono dane wyjściowe polecenia INFO :

    # CPU
used_cpu_sys:530.70
used_cpu_user:445.09
used_cpu_avg_ms_per_sec:0
server_load:0.01
event_wait:1
event_no_wait:1
event_wait_count:10
event_no_wait_count:1

  • MONITOR

    MONITOR to polecenie debugowania, które przesyła strumieniowo z powrotem każde polecenie przetworzone przez serwer Redis. MONITOR może pomóc zrozumieć, co dzieje się z bazą danych. To polecenie jest wymagające i może negatywnie wpłynąć na wydajność, obniżając ją.

  • DZIENNIK WOLNY

    Slow Log Redis to system rejestrowania zapytań, które przekroczyły określony czas wykonania. Czas wykonywania nie obejmuje operacji we/wy, takich jak rozmowa z klientem lub wysłanie odpowiedzi, ale tylko czas potrzebny do rzeczywistego wykonania polecenia.

    Polecenie SLOWLOG odczytuje i resetuje dziennik wolno działających zapytań w Redis, a także może być używane do analizy długotrwałych poleceń po stronie klienta. Możesz monitorować i rejestrować kosztowne polecenia wykonywane na serwerze Redis przy użyciu polecenia SLOWLOG GET.

Ograniczenia przepustowości sieci

Różne rozmiary pamięci podręcznej mają różne możliwości w zakresie przepustowości sieci. Jeśli serwer przekroczy dostępną przepustowość, dane nie są wysyłane do klienta tak szybko. Żądania klientów mogą przekroczyć limit czasu, ponieważ serwer nie jest w stanie wystarczająco szybko przesyłać danych do klienta.

Możesz monitorować metryki , takie jak odczyt pamięci podręcznej i zapis w pamięci podręcznej w witrynie Azure Portal, aby zobaczyć, ile przepustowości jest używane po stronie serwera. Utwórz alerty dotyczące tych metryk, aby otrzymywać powiadomienia na wczesnym etapie o potencjalnym wpływie.

Aby wyeliminować sytuacje, w których użycie przepustowości sieci jest zbliżone do maksymalnej pojemności:

Konserwacja serwera

Planowana lub nieplanowana konserwacja może powodować zakłócenia połączeń klientów. Liczba i typ wyjątków zależą od lokalizacji żądania w ścieżce kodu, oraz od momentu, gdy pamięć podręczna zamyka swoje połączenia.

Jeśli pamięć podręczna Redis w Azure doświadczy przełączenia awaryjnego, wszystkie połączenia klienta z węzła, który uległ awarii, zostaną przeniesione do węzła, który jest nadal uruchomiony. Obciążenie serwera może wzrosnąć z powodu zwiększonych połączeń. Możesz spróbować ponownie uruchomić aplikacje klienckie, aby wszystkie połączenia klienckie zostały ponownie utworzone i redystrybuowane między dwoma węzłami.

Operacja, która wysyła żądanie, ale nie otrzymuje odpowiedzi podczas przełączenia awaryjnego, może otrzymać timeout wyjątek. Nowe żądania w obiekcie zamkniętego połączenia otrzymują wyjątki związane z połączeniem, dopóki połączenie nie zostanie pomyślnie odtworzone.

Aby sprawdzić, czy pamięć podręczna Azure Redis Cache miała tryb failover w czasie timeout wystąpienia wyjątków, sprawdź metrykę Błędy . Na stronie portalu Azure dla pamięci podręcznej wybierz opcję Metryki w obszarze Monitorowanie w lewym menu nawigacyjnym. Następnie utwórz nowy wykres mierzący metrykę Błędy podzieloną na wartość ErrorType. Po utworzeniu tego wykresu zobaczysz ilość dla failover. Aby uzyskać więcej informacji na temat przełączania awaryjnego, zobacz Przełączanie awaryjne i aktualizacje dla usługi Azure Cache for Redis.

Aby uzyskać więcej informacji na temat ograniczania problemów spowodowanych konserwacją serwera, zobacz następujące artykuły:

Powiązana zawartość