Felsöka problem på Azure Cache for Redis-klientsidan

I det här avsnittet beskrivs felsökning av problem som uppstår på grund av ett villkor på Redis-klienten som programmet använder.

• Minnestryck på Redis-klienten
• Trafiktoppar
• Hög processoranvändning på klienten
• Bandbreddsbegränsning på klientsidan

Minnestryck på Redis-klienten

Minnestryck på klientdatorn leder till alla typer av prestandaproblem som kan fördröja bearbetningen av svar från cachen. När minnestrycket når kan systemet sidinläsa data till disk. Den här sidan gör att systemet blir betydligt långsammare.

Så här identifierar du minnestryck på klienten:

• Övervaka minnesanvändningen på datorn för att se till att den inte överskrider det tillgängliga minnet.
• Övervaka klientens Page Faults/Sec prestandaräknare. Under normal drift har de flesta system vissa sidfel. Toppar i sidfel i samband med timeouter för begäranden kan indikera minnestryck.

Hög minnestryck på klienten kan undvikas på flera sätt:

• Gå in på minnesanvändningsmönstren för att minska klientens minnesförbrukning.
• Uppgradera din virtuella klientdator till en större storlek med mer minne.

Trafiktoppar

Trafikstörningar i kombination med dåliga inställningar kan leda till fördröjningar i bearbetningen av data som redan skickats av Redis-servern men som ännu inte ThreadPool förbrukats på klientsidan.

Övervaka hur din ThreadPool statistik ändras med tiden med hjälp av ett exempel. ThreadPoolLogger Du kan använda TimeoutException meddelanden från StackExchange.Redis som nedan för att undersöka vidare:

    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)

I föregående undantag finns det flera intressanta problem:

• Observera att du IOCP i avsnittet och avsnittet har ett värde som är större än WORKER Busy Min värdet. Den här skillnaden innebär ThreadPool att inställningarna behöver justeras.
• Du kan också se in: 64221 . Det här värdet anger att 64 211 byte har tagits emot på klientens kernelsocketlager men inte har lästs av programmet. Den här skillnaden innebär vanligtvis att ditt program (till exempel StackExchange.Redis) inte läser data från nätverket lika snabbt som servern skickar dem till dig.

Du kan konfigurera dina ThreadPool Inställningar så att din trådpool skalas upp snabbt under burst-scenarier.

Hög processoranvändning på klienten

Hög cpu-användning för klienten indikerar att systemet inte kan hålla reda på det arbete som det har ombads att göra. Även om cachen skickade svaret snabbt kan klienten misslyckas med att bearbeta svaret inom rimlig tid.

Övervaka klientens processoranvändning i hela systemet med hjälp av mått som är Azure Portal eller via prestandaräknare på datorn. Var noga med att inte övervaka processprocessorn eftersom en enda process kan ha låg CPU-användning, men den systemomfattande processorn kan vara hög. Håll utkik efter toppar i CPU-användning som motsvarar tidsgränser. Hög CPU-användning kan också in: XXX orsaka höga värden i TimeoutException felmeddelanden enligt beskrivningen i avsnittet Traffic burst.

Så här minimerar du en klients höga CPU-användning:

• Undersök vad som orsakar CPU-toppar.
• Uppgradera klienten till en större VM-storlek med mer CPU-kapacitet.

Bandbreddsbegränsning på klientsidan

Beroende på klientdatorers arkitektur kan de ha begränsningar för hur mycket nätverksbandbredd de har tillgänglig. Om klienten överskrider den tillgängliga bandbredden genom att överbelasta nätverkskapaciteten bearbetas inte data på klientsidan lika snabbt som servern skickar den. Den här situationen kan leda till tidsgränser.

Övervaka hur bandbreddsanvändningen ändras med tiden med hjälp av ett exempel. BandwidthLogger Den här koden kanske inte kan köras i vissa miljöer med begränsade behörigheter (till exempel Azure-webbplatser).

Minska förbrukningen av nätverksbandbredd eller öka storleken på den virtuella klientdatorn till en med mer nätverkskapacitet.

Höga klientanslutningar

Klientanslutningar som når maxvärdet för cacheminnet kan orsaka fel i klientbegäranden för anslutningar utöver det högsta, och kan också orsaka hög processoranvändning på cachen på grund av bearbetning av upprepade återanslutningsförsök.

Höga klientanslutningar kan tyda på en anslutningsläcka i klientkoden. Anslutningar kanske inte används på rätt sätt eller stängs på rätt sätt. Granska klientkoden för användning av anslutningar.

Om de höga anslutningarna är legitima och obligatoriska klientanslutningar kan det krävas att du uppgraderar cacheminnet till en storlek med en högre anslutningsgräns.

Ytterligare information

• Felsöka problem på Azure Cache for Redis-serversidan
• Hur kan jag prestandatesta och prestanda för mitt cacheminne?