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

  • Článek

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

Poznámka:

Několik kroků 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í potíží na straně klienta

Tady je řešení potíží na straně klienta.

Prudké zvýšení provozu a konfigurace fondu vláken

Nárůsty provozu v kombinaci s nízkým ThreadPool nastavením můžou vést ke zpoždění při zpracování dat, která už server Redis odeslal, ale ještě není spotřebován na straně klienta. Zkontrolujte metriku Chyby (typ: UnresponsiveClients) a ověřte, jestli hostitelé klientů dokáží držet krok s náhlým zvýšením provozu.

Pomocí příkladu můžete sledovat, jak ThreadPool se mění statistiky v průběhu času .ThreadPoolLogger 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 problémů:

  • Všimněte si, že v oddílu IOCP a oddílu WORKER máte Busy hodnotu, která je větší než Min hodnota. Tento rozdíl znamená, že vaše ThreadPool nastavení je potřeba upravit.
  • Můžete také vidět in: 64221. Tato hodnota označuje, že v vrstvě soketu jádra klienta bylo přijato 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 vám server odesílá.

Nastavení můžete nakonfigurovat ThreadPool tak, aby se zajistilo, že se fond vláken rychle škáluje ve scénářích s 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ších hodnot.

Příkaz můžete použít redis-cli --bigkeys ke kontrole velkých klíčů v mezipaměti. 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ší odpovědi.
    • 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 jenom 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žití metody kruhového dotazování k vytváření požadavků přes různé objekty připojení

Vysoké využití procesoru na hostitelích klientů

Vysoké využití procesoru klienta znamená, že systém nemůže držet krok s prací, která je k němu přiřazená. I když mezipaměť odeslala odpověď rychle, klient nemusí včas zpracovat odpověď. Naším doporučením je zachovat procesor klienta méně než 80 %. Zkontrolujte metriku Chyby (Typ: UnresponsiveClients) a zjistěte, jestli hostitelé klientů můžou zpracovávat odpovědi ze serveru Redis včas.

Monitorujte využití procesoru na úrovni celého systému klienta pomocí metrik dostupných na webu Azure Portal nebo prostřednictvím čítačů výkonu na počítači. 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 špičky využití procesoru, které odpovídají vypršení časových limitů. Vysoké využití procesoru může také způsobit vysoké in: XXX hodnoty v TimeoutException chybových zprávách, jak je popsáno v části [Nárůst provozu].

Poznámka:

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. Chyby jsou v kódu pravidelně opraveny, aby byly robustnější pro vypršení časových limitů. Je důležité mít nejnovější verzi.

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

  • Prozkoumejte, co způsobuje špičky 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čů můžou mít omezení, jakou šířku pásma sítě mají k dispozici. 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 vést k vypršení časových limitů.

Pomocí příkladu BandwidthLoggersledujte, jak se mění využití šířky pásma v průběhu času . Tento kód se nemusí úspěšně spustit v některých prostředích s omezenými oprávněními (jako jsou weby Azure).

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 jeden s větší kapacitou sítě. Další informace najdete v tématu Velký požadavek nebo velikost odpovědi.

Nastavení protokolu TCP pro klientské aplikace založené na Linuxu

Kvůli optimistickému nastavení PROTOKOLU TCP v Linuxu můžou klientské aplikace hostované v Linuxu zaznamenat 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í RedisSessionStateProvider

Pokud používáte RedisSessionStateProvider, ujistěte se, že jste správně nastavili časový limit opakování. Hodnota retryTimeoutInMilliseconds by měla být vyšší než operationTimeoutInMilliseconds hodnota. V opačném případě nedojde k žádným opakovaným pokusům. V následujícím příkladu retryTimeoutInMilliseconds je nastavená hodnota 3000. Další informace najdete v tématu ASP.NET Zprostředkovatel stavu relace pro Azure Cache for Redis a použití parametrů konfigurace zprostředkovatele stavu relace a poskytovatele výstupní mezipaměti.

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

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

Tady je ř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á odešle požadavek, ale neobdrží odpověď, když dojde k převzetí služeb při selhání, může dojít k výjimce časového limitu. Nové požadavky na objekt uzavřeného připojení přijímají výjimky připojení, dokud se opětovné připojení úspěšně neskončí.

Další informace najdete v těchto dalších částech:

Pokud chcete zkontrolovat, jestli vaše služba Azure Cache for Redis měla převzetí služeb při selhání během vypršení časových limitů, zkontrolujte chyby metrik. V nabídce Prostředek na webu Azure Portal vyberte Metriky. Pak vytvořte nový graf, který měří metriku Errors a rozdělí ho ErrorType. Po vytvoření tohoto grafu se zobrazí počet převzetí služeb při selhání.

Další informace o převzetí služeb při selhání najdete v tématu Převzetí služeb při selhání a opravy pro Azure Cache for Redis.

Vysoké zatížení serveru

Vysoké zatížení serveru znamená, že server Redis nemůž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 zatížení serveru. Sledujte špičky využití Server Load , které odpovídají časovým limitům. Vytvořte upozornění na metriky na zatížení serveru, abyste byli včas informováni o potenciálních dopadech.

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

  • Prozkoumejte, co způsobuje vysoké zatížení serveru, jako jsou dlouhotrvající příkazy, které jsou uvedené v tomto článku kvůli vysokému zatížení paměti.
  • Horizontálně navyšte kapacitu na více horizontálních oddílů a rozdělte zatížení mezi více procesů Redis nebo vertikálně navyšte kapacitu na větší velikost mezipaměti s větším využitím jader procesoru. Další informace najdete v nejčastějších dotazech k plánování služby Azure Cache for Redis.
  • Pokud je vaše produkční úloha v mezipaměti C1 negativně ovlivněná latencí některých spuštění interní kontroly defenderu, můžete snížit účinek škálováním na vyšší úroveň s více jádry procesoru, jako je C2.

Š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ů několikrát denně, zatímco na virtuálních počítačích běží kontrola interního defenderu. Při kontrole interního defenderu na těchto úrovních se zobrazí vyšší latence požadavků. Mezipaměti na úrovních C0 a C1 mají pouze jedno jádro pro vícetask, které rozdělí práci obsluhy interního prohledávání defenderu a požadavků Redis.

Vysoké využití paměti

Tento oddíl byl přesunut. Další informace naleznete 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é. 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 všechny ostatní, které po něm přicházejí.

Projděte si příkazy, které vydáváte na server Redis, 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 O(N). Klíče se můžete vyhnout pomocí funkce SCAN , abyste snížili špičky procesoru.

Pomocí příkazu SLOWLOG GET můžete měřit nákladné příkazy, které se spouštějí na serveru.

Zákazníci můžou pomocí konzoly spouštět tyto příkazy Redis k prozkoumání dlouhotrvajících a drahých příkazů.

  • SLOWLOG se používá ke čtení a resetování protokolu pomalých dotazů Redis. Dá se použít k prošetření dlouhotrvajících příkazů na straně klienta. Pomalý protokol Redis je systém pro protokolování dotazů, které překročily zadanou 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 měřit nebo protokolovat nákladné příkazy spouštěné na serveru SLOWLOG Redis.
  • MONITOR je ladicí příkaz, který streamuje všechny příkazy zpracovávané serverem Redis. Může vám pomoct 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.
  • INFO - příkaz vrátí informace a statistiky o serveru ve formátu, který je jednoduchý k parsování podle počítačů a snadno čitelný člověkem. V takovém případě může být užitečné prozkoumat využití procesoru. Zatížení serveru 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ázka výstupu:

# 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 – vrací informace a statistiky o serveru 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, 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.

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ě:

  • Změňte chování volání klienta, aby se snížila poptávka po síti.
  • Škálování 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.

Výjimky časového limitu StackExchange.Redis

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

Související obsah