Sdílet prostřednictvím


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

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 (Preview).

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 Managed Redis a jak používat konfigurační parametry zprostředkovatele stavu relace a poskytovatele 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á 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ématu Odolnost připojení.

Vysoké využití procesoru

Vysoké využití procesoru 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 procesor. Sledujte špičky využití CPU , které odpovídají časovým limitům. Vytvořte upozornění na metriky týkající se procesoru, které se budou včas informovat o potenciálních dopadech.

Pokud chcete zmírnit vysoké využití 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 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 tématu Architektura Azure Managed Redis.
  • Pokud je vaše produkční úloha v mezipaměti negativně ovlivněná latencí některých spuštění interní kontroly defenderu, můžete snížit účinek migrací mezipaměti na úroveň optimalizovanou pro výpočty nebo škálováním na vyšší nabídku s větším počtem jader procesoru.

Špičky v procesoru

V mezipamětí B0, B1, B3 a B5 se může zobrazit krátké špičky procesoru, 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 těchto úrovních mají pouze dvě jádra pro vícetask a rozdělují práci obsluhy interní kontroly defenderu a požadavků Redis.

Vysoké využití paměti

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

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.