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

Tato část popisuje řešení potíží s časovým limitem, ke kterým dochází při připojování k Azure Cache for Redis.

• Opravy serveru Redis
• Výjimky časového limitu StackExchange.Redis

Opravy serveru Redis

Azure Cache for Redis serverový software pravidelně aktualizuje v rámci funkcí spravované služby, které poskytuje. Tato aktivita oprav probíhá z velké části za scénou. Během převzetí služeb při selhání při opravách uzlů serveru Redis mohou klienti Redis připojení k těmto uzlům zaznamenat dočasné časové limity při přepnutí připojení mezi těmito uzly. Další informace o opravách vedlejších účinků aplikace a o tom, jak zlepšit zpracování událostí oprav, najdete v tématu Jak převzetí služeb při selhání ovlivňuje klientskou aplikaci.

Výjimky časového limitu StackExchange.Redis

StackExchange.Redis používá nastavení konfigurace s názvem synctimeout pro synchronní operace s výchozí hodnotou 5 000 ms. Pokud synchronní volání v této době není dokončeno, klient StackExchange.Redis vyvolá chybu časového limitu podobnou následujícímu příkladu:

    System.TimeoutException: Timeout performing MGET 2728cc84-58ae-406b-8ec8-3f962419f641, inst: 1,mgr: Inactive, queue: 73, qu=6, qs=67, qc=0, wr=1/1, in=0/0 IOCP: (Busy=6, Free=999, Min=2,Max=1000), WORKER (Busy=7,Free=8184,Min=2,Max=8191)

Tato chybová zpráva obsahuje metriky, které vám můžou pomoct s příčinou a možným vyřešením problému. Následující tabulka obsahuje podrobnosti o metrikách chybových zpráv.

V předchozím příkladu výjimky obsahují oddíly IOCP WORKER a hodnotu, která je větší než Busy Min hodnota . Rozdíl znamená, že byste měli upravit ThreadPool nastavení. Můžete nakonfigurovat nastavení fondu vláken, abyste zajistili, že se fond vláken ve scénářích shlukování rychle škáluje.

Následující kroky můžete použít k eliminaci možných hlavních příčin.

1. Osvědčeným postupem je detekovat a nahrazovat pozastavená připojení pomocí modelu ForceReconnect, jak je popsáno v článku Odolnost připojení.

   Další informace o používání StackExchange.Redis najdete v tématu Připojení mezipaměti pomocí StackExchange.Redis.

2. Ujistěte se, že váš server a klientská aplikace jsou ve stejné oblasti v Azure. Například může do dochází k časovým limitům, když je mezipaměť v USA – východ ale klient je v USA – západ a požadavek se v tomto intervalu neskoní nebo při ladění z místního vývojového počítače může do dochází k časovým synctimeout limitům.

   Důrazně doporučujeme mít mezipaměť a klienta ve stejné oblasti Azure. Pokud máte scénář, který zahrnuje volání mezi oblastmi, měli byste interval nastavit na vyšší hodnotu, než je výchozí synctimeout interval 5 000 ms, zahrnutím vlastnosti do synctimeout připojovacího řetězce. Následující příklad ukazuje fragment připojovacího řetězce pro StackExchange.Redis poskytovaný Azure Cache for Redis s synctimeout 8 000 ms.

   synctimeout=8000,cachename.redis.cache.windows.net,abortConnect=false,ssl=true,password=...
   

3. Ujistěte se, že používáte nejnovější verzi balíčku StackExchange.Redis NuGet . V kódu se neustále opravují chyby, aby byly robustnější pro časové limity, takže je důležité mít nejnovější verzi.

4. Pokud jsou vaše požadavky vázány omezením šířky pásma na serveru nebo klientovi, jejich dokončení trvá déle a může způsobit časové limity. Informace o tom, jestli je časový limit kvůli šířce pásma sítě na serveru, najdete v tématu Omezení šířky pásma na straně serveru. Informace o tom, jestli je časový limit kvůli šířce pásma klientské sítě, najdete v tématu Omezení šířky pásma na straně klienta.

5. Vázané procesory jsou na serveru nebo na klientovi?

   • Zkontrolujte, jestli vás na klientovi neváže procesor. Vysoké využití procesoru může způsobit, že se požadavek v intervalu nezpracuje a časový synctimeout limit požadavku. Tento problém můžete vyřešit přesunutím na větší velikost klienta nebo distribucí zatížení.
   • Monitorováním metriky výkonu mezipaměti procesoru zkontrolujte, jestli se na serveru neváže procesor. Požadavky přicházející v době, kdy je Redis vázaná na procesor, mohou způsobit, že u těchto požadavků časový limit napadne. Pokud chcete tento stav řeší, můžete zatížení distribuovat napříč několika horizontálními oddíly v mezipaměti Premium nebo upgradovat na větší velikost nebo cenovou úroveň. Další informace najdete v tématu Omezení šířky pásma na straně serveru.

6. Zpracování příkazů na serveru trvá dlouho? Dlouhotrvá zpracování příkazů na serveru Redis může způsobit časové limity. Další informace o dlouhotr spuštěných příkazech najdete v tématu Dlouho běžící příkazy. Ke své instanci Azure Cache for Redis se můžete připojit pomocí klienta redis-cli nebo konzoly RedisConsole . Potom spusťte příkaz SLOWLOG a podívejte se, jestli jsou požadavky pomalejší, než se čekalo. Redis Server a StackExchange.Redis jsou optimalizované pro mnoho malých požadavků, nikoli pro méně velkých požadavků. Rozdělení dat do menších bloků v této oblasti může věci vylepšit.

   Informace o připojení ke koncovému bodu TLS/SSL vaší mezipaměti pomocí rozhraní příkazového řádku Redis a stunnel najdete v blogovém příspěvku Oznamující zprostředkovatele stavu relace ASP.NET pro Redis Preview.

7. Vysoké zatížení serveru Redis může způsobit časové limity. Zatížení serveru můžete monitorovat monitorováním Redis Server Load metriky výkonu mezipaměti. Zatížení serveru 100 (maximální hodnota) znamená, že server Redis je zaneprázdněný a bez doby nečinnosti zpracovává požadavky. Pokud chcete zobrazit, jestli některé požadavky zachytují všechny možnosti serveru, spusťte příkaz SlowLog, jak je popsáno v předchozím odstavci. Další informace najdete v tématu Vysoké využití procesoru / Zatížení serveru.

8. Byla na straně klienta nějaká jiná událost, která mohla způsobit tři tečky v síti? Mezi běžné události patří škálování počtu instancí klienta nahoru nebo dolů, nasazení nové verze klienta nebo povolení automatického škálování. V našem testování jsme zjistili, že automatické škálování nebo škálování nahoru nebo dolů může způsobit několik sekund ztráta odchozího síťového připojení. Kód StackExchange.Redis je vůči takovým událostem odolný a znovu se připojí. Při opětovném připojování může časový limit všech požadavků ve frontě trvat.

9. Došlo k velkému požadavku před několika malými požadavky na mezipaměť, u které došlo k časového limitu? Parametr v chybové zprávě udává, kolik požadavků bylo odesláno z klienta na server, ale nezpracuje qs odpověď. Tato hodnota může dál růst, protože StackExchange.Redis používá jedno připojení TCP a může číst pouze jednu odpověď najednou. I když u první operace časový limit vyprchá, nezastaví se tím odeslání dalších dat na server nebo ze serveru. Ostatní požadavky budou blokovány, dokud se velký požadavek nedokončí a může dojít k časovém limitu. Jedním z řešení je minimalizace pravděpodobnosti časových limitů tím, že zajistíte, aby vaše mezipaměť byla dostatečně velká pro vaši úlohu, a rozdělením velkých hodnot do menších bloků. Dalším možným řešením je použít v klientovi fond objektů a zvolit nejméně načtený fond při ConnectionMultiplexer ConnectionMultiplexer odesílání nového požadavku. Načítání napříč více objekty připojení by mělo zabránit jedinému časovému limitu, který by způsobil také časový limit jiných požadavků.

10. Pokud používáte , ujistěte se, že jste správně nastavili RedisSessionStateProvider časový limit opakování. retryTimeoutInMilliseconds hodnota by měla být operationTimeoutInMilliseconds vyšší než , jinak nedojde k opakování. V následujícím příkladu retryTimeoutInMilliseconds je nastavená na hodnotu 3000. Další informace najdete v tématu ASP.NET Zprostředkovatel stavu relace pro Azure Cache for Redis a Použití konfiguračních parametrů zprostředkovatele stavu relace a zprostředkovatele 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" />
    

11. Zkontrolujte využití paměti na Azure Cache for Redis pomocí monitorování a Used Memory RSS Used Memory . Pokud jsou zásady vyřazení na místě, Redis začne vyřazení klíčů, jakmile dosáhne Used_Memory velikosti mezipaměti. V ideálním případě Used Memory RSS by měl být pouze mírně vyšší než Used memory . Velký rozdíl znamená fragmentaci paměti (interní nebo externí). Pokud je menší než , znamená to, že část paměti Used Memory RSS Used Memory mezipaměti byla prohoděna operačním systémem. Pokud k tomuto prohození dojde, můžete očekávat významné latence. Vzhledem k tomu, že Redis nemá kontrolu nad tím, jak se jeho přidělení mapují na paměťové stránky, je vysoká často výsledkem špičky Used Memory RSS využití paměti. Když server Redis volné paměti, alokátor vezme paměť, ale může nebo nemusí dát paměť zpět do systému. Může dojít k nesrovnalostem mezi hodnotou a Used Memory spotřebou paměti hlášenou operačním systémem. Redis mohl paměť použít a uvolnit, ale nevracet ji zpět do systému. Pokud chcete zmírnit problémy s pamětí, můžete provést následující kroky:

    • Upgradujte mezipaměť na větší velikost, abyste nesní pomocí omezení paměti v systému.
    • Nastavte časy vypršení platnosti klíčů tak, aby se starší hodnoty proaktivně vyřazeny.
    • Monitorujte used_memory_rss metriku mezipaměti. Když tato hodnota přiblíží velikosti jejich mezipaměti, pravděpodobně začnete mít problémy s výkonem. Distribuujte data napříč několika horizontálními oddíly, pokud používáte mezipaměť úrovně Premium nebo upgradujte na větší velikost mezipaměti.

    Další informace najdete v tématu Tlak na paměť na serveru Redis.

Další informace

• Řešení potíží se službou Azure Cache for Redis na straně klienta
• Řešení potíží se službou Azure Cache for Redis na straně serveru
• Jak mohu srovnávací testy a testovat výkon své mezipaměti?
• Monitorování Azure Cache for Redis