Udostępnij przez

Rozwiązywanie problemów z opóźnieniami i przekroczeniami limitu czasu usługi Redis zarządzanej platformy Azure

  • Dotyczy: ✅ Azure Managed Redis

Operacja klienta, która nie otrzymuje na czas odpowiedzi, może spowodować wyjątek spowodowany dużym opóźnieniem lub przekroczeniem limitu czasu. Być może upłynął limit czasu operacji na różnych etapach. To, skąd pochodzi limit czasu, pomaga określić przyczynę i środki zaradcze.

W tej sekcji omówiono rozwiązywanie problemów z opóźnieniami i przekroczeniem limitu czasu występujących podczas nawiązywania połączenia z usługą Azure Managed Redis.

Uwaga / Notatka

Kilka kroków rozwiązywania problemów w tym przewodniku zawiera instrukcje dotyczące uruchamiania poleceń usługi Redis i monitorowania różnych metryk wydajności. Aby uzyskać więcej informacji i instrukcji, zobacz artykuły w sekcji Dodatkowe informacje.

Rozwiązywanie problemów po stronie klienta

Przedstawiamy kroki rozwiązywania problemów po stronie klienta.

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ź metrykę „Błędy” (Typ: UnresponsiveClients), aby sprawdzić, czy hosty klienckie nadążają za nagłym wzrostem ruchu.

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

    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)

W poprzednim wyjątku istnieje kilka interesujących problemów:

  • Zwróć uwagę, że w sekcji IOCP i sekcji WORKER znajduje się wartość Busy większa niż wartość Min. Ta różnica oznacza, że ustawienia ThreadPool wymagają dostosowania.
  • Możesz również wyświetlić in: 64221. Ta wartość wskazuje, że 64 221 bajtów zostało odebranych w warstwie gniazda jądra klienta, ale nie zostały odczytane przez aplikację. Ta różnica zwykle oznacza, że aplikacja (na przykład StackExchange.Redis) nie odczytuje danych z sieci tak szybko, jak serwer wysyła je do Ciebie.

Możesz skonfigurować swoje ThreadPool Ustawienia, aby upewnić się, że pula wątków jest szybko zwiększana w sytuacjach gwałtownego wzrostu obciążenia.

Duża wartość klucza

Aby uzyskać informacje na temat używania wielu kluczy i mniejszych wartości, zobacz Rozważ więcej kluczy i mniejszych wartości.

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

  • 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 z limitami bieżącego rozmiaru maszyny wirtualnej. Większa przepustowość tylko na serwerze lub tylko na kliencie może nie być wystarczająca.
  • Zwiększ liczbę obiektów połączenia używanych przez aplikację.
    • Używanie podejścia okrężnego do podejmowania żądań na różnych obiektach połączenia

Wysokie użycie procesora CPU na hostach klienckich

Wysokie użycie procesora klienta wskazuje, że system nie nadąża z przypisaną pracą. Mimo że pamięć podręczna szybko wysłała odpowiedź, klient mógł nie przetworzyć odpowiedzi na czas. Naszym zaleceniem jest utrzymanie obciążenia CPU klienta poniżej 80%. Sprawdź metrykę "Błędy" (typ: UnresponsiveClients), aby określić, czy twoje hosty klienckie są w stanie przetwarzać odpowiedzi z serwera Redis w czasie.

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. Należy uważać, aby nie monitorować procesora, ponieważ pojedynczy proces może zużywać mało czasu procesora, ale zużycie procesora całego systemu 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 komunikatach o błędach TimeoutException zgodnie z opisem w sekcji [Wzrost ruchu].

Uwaga / Notatka

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. Błędy są regularnie naprawiane w kodzie, aby uczynić go bardziej odpornym na przekroczenia limitu czasu. Posiadanie najnowszej wersji jest ważne.

Aby zmniejszyć wysokie użycie procesora klienta:

  • Zbadaj, co powoduje wzrosty użycia procesora.
  • Uaktualnij klienta do większego rozmiaru maszyny wirtualnej przy użyciu większej pojemności procesora CPU.

Ograniczenie przepustowości sieci na hostach klienckich

W zależności od architektury komputerów klienckich mogą one mieć ograniczenia dotyczące dostępnej przepustowości sieci. Jeśli klient przekroczył dostępną przepustowość przez przeciążenie wydajności sieci, dane nie są przetwarzane po stronie klienta z szybkością, z jaką są wysyłane przez serwer. 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.

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

Ze względu na optymistyczne ustawienia TCP w systemie Linux aplikacje klienckie hostowane w systemie Linux mogą napotykać problemy z łącznością. Aby uzyskać więcej informacji, zobacz Ustawienia TCP dla aplikacji klienckich hostowanych w systemie Linux.

Limit czasu ponawiania prób dla dostawcy RedisSessionStateProvider

Jeśli używasz usługi RedisSessionStateProvider, upewnij się, że ustawiono prawidłowy limit czasu ponawiania prób. Wartość retryTimeoutInMilliseconds powinna być wyższa niż operationTimeoutInMilliseconds wartość. W przeciwnym razie nie ma ponownych prób. W poniższym przykładzie wartość retryTimeoutInMilliseconds została ustawiona na 3000. Aby uzyskać więcej informacji, jak korzystać z parametrów konfiguracyjnych dostawcy stanu sesji oraz dostawcy pamięci podręcznej dla wyników.

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

Rozwiązywanie problemów po stronie serwera

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 tego, kiedy pamięć podręczna zamyka swoje połączenia. Na przykład operacja, która wysyła żądanie, ale nie otrzymuje odpowiedzi, gdy nastąpi przełączanie awaryjne, może uzyskać wyjątek dotyczący limitu czasu. 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 uzyskać więcej informacji, zobacz Odporność połączenia.

Wysokie zużycie procesora

Wysokie użycie procesora CPU oznacza, że serwer Redis nie może nadążyć za żądaniami, co prowadzi do przekroczenia limitu czasu. Serwer może wolno odpowiadać i nie nadążać za ilością żądań.

Monitoruj metryki takie jak CPU. Obserwuj skoki w użyciu CPU, które odpowiadają na przerwania czasowe. Utwórz alerty dotyczące metryk procesora, aby otrzymywać wczesne powiadomienia o potencjalnym wpływie.

Istnieje kilka zmian, które można wprowadzić, aby ograniczyć wysokie użycie procesora:

  • Zbadaj, co powoduje wysokie użycie procesora, takie jak długotrwałe polecenia, co jest opisane w tym artykule, ze względu na duże obciążenie pamięci.
  • Rozszerz zasoby poziomo do większej liczby fragmentów, aby rozłożyć obciążenie na wiele procesów Redis, lub zwiększ zasoby do większego rozmiaru pamięci podręcznej z większą liczbą rdzeni procesora CPU. Aby uzyskać więcej informacji, zobacz Architektura usługi Azure Managed Redis.
  • Jeśli obciążenie produkcyjne w pamięci podręcznej jest negatywnie wpływane przez dodatkowe opóźnienia wynikające z niektórych wewnętrznych przebiegów skanowania przez Defendera, możesz zmniejszyć ten efekt, migrując pamięć podręczną do warstwy zoptymalizowanej pod kątem obliczeń lub skalując do wyższej oferty z większą liczbą rdzeni procesora.

Nagłe wzrosty aktywności CPU

W pamięciach podręcznych B0, B1, B3 i B5 mogą wystąpić krótkie skoki użycia procesora, które nie są spowodowane wzrostem liczby żądań, a zdarzają się kilka razy dziennie, gdy na maszynach wirtualnych uruchomione jest wewnętrzne skanowanie za pomocą Defender. Zobaczysz większe opóźnienie żądań, podczas gdy wewnętrzne skanowania w usłudze Defender są wykonywane w tych warstwach. Pamięci podręczne na tych poziomach mają tylko dwa rdzenie do wielozadaniowości, dzieląc pracę polegającą na obsłudze skanowania przez Defendera i żądań Redis.

Wysokie użycie pamięci

Aby uzyskać więcej informacji, zobacz Wysokie użycie pamięci.

Długotrwałe polecenia

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

Przejrzyj polecenia wystawiane na serwer Redis, aby zrozumieć ich wpływ na wydajność. Na przykład polecenie KEYS jest często używane bez świadomości, że jest to operacja O(N). Aby uniknąć używania KEYS, można użyć SCAN w celu zmniejszenia skoków obciążenia procesora.

Za pomocą polecenia SLOWLOG GET klienci mogą mierzyć kosztowne polecenia wykonywane na serwerze.

Klienci mogą używać konsoli do uruchamiania tych poleceń usługi Redis w celu zbadania długotrwałych i kosztownych poleceń.

  • SLOWLOG służy do odczytywania i resetowania dziennika wolnych zapytań usługi Redis. Może być używane do badania poleceń o długim czasie działania po stronie klienta. 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, wysłanie odpowiedzi itd., ale tylko czas potrzebny do rzeczywistego wykonania polecenia. Za pomocą polecenia SLOWLOG klienci mogą mierzyć/dokumentować kosztowne polecenia wykonywane na serwerze Redis.
  • MONITOR to polecenie debugowania, które przesyła strumieniowo z powrotem każde polecenie przetworzone przez serwer Redis. Może to pomóc w zrozumieniu, co dzieje się z bazą danych. To polecenie jest wymagające i może negatywnie wpłynąć na wydajność. Może to obniżyć wydajność.
  • INFO — polecenie zwraca informacje i statystyki dotyczące serwera w formacie prostym do analizowania przez komputery i łatwego do odczytania przez ludzi. W takim przypadku sekcja CPU może być przydatna do zbadania użycia CPU. Procesor CPU 100 (wartość maksymalna) oznacza, że serwer Redis był zajęty przez cały czas i nigdy nie był bezczynny podczas przetwarzania żądań.

Przykładowe dane wyjściowe:

# 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
  • CLIENT LIST — zwraca informacje i statystyki dotyczące serwera połączeń klienta w formacie najczęściej czytelnym dla człowieka.

Ograniczenie 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 będą 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.

Metryki „Odczyt z pamięci podręcznej” i „Zapis w pamięci podręcznej” mogą służyć do sprawdzania, ile przepustowości jest używanej po stronie serwera. Te metryki można wyświetlić w portalu. Utwórz alerty dla metryk, takich jak odczyt z pamięci podręcznej lub zapis w pamięci podręcznej, aby uzyskiwać wczesne powiadomienia o potencjalnym wpływie.

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

Wyjątki przekroczenia limitu czasu StackExchange.Redis

Aby uzyskać bardziej szczegółowe informacje na temat adresowania limitów czasu podczas korzystania z usługi StackExchange.Redis, zobacz Badanie wyjątków przekroczenia limitu czasu w usłudze StackExchange.Redis.

Treści powiązane

  • Last updated on