Sdílet prostřednictvím

Řešení potíží s latencí a časovými limity služby Azure Cache for Redis

  • Platí pro: ✅ Azure Cache for Redis

Důležité

Služba Azure Cache for Redis oznámila časovou osu vyřazení všech skladových položek. Doporučujeme přesunout stávající instance Azure Cache for Redis do Azure Managed Redis , jakmile budete moct.

Další podrobnosti o ukončení podpory:

Operace klienta Azure Cache for Redis, která neobdrží včasnou odpověď, může způsobit vysokou latenci nebo výjimku časového limitu. Tento článek vysvětluje, jak řešit běžné problémy, které můžou vést k vysoké latenci a vypršení časových limitů.

U operace může docházet k problémům nebo vypršení časového limitu v různých fázích. Zdroj problému pomáhá určit příčinu a zmírnění rizik. Tento článek je rozdělený na problémy na straně klienta a na straně serveru.

Problémy na straně klienta

Problémy na straně serveru

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

Následující problémy na straně klienta můžou ovlivnit latenci a výkon a vést k vypršení časových limitů.

Vysoký počet připojení klientů

Požadavky klientů na připojení klientů nad rámec maxima mezipaměti můžou selhat. Vysoká počet klientských připojení může také způsobit vysoké zatížení serveru při opakovaném pokusu o opětovné připojení.

Vysoký počet klientských připojení může naznačovat únik připojení v klientském kódu. Připojení nemusí být správně znovu použita nebo uzavřena. Zkontrolujte použití připojení v klientském kódu.

Pokud je vysoký počet připojení legitimní a jedná se o požadovaná klientská připojení, možná bude nutné upgradovat mezipaměť na velikost s vyšším limitem připojení. Zkontrolujte, jestli je maximální agregace Připojených klientů blízko nebo vyšší než maximální povolený počet připojení pro velikost vaší mezipaměti. Další informace o nastavení velikosti jednotlivých klientských připojení najdete v tématu Výkon služby Azure Cache for Redis.

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

Vysoké využití procesoru klienta znamená, že systém nemůže držet krok s prací přiřazenou k němu. I když mezipaměť odešle odpověď rychle, klient nemusí dostatečně rychle zpracovat odpověď. Nejlepší je zachovat procesor klienta na méně než 80%.

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

  • Prozkoumejte příčinu špiček procesoru.
  • Upgradujte klienta na větší velikost virtuálního počítače s větší kapacitou procesoru.

Monitorujte využití procesoru celého systému klienta pomocí metrik dostupných na webu Azure Portal nebo prostřednictvím čítačů výkonu na virtuálním počítači. Zkontrolujte chyby metrik (typ: UnresponsiveClients) a zjistěte, jestli hostitelé klientů můžou zpracovávat odpovědi ze serveru Redis včas.

Dávejte pozor, abyste nemonitorovali procesor, protože jeden proces může mít nízké využití procesoru, ale procesor 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é zatížení procesoru může také způsobit vysoké in: XXX hodnoty v timeoutException chybových zprávách. Příklad najdete v části Konfigurace fondu přenosů dat a fondu vláken .

StackExchange.Redis 1.1.603 a novější obsahuje metriku local-cpu v timeoutException chybových zprávách. Ujistěte se, že používáte nejnovější verzi balíčku StackExchange.Redis NuGet, protože chyby jsou pravidelně opraveny, aby byl kód odolnější vůči vypršení časových limitů. Další informace najdete v tématu Zkoumání timeout výjimek v StackExchange.Redis.

Velké hodnoty klíčů

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

Zmírnění problému:

  • Zvyšte velikost virtuálního počítače, abyste získali vyšší 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 virtuálních počítačích s limity vašich aktuálních velikostí virtuálních počítačů. Větší šířka pásma na serveru nebo klientovi nemusí být dostatečná.

  • Zvyšte počet objektů připojení, které vaše aplikace používá. Pomocí přístupu round-robin provádějte požadavky na různé objekty připojení. Informace o použití více klíčů a menších hodnot najdete v tématu Zvažte více klíčů a menší hodnoty.

Zatížení paměti u klienta Redis

Zatížení paměti na klienta může vést k problémům s výkonem, které zpožďují zpracování odpovědí mezipaměti. Když dojde k zatížení paměti, může systém odkládat data na disk. Chyba této stránky způsobí, že se systém výrazně zpomalí.

Zjištění zatížení paměti u klienta:

  • Monitorujte využití paměti na virtuálním počítači a ujistěte se, že nepřekračuje dostupnou paměť.
  • Monitorujte čítač výkonu Page Faults/Sec klienta. Během normálního provozu má většina systémů několik chyb stránky. Špičky ve výskytech chyb stránkování související s překročením časového limitu požadavků mohou naznačovat nedostatek paměti.

Zmírnění vysokého zatížení paměti u klienta:

  • Prozkoumejte vzory využití paměti, abyste snížili spotřebu paměti v klientovi.
  • Upgradujte klientský virtuální počítač na větší velikost s větší pamětí.

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

Klientské počítače můžou mít v závislosti na své architektuře omezení dostupnosti šířky pásma sítě. Pokud klient překročí dostupnou šířku pásma přetížením síťové kapacity, data se nezpracují na straně klienta tak rychle, jak ho server odesílá. 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.

RedisSessionStateProvider doba opakovaného pokusu

Pokud používáte RedisSessionStateProvider, ujistěte se, že jste správně nastavili retryTimeout . 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 retryTimeoutInMilliseconds je nastavena 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"
>

Nastavení protokolu TCP pro klientské aplikace v Linuxu

Klientské aplikace hostované v Linuxu můžou mít problémy s připojením kvůli optimistickému nastavení protokolu TCP v Linuxu. Další informace najdete v tématu Nastavení protokolu TCP pro klientské aplikace hostované v Linuxu.

Náhlý nárůst provozu a konfigurace vláknového fondu

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: Nereagující klienti) a ověřte, zda hostitelé klientů zvládnou náhlé špičky provozu. Nastavení fondu vláken můžete nakonfigurovat tak, aby se fond vláken rychle navyšoval při nárazových scénářích.

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)

Předchozí výjimka ukazuje několik problémů.

  • V oddílu IOCP a oddílu WORKER je hodnota Busy větší než hodnota Min, což znamená, že je potřeba upravit ThreadPool nastavení.
  • Hodnota in: 64221 označuje, že v vrstvě soketu jádra klienta byla přijata 64 221 bajtů, ale aplikace je nečte. Tento rozdíl obvykle znamená, že vaše aplikace, například StackExchange.Redis, nečte data ze sítě tak rychle, jak ji server odesílá.

StackExchange.Redis 1.1.603 a novější obsahuje metriku local-cpu v timeoutException chybových zprávách. Ujistěte se, že používáte nejnovější verzi balíčku StackExchange.Redis NuGet, protože chyby jsou pravidelně opraveny, aby byl kód odolnější vůči vypršení časových limitů. Další informace najdete v tématu Zkoumání výjimek časového limitu ve službě StackExchange.Redis.

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

Následující problémy na straně serveru můžou ovlivnit výkon a vést k vypršení časových limitů.

Vysoké využití paměti

Zatížení paměti na serveru může vést k různým problémům s výkonem, které zpožďují zpracování požadavků. Když dojde k zatížení paměti, systém stránkuje data na disk, což způsobuje, že se systém výrazně zpomalí.

Mezi možné příčiny zatížení paměti patří to, že mezipaměť je naplněna daty téměř ke své maximální kapacitě nebo že server Redis má vysokou fragmentaci paměti.

Fragmentace je pravděpodobně v případě, že vzor zatížení ukládá data s vysokou variací velikosti, například když jsou data rozložená do velikosti 1 kB a 1 MB. Když dojde k odstranění klíče o velikosti 1 kB z existující paměti, klíč o velikosti 1 MB se do prostoru nevejde, což způsobuje fragmentaci. Podobně pokud dojde k odstranění klíče o velikosti 1 MB, přidaný klíč o velikosti 1,5 MB se do stávající uvolněné paměti nevejde. Výsledkem této nevyužité volné paměti je fragmentace.

Pokud je mezipaměť fragmentovaná a běží pod vysokým zatížením paměti, systém provede přepnutí na záložní systém a pokusí se obnovit paměť velikosti rezidentního souboru (RSS). Redis zveřejňuje dvě statistiky, used_memory a used_memory_rss, prostřednictvím příkazu INFO, což vám může pomoci identifikovat tento problém. Tyto metriky můžete zobrazit také na webu Azure Portal.

Pokud je used_memory_rsshodnota vyšší než 1,5násobekused_memory metriky, dochází k fragmentaci paměti. Fragmentace může způsobit problémy v následujících případech:

  • Využití paměti se blíží maximálnímu limitu paměti pro mezipaměť.
  • Metrika used_memory_rss je vyšší než maximální limit paměti, což může mít za následek chybu stránky v paměti.

Můžete provést několik akcí, které vám pomůžou udržet využití paměti v pořádku.

Další doporučení ke správě paměti najdete v tématu Osvědčené postupy pro správu paměti.

Vysoké zatížení serveru

Vysoké zatížení serveru znamená, že server Redis je zaneprázdněný a nemůže držet krok s požadavky, což vede k vypršení časového limitu nebo pomalým odpovědím. Pokud chcete zmírnit vysoké zatížení serveru, nejprve prozkoumejte příčinu, například dlouhotrvající příkazy kvůli vysokému zatížení paměti.

Metriky, jako je zatížení serveru, můžete monitorovat na webu Azure Portal. Pokud chcete zkontrolovat metriku zatížení serveru, vyberte Insights v části Monitorování z levého navigačního menu na stránce mezipaměti a zobrazte graf zatížení serveru. Nebo v levé navigační nabídce vyberte Metriky, a pak v části Metriky vyberte Zatížení serveru.

Sledujte špičky ve využití zatížení serveru, které souvisí s časovými limity. Vytvořte upozornění na metriky zatížení serveru, abyste byli včas informováni o potenciálních dopadech.

Špičky zatížení serveru

U mezipamětí C0 a C1 se můžou zobrazovat krátké špičky v zatížení serveru, které nejsou způsobené nárůstem požadavků, zatímco na virtuálních počítačích běží interní kontrola Defenderu. Na těchto úrovních uvidíte vyšší latenci požadavků, zatímco dochází k interním kontrolám Defenderu.

Mezipaměti na úrovních C0 a C1 mají pouze jedno jádro pro multitasking, což rozděluje práci obsluhy skenování interního Defenderu a požadavků systému Redis. Pokud dodatečná latence z interních kontrol Defenderu negativně působí na vaše produkční úlohy v mezipaměti C1, můžete škálovat na nabídku vyšší úrovně, která obsahuje více procesorových jader, jako je C2. Další informace najdete v tématu Volba správné úrovně.

Další informace o rychlých změnách počtu připojení klientů naleznete v tématu Vyhněte se špičkám připojení klientů.

Stupňování

Škálováním na více horizontálních oddílů můžete distribuovat zatížení napříč několika procesy Redis nebo vertikálně navýšit kapacitu na větší velikost mezipaměti s větším využitím jader procesoru. Operace škálování jsou náročné na procesor a paměť, protože mohou zahrnovat přesun dat kolem uzlů a změnu topologie clusteru. Další informace najdete v tématu Nejčastější dotazy k plánování služby Azure Cache for Redis a škálování.

Dlouhotrvající příkazy

Některé příkazy Redis jsou náročnější na spuštění než jiné. Dokumentace k příkazům Redis ukazuje časovou složitost jednotlivých příkazů. Zpracování příkazů Redis probíhá v jednom vláknu. Jakýkoli příkaz, který trvá dlouhou dobu, může blokovat ostatní, kteří ho následují.

Projděte si příkazy, které na serveru Redis vydáváte, a seznamte se s jejich dopadem na výkon. Například příkaz KEYS se často používá bez vědomí, že se jedná o operaci big O Notation (O(N).) Pokud chcete snížit špičky procesoru, můžete se vyhnout KEYS pomocí funkce SCAN.

V konzole můžete spustit následující příkazy Redis, abyste prozkoumali dlouhotrvající a nákladné příkazy.

  • SEZNAM KLIENTŮ

    Příkaz CLIENT LIST vrátí informace a statistiky o serveru připojení klientů v převážně čitelné podobě.

  • INFORMACE

    Příkaz INFO vrátí informace a statistiky o serveru ve formátu, který je jednoduchý pro počítače k analýze a snadnému čtení lidí. Tato CPU část může být užitečná k prozkoumání využití procesoru. server_load Hodnota 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ý.

    Následující příklad ukazuje výstup příkazu 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 je ladicí příkaz, který streamuje všechny příkazy zpracovávané serverem Redis. MONITOR vám může pomoct pochopit, co se děje s databází. Tento příkaz je náročný a může negativně ovlivnit a snížit výkon.

  • SLOWLOG

    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 nebo odeslání odpovědi, ale pouze doba potřebná k provedení příkazu.

    Příkaz SLOWLOG čte a resetuje protokol pomalých dotazů Redis a dá se také použít k prošetření dlouhotrvajících příkazů na straně klienta. Pomocí příkazu SLOWLOG GET můžete monitorovat a protokolovat nákladné příkazy spouštěné na serveru Redis.

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, data se klientovi neodesílají tak rychle. 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.

Metriky, jako je čtení mezipaměti a zápis do mezipaměti, můžete monitorovat na webu Azure Portal a zjistit, kolik šířky pásma na straně serveru se používá. Vytvořte upozornění na tyto metriky, abyste byli včas informováni o potenciálních dopadech.

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

  • Změňte chování volání klienta tak, aby se snížila poptávka po síti.
  • Škálujte na větší velikost mezipaměti s větší kapacitou šířky pásma sítě. Další informace najdete v nejčastějších dotazech k plánování služby Azure Cache for Redis.

Ú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í.

Pokud vaše mezipaměť Azure Redis prochází procesem převzetí služeb při selhání, všechna klientská připojení z uzlu, který přestal fungovat, se přenesou na uzel, který je stále funkční. Zatížení serveru se může zvýšit kvůli zvýšenému počtu připojení. Můžete zkusit restartovat klientské aplikace, aby se všechna připojení klientů vytvořila znovu a redistribuovala mezi oba uzly.

Při převzetí služeb při selhání může dojít k výjimce timeout u operace, která odešle požadavek, ale neobdrží odpověď. 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í.

Chcete-li zjistit, zda vaše Azure Redis cache měla převzetí služeb při selhání v době, kdy došlo k výjimkám timeout, zkontrolujte metriku Chyby. Na stránce Azure portálu pro vaši mezipaměť vyberte v části Monitorování v levé navigační nabídce Metriky. Potom vytvořte nový graf, který měří metriku Chyby a rozdělí ho podle typu ErrorType. Po vytvoření tohoto grafu uvidíte počet případů převzetí při selhání. Další informace o převzetí služeb při selhání a aktualizacích pro Azure Cache for Redis naleznete v tématu Převzetí služeb při selhání a aktualizace pro Azure Cache for Redis.

Další informace o zmírnění problémů kvůli údržbě serveru najdete v následujících článcích:

Související obsah

  • Last updated on