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

  • Artykuł

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 Cache for Redis.

Uwaga

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

Oto rozwiązywanie problemów po stronie klienta.

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

Wzrost ruchu w połączeniu z niskimi ThreadPool ustawieniami może spowodować opóźnienia przetwarzania danych już wysyłanych przez serwer Redis, ale nie są jeszcze używane po stronie klienta. Sprawdź metrykę „Błędy” (Typ: UnresponsiveClients), aby sprawdzić, czy hosty klienckie nadążają za nagłym wzrostem ruchu.

Monitoruj, jak ThreadPool zmieniają się statystyki w czasie, korzystając z przykładu ThreadPoolLogger. Aby dokładniej zbadać, możesz użyć TimeoutException komunikatów z witryny StackExchange.Redis:

    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 IOCP sekcji i WORKER sekcji masz Busy wartość większą niż Min wartość. Ta różnica oznacza, że ustawienia ThreadPool wymagają dostosowania.
  • Można również zobaczyć 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ć ThreadPool Ustawienia, aby upewnić się, że pula wątków szybko skaluje się w górę w scenariuszach zwiększania wydajności.

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ć redis-cli --bigkeys polecenia , 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 CPU klienta wskazuje, że system nie może nadążyć za przypisaną pracą. Mimo że pamięć podręczna szybko wysłała odpowiedź, klient może nie przetworzyć odpowiedzi w odpowiednim czasie. Naszym zaleceniem jest utrzymanie mniej procesora CPU klienta o 80%. Sprawdź metryka "Błędy" (typ: UnresponsiveClients), aby określić, czy hosty klienckie mogą 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 zachować ostrożność, aby nie monitorować procesora CPU, ponieważ pojedynczy proces może mieć niskie użycie procesora CPU, ale procesor cpu dla całego systemu może być wysoki. Obserwuj skoki użycia procesora CPU, które odpowiadają limitom czasu. Wysokie użycie procesora CPU może również spowodować wysokie in: XXX wartości w TimeoutException komunikatach o błędach zgodnie z opisem w sekcji [Traffic burst] (Wzrost ruchu).

Uwaga

StackExchange.Redis 1.1.603 i nowsze zawierają local-cpu metryki w TimeoutException komunikatach o błędach. Upewnij się, że używasz najnowszej wersji pakietu NuGet StackExchange.Redis. Błędy są regularnie naprawiane w kodzie, aby zwiększyć niezawodność limitów czasu. Posiadanie najnowszej wersji jest ważne.

Aby wyeliminować wysokie użycie procesora CPU klienta:

  • Zbadaj, co powoduje wzrosty użycia procesora CPU.
  • 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 maszyn 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. Taka sytuacja może prowadzić do przekroczenia limitu czasu.

Monitoruj, jak zmienia się użycie przepustowości w czasie, korzystając z przykładu BandwidthLogger. Ten kod może nie działać pomyślnie w niektórych środowiskach z ograniczonymi uprawnieniami (takimi jak witryny internetowe platformy Azure).

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 PROTOKOŁU 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 retryTimeoutInMilliseconds ustawiono wartość 3000. Aby uzyskać więcej informacji, zobacz ASP.NET Dostawca stanu sesji dla usługi Azure Cache for Redis i How to use the configuration parameters of Session State Provider and Output Cache Provider (Jak używać parametrów konfiguracji dostawcy stanu sesji i dostawcy wyjściowej pamięci podręcznej).

<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"
>

Rozwiązywanie problemów po stronie serwera

Oto 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 przejście w tryb failover, może uzyskać wyjątek przekroczenia limitu czasu. Nowe żądania w obiekcie zamkniętego połączenia odbierają wyjątki połączeń do momentu pomyślnego ponownego nawiązania połączenia.

Aby uzyskać więcej informacji, zapoznaj się z innymi sekcjami:

Aby sprawdzić, czy usługa Azure Cache for Redis miała tryb failover w czasie wystąpienia przekroczenia limitu czasu, sprawdź błędy metryki. W menu Zasób witryny Azure Portal wybierz pozycję Metryki. Następnie utwórz nowy wykres pomiaru Errors metryki z podziałem na ErrorTypewartość . Po utworzeniu tego wykresu zobaczysz liczbę trybu failover.

Aby uzyskać więcej informacji na temat trybu failover, zobacz Tryb failover i stosowanie poprawek dla usługi Azure Cache for Redis.

Duże obciążenie serwera

Duże obciążenie serwera 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 obciążenie serwera. Obserwuj wzrosty Server Load użycia, które odpowiadają limitom czasu. Utwórz alerty dotyczące metryk obciążenia serwera, aby otrzymywać powiadomienia na wczesnym etapie o potencjalnym wpływie.

Istnieje kilka zmian, które można wprowadzić, aby ograniczyć duże obciążenie serwera:

  • Zbadaj, co powoduje wysokie obciążenie serwera, takie jak długotrwałe polecenia, zanotowano w tym artykule ze względu na wysokie wykorzystanie pamięci.
  • Skalowanie w poziomie do większej liczby fragmentów w celu dystrybucji obciążenia w wielu procesach usługi Redis lub skalowanie w górę do większego rozmiaru pamięci podręcznej przy użyciu większej liczby rdzeni procesora CPU. Aby uzyskać więcej informacji, zobacz Azure Cache for Redis planning FAQ (Planowanie usługi Azure Cache for Redis — często zadawane pytania).
  • Jeśli obciążenie produkcyjne w pamięci podręcznej C1 jest negatywnie dotknięte dodatkowym opóźnieniem skanowania antywirusowego, możesz zmniejszyć efekt, płacąc za wyższą warstwę z wieloma rdzeniami procesora CPU, takimi jak C2.

Skoki obciążenia serwera

W pamięciach podręcznych C0 i C1 mogą wystąpić krótkie skoki obciążenia serwera nie spowodowane wzrostem liczby żądań kilka razy dziennie podczas skanowania wirusów na maszynach wirtualnych. Zobaczysz większe opóźnienie żądań podczas skanowania wirusów w tych warstwach. Pamięci podręczne w warstwach C0 i C1 mają tylko jeden rdzeń do multitask, dzieląc pracę służącą skanowaniu wirusów i żądaniom redis.

Wysokie użycie pamięci

Ta sekcja została przeniesiona. 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 pokazuje 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ć wszystkie inne polecenia, które pochodzą 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 znajomości, że jest to operacja O(N). Klucze można uniknąć, używając funkcji SCAN , aby zmniejszyć wzrosty użycia procesora CPU.

Za pomocą polecenia SLOWLOG GET można zmierzyć 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ń.

  • DZIENNIK SLOWLOG służy do odczytywania i resetowania dziennika wolnych zapytań usługi Redis. Służy do badania długotrwałych poleceń po stronie klienta. Dziennik wolny usługi Redis to system do rejestrowania zapytań, które przekroczyły określony czas wykonywania. Czas wykonywania nie obejmuje operacji we/wy, takich jak rozmowa z klientem, wysłanie odpowiedzi itd., ale tylko czas potrzebny do rzeczywistego wykonania polecenia. Klienci mogą mierzyć/rejestrować kosztowne polecenia wykonywane na serwerze Redis przy użyciu SLOWLOG polecenia .
  • 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 procesora CPU może być przydatna do zbadania użycia procesora CPU. Obciążenie serwera 100 (wartość maksymalna) oznacza, że serwer Redis był zajęty przez cały czas i nigdy nie był bezczynny podczas przetwarzania żądań.

Przykład danych wyjściowych:

# 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
  • LISTA KLIENTÓW — 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 są wysyłane do klienta tak szybko. Żądania klientów mogą powodować przekraczanie limitu czasu, ponieważ serwer nie może wystarczająco szybko wypychać 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 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.

Powiązana zawartość