Řešení potíží se službou Azure Cache for Redis na straně klienta

Tato část popisuje řešení potíží, ke kterým dochází kvůli podmiňování klienta Redis, který vaše aplikace používá.

• Tlak na paměť na klientovi Redis
• Prudké zvýšení provozu
• Vysoké využití procesoru klienta
• Omezení šířky pásma na straně klienta

Tlak na paměť na klientovi Redis

Tlak na paměť na klientském počítači vede k nejrůznějším problémům s výkonem, které mohou zpozdit zpracování odpovědí z mezipaměti. Když dojde k poklesu tlaku paměti, systém může stránkovat data na disk. Chyba na této stránce způsobí výrazné zpomalení systému.

Zjištění tlaku na paměť na straně klienta:

• Monitorujte využití paměti na počítači a ujistěte se, že nepřekračuje dostupnou paměť.
• Monitorujte čítač Page Faults/Sec výkonu klienta. Během normálního provozu má většina systémů určité chyby stránkování. Špičky chyb stránkování odpovídající vypršením časových limitů požadavků můžou značit zatížení paměti.

Vysoké nároky na paměť klienta je možné zmírnit několika způsoby:

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

Prudké zvýšení provozu

Shluky provozu v kombinaci s špatným nastavením mohou vést ke zpožděním při zpracování dat, která už server Redis odeslal, ale ještě se nevyužívali ThreadPool na straně klienta.

Pomocí příkladu ThreadPool můžete monitorovat, jak se statistika v průběhu času ThreadPoolLogger mění. K dalšímu TimeoutException prošetření můžete použít zprávy z StackExchange.Redis jako níže:

    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 je několik zajímavých problémů:

• Všimněte IOCP si, že v WORKER oddílu a oddílu máte Busy hodnotu, která je větší než Min hodnota. Tento rozdíl znamená, ThreadPool že nastavení je potřeba upravit.
• Můžete také vidět in: 64221 . Tato hodnota znamená, že ve vrstvě soketu klienta bylo přijato 64 211 bajtů, ale aplikace je nečetla. Tento rozdíl obvykle znamená, že vaše aplikace (například StackExchange.Redis) nečítá data ze sítě tak rychle, jak vám je server odesílá.

Můžete nakonfigurovat vlastní Nastavení ThreadPool zajistit, aby se fond vláken ve scénářích shlukování rychle škáluje.

Vysoké využití procesoru klienta

Vysoké využití procesoru klienta znamená, že systém nemůže držet pod nácemi, o které byl požádán. I když mezipaměť odeslala odpověď rychle, klientovi se nemusí podařit odpověď včas zpracovat.

Monitorujte využití procesoru na úrovni celého systému klienta pomocí metrik dostupných v Azure Portal nebo prostřednictvím čítačů výkonu na počítači. Dávejte pozor, abyste ne monitorovat procesor procesu, protože jeden proces může mít nízké využití procesoru, ale procesor celého systému může být vysoký. Sledujte špičky využití procesoru, které odpovídají časovým limitům. Vysoké využití procesoru může také způsobovat in: XXX vysoké hodnoty v chybových zprávách, jak TimeoutException je popsáno v části Sesunutí provozu.

Zmírnění vysokého 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 na straně klienta

V závislosti na architektuře klientských počítačů mohou mít omezení, kolik šířky pásma sítě mají k dispozici. Pokud klient přetíží dostupnou šířku pásma přetížením kapacity sítě, nezpracují se data na straně klienta tak rychle, jak je server odesílá. Tato situace může vést k časovým limitům.

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

Pokud chcete tento riziko zmírnit, snižte využití šířky pásma sítě nebo zvětšete velikost klientského virtuálního počítače na jeden virtuální počítač s větší kapacitou sítě.

Vysoká připojení klientů

Připojení klientů dosahující maximálního využití mezipaměti mohou způsobit chyby v požadavcích klientů na připojení nad rámec maximálního počtu a mohou také způsobit vysoké využití procesoru serveru v mezipaměti z důvodu zpracování opakovaných pokusů o opětovné připojení.

Vysoká připojení klientů mohou indikovat nevrácení připojení v klientském kódu. Připojení se nemusí znovu používat nebo správně zavírá. Zkontrolujte použití připojení v kódu klienta.

Pokud jsou všechna vysoká připojení legitimní a požadovaná připojení klientů, může být potřeba upgradovat mezipaměť na velikost s vyšším limitem připojení.

Další informace

• Řešení potíží se službou Azure Cache for Redis na straně serveru
• Jak můžu srovnávací testy a otestovat výkon mezipaměti?