Rozwiązywanie problemów z opóźnieniem i przekroczeniami limitu czasu usługi Azure Cache for 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 Cache for Redis.
-
Rozwiązywanie problemów po stronie klienta
- Nagły wzrost ruchu a konfiguracja puli wątków
- Duża wartość klucza
- Wysokie użycie procesora CPU na hostach klienckich
- Ograniczenie przepustowości sieci na hostach klienckich
- Ustawienia protokołu TCP dla aplikacji klienckich opartych na systemie Linux
- Limit czasu ponawiania prób dla dostawcy RedisSessionStateProvider
- Rozwiązywanie problemów po stronie serwera
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.
Przedstawiamy kroki rozwiązywania problemów po stronie klienta.
Zwielokrotnienie wydajności ruchu w połączeniu ze złymi ustawieniami ThreadPool
może spowodować opóźnienia przetwarzania danych już wysłanych przez serwer Redis, ale jeszcze nie przetworzonych 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 sekcji
IOCP
i sekcjiWORKER
maszBusy
wartość większą niż wartośćMin
. Ta różnica oznacza, że ustawieniaThreadPool
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ć ustawienia ThreadPool
, aby upewnić się, że pula wątków jest szybko skalowana w górę w scenariuszach zwiększania wydajności.
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
Duże użycie procesora CPU klienta wskazuje, że system nie nadąża ze przypisaną pracą. Mimo że pamięć podręczna szybko wysłała odpowiedź, klient mógł nie przetworzyć odpowiedzi na czas. 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ż powodować wysokie in: XXX
wartości w komunikatach o błędach TimeoutException
zgodnie z opisem w sekcji [Wzrost ruchu].
Uwaga
StackExchange.Redis 1.1.603 i nowsze zawierają local-cpu
metryki 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 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.
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.
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.
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.
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, zobacz dostawca stanu sesji ASP.NET dla usługi Azure Cache for Redis i dostawca ASP.NET output cache provider for Azure Cache for Redis.
<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"
>
Oto rozwiązywanie problemów po stronie 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 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 ErrorType
wartość . 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 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 skoki użycia procesora Server Load
, 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.
- Przeskaluj w poziomie do większej liczby fragmentów w celu dystrybucji obciążenia w ramach wielu procesów usługi Redis lub przeskaluj w górę do większego rozmiaru pamięci podręcznej z większą liczbą 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 z niektórych wewnętrznych przebiegów skanowania w usłudze Defender, możesz zmniejszyć efekt przez skalowanie do wyższej warstwy z wieloma rdzeniami procesora CPU, takimi jak C2.
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ń kilka razy dziennie, podczas gdy wewnętrzne skanowanie w usłudze Defender jest uruchomione na maszynach wirtualnych. Zobaczysz większe opóźnienie żądań, podczas gdy wewnętrzne skanowania w usłudze Defender są wykonywane w tych warstwach. Pamięci podręczne w warstwach C0 i C1 mają tylko jeden rdzeń do multitask, dzieląc pracę obsługi wewnętrznego skanowania w usłudze Defender i żądań redis.
Ta sekcja została przeniesiona. Aby uzyskać więcej informacji, zobacz Wysokie użycie pamięci.
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. Dowolne trwające długo polecenie może zablokować wszystkie inne pojawiające się 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 polecenia KEYS, klient może użyć polecenia SCAN w celu zmniejszenia skoków użycia procesora CPU.
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. 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. 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 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ł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.
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ą 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:
- Zmień zachowanie wywołania klienta, aby zmniejszyć zapotrzebowanie na sieć.
- Skalowanie do większego rozmiaru pamięci podręcznej przy użyciu większej pojemności przepustowości sieci. Aby uzyskać więcej informacji, zobacz Azure Cache for Redis planning FAQ (Planowanie usługi Azure Cache for Redis — często zadawane pytania).
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.