Sdílet prostřednictvím

Řešení potíží s latencí a vypršením časových limitů Azure Managed Redis

  • Platí pro: ✅ Azure Managed Redis

Operace klienta, která neobdrží včasnou odpověď, může vést k vysoké latenci nebo výjimce vypršení časového limitu. K vypršení časového limitu operace může dojít v různých fázích. Informace o tom, odkud vypršení časového limitu pochází, pomáhá určit příčinu a zmírnění rizik.

Tato část popisuje řešení potíží s latencí a vypršením časového limitu, ke kterým dochází při připojování ke službě Azure Managed Redis.

Poznámka:

Několik postupů pro řešení potíží v této příručce obsahuje pokyny ke spuštění příkazů Redis a monitorování různých metrik výkonu. Další informace a pokyny najdete v článcích v části Další informace.

Řešení problémů na straně klienta

V této části najdete informace o řešení potíží na straně klienta.

Náhlý nárůst provozu a konfigurace fondu vláken

Prudké zvýšení provozu v kombinaci se špatným nastavením fondu ThreadPool může mít za následek zpoždění při zpracování dat již odeslaných serverem Redis, která však ještě nebyla přijata na straně klienta. Zkontrolujte metriku "Chyby" (typ: UnresponsiveClients) a ověřte, jestli vaši klientští hostitelé dokáží zvládnout náhlé zvýšení provozu.

K dalšímu zkoumání můžete použít TimeoutException zprávy z 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)

V předchozí výjimce existuje několik zajímavých situací:

  • Všimněte si, že v oddílu IOCP a oddílu WORKER máte hodnotu Busy, která je větší než hodnota Min. Tento rozdíl znamená, že je třeba upravit nastavení ThreadPool.
  • Také můžete vidět in: 64221. Tato hodnota označuje, že ve vrstvě soketu jádra klienta bylo přijato 64 221 bajtů, ale aplikace je nepřečetla. Tento rozdíl obvykle znamená, že vaše aplikace (například StackExchange.Redis) nečte data ze sítě tak rychle, jak vám je server posílá.

Můžete nakonfigurovat své ThreadPool nastavení, abyste zajistili, že váš fond vláken bude rychle škálovat ve scénářích s náhlým nárůstem kapacity.

Velká hodnota klíče

Informace o použití více klíčů a menších hodnot najdete v tématu Zvažte více klíčů a menší hodnoty.

Ke kontrole velkých klíčů v mezipaměti můžete použít příkaz redis-cli --bigkeys. Další informace najdete v tématu redis-cli, rozhraní příkazového řádku Redis --Redis.

  • Zvětšením velikosti virtuálního počítače získáte větší možnosti šířky pásma.
    • Větší šířka pásma na virtuálním počítači klienta nebo serveru může zkrátit dobu přenosu dat pro větší odezvy.
    • Porovnejte aktuální využití sítě na obou počítačích s omezeními aktuální velikosti virtuálního počítače. Větší šířka pásma pouze na serveru nebo pouze na klientovi nemusí být dostatečná.
  • Zvyšte počet objektů připojení, které vaše aplikace používá.
    • Použijte rotující metodu pro odesílání požadavků přes různé objekty připojení.

Vysoké zatížení CPU na klientech hostitelů

Vysoké využití procesoru na straně klienta značí, že systém nedokáže držet krok s prací, která je mu přidělena. I když mezipaměť odešle odpověď rychle, klient ji nemusí zpracovat včas. Doporučujeme udržovat využití procesoru klienta pod 80%. Zkontrolujte metriku Chyby (Typ: UnresponsiveClients) a zjistěte, jestli hostitelé klientů můžou zpracovávat odezvy serveru Redis včas.

Monitorujte využití procesoru na úrovni celého systému klienta pomocí metrik dostupných na webu Azure Portal nebo čítačů výkonu v počítači. Dávejte pozor, abyste nemonitorovali využití procesoru na úrovni procesů, protože jeden proces může mít nízké využití procesoru, ale využití na úrovni celého systému může být vysoké. Sledujte nárůsty využití procesoru, které se shodují s vypršením časových limitů. Vysoké využití procesoru může také způsobit vysoké hodnoty in: XXX v chybových zprávách TimeoutException, jak je popsáno v sekci [Prudký nárůst provozu].

Poznámka:

StackExchange.Redis verze 1.1.603 a novějších obsahuje metriku local-cpu v TimeoutException chybových zprávách. Ujistěte se, že používáte nejnovější verzi sady StackExchange.Redis NuGet. Chyby v kódu jsou pravidelně opravovány, aby byl kód robustnější oproti vypršení časového limitu. Je důležité mít nejnovější verzi.

Pokud chcete zmírnit vysoké využití procesoru klienta:

  • Prozkoumejte, co způsobuje špičky využití procesoru.
  • upgradujte klienta na větší velikost virtuálního počítače s větší kapacitou procesoru.

Omezení šířky pásma sítě na hostitelích klientů

V závislosti na architektuře klientských počítačů pro ně může platit omezení dostupné šířky pásma sítě. Pokud klient překročí dostupnou šířku pásma v důsledku přetížení kapacity sítě, pak se data na straně klienta nebudou zpracovávat tak rychle, jak je server bude odesílat. Tato situace může způsobit vypršení časových limitů.

Pokud chcete zmírnit omezení, snižte spotřebu šířky pásma sítě nebo zvyšte velikost klientského virtuálního počítače na počítač s větší kapacitou sítě. Další informace najdete v tématu Velké požadavky nebo odpovědi.

Nastavení protokolu TCP pro klientské aplikace v Linuxu

Kvůli optimistickému nastavení protokolu TCP v Linuxu mohou klientské aplikace hostované v Linuxu zaznamenávat problémy s připojením. Další informace najdete v tématu Nastavení protokolu TCP pro klientské aplikace hostované v Linuxu.

Časový limit opakování pro RedisSessionStateProvider

Pokud používáte nástroj RedisSessionStateProvider, ujistěte se, že jste správně nastavili časový limit opakování. Hodnota retryTimeoutInMilliseconds by měla být vyšší než hodnota operationTimeoutInMilliseconds. V opačném případě nedojde k opakovaným pokusům. V následujícím příkladu,je hodnota retryTimeoutInMilliseconds nastavena na 3000. Další informace naleznete v tématu Použití parametrů konfigurace zprostředkovatele stavu relace a zprostředkovatele výstupní mezipaměti.

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

Řešení potíží na straně serveru

Údržba serveru

Plánovaná nebo neplánovaná údržba může způsobit přerušení připojení klientů. Počet a typ výjimek závisí na umístění požadavku v cestě kódu a na tom, kdy mezipaměť ukončuje připojení. Například operace, která při předání řízení odešle požadavek, ale neobdrží odpověď, může vyvolat výjimku časového limitu. Nové požadavky na objekt uzavřeného připojení vyvolávají výjimky, dokud nedojde k úspěšnému opětovnému připojení.

Další informace najdete v tématu věnovaném odolnosti připojení.

Vysoké využití procesoru

Vysoké zatížení procesoru znamená, že server Redis nedokáže držet krok s požadavky, což vede k vypršení časových limitů. Server může reagovat pomalu a může se stát, že nedokáže držet krok s frekvencí požadavků.

Monitorujte metriky jako je využití procesoru. Sledujte nárůsty využití CPU, které odpovídají časovým prodlevám. Vytvořte upozornění na metriky procesoru, abyste včas dostávali upozornění na potenciální dopady.

Pokud chcete zmírnit vysoké zatížení procesoru, můžete provést několik změn:

  • Prozkoumejte, co způsobuje vysoké využití procesoru, například dlouhotrvající příkazy, které jsou uvedené v tomto článku, protože vedou k vysokému zatížení paměti.
  • Škálujte na více shardů, abyste rozložili zátěž mezi více procesů Redis, nebo navyšte kapacitu na větší velikost mezipaměti s více jádry procesoru. Další informace najdete v tématu Architektura Azure Managed Redis.
  • Pokud je vaše produkční zatížení v mezipaměti negativně ovlivněno zvýšenou latencí způsobenou některými interními kontrolami defenderu, můžete snížit účinek migrací mezipaměti na úroveň optimalizovanou pro výpočetní výkon nebo škálováním na vyšší úroveň s více procesorovými jádry.

Špičky CPU

V mezipaměti B0, B1, B3 a B5 se mohou několikrát denně zobrazit krátké špičky využití procesoru, které nejsou způsobené nárůstem požadavků – na virtuálních počítačích běží kontrola interního defenderu. Během skenování interním Defenderem na těchto úrovních zaznamenáte vyšší latenci požadavků. Mezipaměti na těchto úrovních mají pouze dvě jádra pro multitasking a rozdělují práci obsluhy interní kontroly defenderu a požadavků Redis.

Vysoké využití paměti

Další informace najdete v tématu Vysoké využití paměti.

Dlouhotrvající příkazy

Některé příkazy Redis jsou náročnější na spuštění než jiné. Informace o časové náročnosti jednotlivých příkazů najdete v dokumentaci k příkazům Redis. Zpracování příkazů Redis probíhá v jednom vláknu. Jakýkoli příkaz, který trvá dlouhou dobu, může zablokovat všechny další příkazy, které přijdou po něm.

Projděte si příkazy, které vydáváte serveru Redis, a seznamte se s jejich dopadem na výkon. Například příkaz KEYS se často používá bez vědomí toho, že se jedná o operaci O(N). Abyste se vyhnuli příkazu KEYS a snížili tak špičky využití procesoru, použijte příkaz SCAN.

Náročné příkazy spouštěné na serveru můžete měřit pomocí příkazu SLOWLOG.

Zákazníci mohou pomocí konzole spustit tyto příkazy Redis k prozkoumání dlouhotrvajících a náročných příkazů.

  • SLOWLOG slouží ke čtení a resetování protokolu pomalých dotazů Redis. Je možné ho používat ke kontrole dlouhotrvajících příkazů na straně klienta. Záznam pomalých dotazů v Redis je systém pro zaznamenávání dotazů, které překročily stanovenou dobu provádění. Doba provádění nezahrnuje vstupně-výstupní operace, jako je komunikace s klientem, odeslání odpovědi atd., ale jen čas potřebný ke skutečnému spuštění příkazu. Zákazníci můžou pomocí příkazu SLOWLOG měřit a protokolovat náročné příkazy spouštěné na serveru Redis.
  • MONITOR je ladicí příkaz, který přehrává všechny příkazy zpracovávané serverem Redis. Může vám pomoci pochopit, co se děje s databází. Tento příkaz je náročný a může negativně ovlivnit výkon. Může snížit výkon.
  • Příkaz INFO vrátí informace a statistiky o serveru ve formátu, který lze jednoduše analyzovat podle jednotlivých počítačů a je snadno čitelný. V tomto případě může být užitečné prozkoumat využití procesoru v příslušné části. Využití procesoru 100 (maximální hodnota) značí, že server Redis byl neustále zaneprázdněn a při zpracování požadavků nebyl nikdy nečinný.

Ukázkový výstup:

# 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
  • Příkaz CLIENT LIST vrací informace a statistiky o serveru pro připojení klientů v převážně čitelné podobě.

Omezení šířky pásma sítě

Různé velikosti mezipaměti mají různé kapacity šířky pásma sítě. Pokud server překročí dostupnou šířku pásma, budou data odesílána klientovi pomaleji. U požadavků klienta může docházet k vypršení časových limitů, protože server nedokáže dostatečně rychle odesílat data do klienta.

Pokud chcete zjistit využití šířky pásma na straně serveru, můžete k tomu použít metriky Čtení z mezipaměti a Zápisy do mezipaměti. Tyto metriky můžete zobrazit na portálu. Vytvořte upozornění na metriky, jako je metrika čtení z mezipaměti nebo zápisu do mezipaměti, abyste včas dostávali upozornění na potenciální dopady.

Pokud chcete zmírnit situace, kdy se využití šířky pásma sítě blíží maximální kapacitě:

Výjimky časového limitu v StackExchange.Redis

Konkrétnější informace o řešení časových limitů při použití nástroje StackExchange.Redis najdete v tématu Zkoumání výjimek časových limitů ve StackExchange.Redis.

Související obsah

  • Last updated on