Sdílet prostřednictvím

Řešení potíží s latencí a časovými limity služby Azure Managed Redis (Preview)

  • Č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 Managed Redis (Preview).

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.

Prudké zvýšení 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 hostitelé klientů dokáží držet krok s náhlým zvýšením provozu.

Pomocí příkladuThreadPoolLogger můžete sledovat, jak se mění statistiky ThreadPool v průběhu času . 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.
  • Můžete se také setkat se zprávou 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á.

Nastavení ThreadPool můžete nakonfigurovat tak, abyste zajistili rychlé škálování fondu vláken 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ší 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ž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 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 zachovat u procesoru klienta méně než 80% využití. 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 špičky využití procesoru, které odpovídají vypršení č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 části [Prudké zvýšení provozu].

Poznámka:

StackExchange.Redis 1.1.603 a novější obsahuje v TimeoutException chybových zprávách metriku local-cpu. 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ů.

Změny využití šířky pásma v průběhu času můžete sledovat pomocí ukázkového nástroje BandwidthLogger. 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 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í 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 najdete v tématech Zprostředkovatel stavu relací ASP.NET pro Azure Managed Redis a Jak používat konfigurační parametry zprostředkovatele stavu relací 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 u operace, která při převzetí služeb při selhání odešle požadavek, ale neobdrží odpověď, 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 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 špičky využití prostředku CPU, které odpovídají vypršení časových limitů. 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álováním na více instancí zvyšte počet horizontálních oddílů, aby se zatížení distribuovalo mezi více procesů Redis, případně vertikálně 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 nadměrnou latencí některých spuštěných interních kontrol 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 vytížení procesoru

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. 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 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. Každý dlouhotrvající příkaz zablokovat všechny další příkazy.

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). Špičky využití procesoru můžete snížit tím, že místo příkazu KEYS použijete 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 z konzoly zkoumat dlouhotrvající a náročné příkazy pomocí těchto příkazů Redis.

  • 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. 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 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 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