Dela via

Felsöka svarstider och timeouter för Azure Cache for Redis

  • Gäller för: ✅ Azure Cache for Redis

Viktigt!

Azure Cache for Redis meddelade sin tidslinje för pensionering för alla SKU:er. Vi rekommenderar att du flyttar dina befintliga Azure Cache for Redis-instanser till Azure Managed Redis så snart du kan.

Mer information om pensionering:

En Azure Cache for Redis-klientåtgärd som inte får ett svar i tid kan orsaka långa svarstider eller ett timeout-undantag. Den här artikeln beskriver hur du felsöker vanliga problem som kan leda till långa svarstider och tidsgränser.

En åtgärd kan uppleva problem eller tidsgränser i olika skeden. Orsaken till problemet hjälper till att fastställa orsaken och begränsningen. Den här artikeln är indelad i problem på klientsidan och på serversidan.

Problem på klientsidan

Problem på serversidan

Felsöka problem på klientsidan

Följande problem på klientsidan kan påverka svarstid och prestanda och leda till tidsgränser.

Höga klientanslutningar

Klientbegäranden för klientanslutningar som överskrider maxgränsen för cacheminnet kan misslyckas. Höga klientanslutningar kan också orsaka hög serverbelastning vid bearbetning av upprepade återanslutningsförsök.

Höga klientanslutningar kan tyda på en anslutningsläcka i klientkoden. Anslutningar kanske inte återanvänds eller stängs korrekt. Granska klientkoden för anslutningsanvändning.

Om de höga anslutningarna alla är legitima och nödvändiga klientanslutningar kan du behöva uppgradera cacheminnet till en storlek med en högre anslutningsgräns. Kontrollera om måttet Max för anslutna klienter är nära eller högre än det maximala antalet tillåtna anslutningar för din cachestorlek. För mer information om dimensionering per klientanslutningar, se Prestanda för Azure Cache for Redis.

Hög processoranvändning på klientvärdar

Hög klient-CPU-användning indikerar att systemet inte kan hålla jämna steg med det arbete som tilldelats det. Även om cachen skickar svaret snabbt kan klienten misslyckas med att bearbeta svaret tillräckligt snabbt. Det är bäst att hålla klientens CPU på mindre än 80%.

Så här minimerar du en klients höga processoranvändning:

  • Undersöka orsaken till CPU-toppar.
  • Uppgradera klienten till en större storlek på den virtuella datorn (VM) med mer CPU-kapacitet.

Övervaka klientens systemomfattande CPU-användning med hjälp av mått som är tillgängliga i Azure-portalen eller via prestandaräknare på den virtuella datorn. Kontrollera mätvärdet Fel (Typ: Klienter som inte svarar) för att avgöra om klientvärdarna kan bearbeta svar från Redis-servern i tid.

Var noga med att inte övervaka process-CPU, 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 processoranvändningen som motsvarar utgångstider. Hög CPU kan också orsaka höga in: XXX värden i timeoutException felmeddelanden. Se avsnittet trafikrusning och konfiguration av trådpool för ett exempel.

StackExchange.Redis 1.1.603 och senare inkluderar mätvärdet local-cpu i felmeddelanden timeoutException. Se till att använda den senaste versionen av NuGet-paketet StackExchange.Redis eftersom buggar regelbundet åtgärdas för att göra koden mer resistent mot tidsgränser. Mer information finns i Undersöka timeout undantag i StackExchange.Redis.

Stora nyckelvärden

Du kan använda kommandot redis-cli --bigkeys för att söka efter stora nycklar i cacheminnet. Mer information om redis-cli, redis-kommandoradsgränssnittet, finns i Redis CLI.

Så här åtgärdar du problemet:

  • Öka storleken på den virtuella datorn för att få högre bandbreddsfunktioner. Mer bandbredd på den virtuella klient- eller serverdatorn kan minska dataöverföringstiderna för större svar. Jämför din aktuella nätverksanvändning på båda de virtuella datorerna med gränserna för dina aktuella VM-storlekar. Mer bandbredd på bara servern eller klienten kanske inte räcker.

  • Öka antalet anslutningsobjekt som programmet använder. Använd en rundgångsmetod för att göra förfrågningar över olika anslutningsobjekt. Information om hur du använder flera nycklar och mindre värden finns i Överväg fler nycklar och mindre värden.

Minnestryck på Redis-klienten

Minnesbelastning på klienten kan leda till prestandaproblem som fördröjer bearbetningen av cachesvar. När minnesbelastning uppstår kan systemet skicka data till disken. Den här sidans fel gör att systemet blir betydligt långsammare.

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

  • Övervaka minnesanvändningen på den virtuella datorn för att se till att den inte överskrider tillgängligt minne.
  • Övervaka klientens Page Faults/Sec prestandaräknare. Under normal drift har de flesta system vissa sidfel. Toppar i sidfel som motsvarar tidsgränser för begäran kan indikera minnestryck.

Så här minskar du hög minnesbelastning på klienten:

  • Undersök minnesanvändningsmönstren för att minska minnesförbrukningen på klienten.
  • Uppgradera den virtuella klientdatorn till en större storlek med mer minne.

Begränsning av nätverksbandbredd på klientvärdar

Beroende på deras arkitektur kan klientdatorer ha begränsningar för nätverksbandbreddens tillgänglighet. 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änsöverskridanden.

För att åtgärda problemet, minska nätverksbandbreddens användning eller uppgradera den virtuella klientdatorn till en med större nätverkskapacitet. För mer information, se Stor storlek på förfrågan eller svar.

RedisSessionStateProvider retryTimeout

Om du använder RedisSessionStateProviderkontrollerar du att du har angett retryTimeout rätt. Värdet retryTimeoutInMilliseconds ska vara högre än värdet operationTimeoutInMilliseconds. Annars görs inga återförsök.

I följande exempel retryTimeoutInMilliseconds anges till 3000.

<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"
>

TCP-inställningar för Linux-baserade klientprogram

Klientprogram som finns i Linux kan uppleva anslutningsproblem på grund av optimistiska TCP-inställningar i Linux. Mer information finns i TCP-inställningar för Linux-värdbaserade klientprogram.

Trafiköverbelastning och konfiguration av trådpool

Trafiktoppar i kombination med dåliga ThreadPool-inställningar kan leda till fördröjningar i bearbetningen av data som redan skickats av Redis-servern men som ännu inte förbrukats på klientsidan. Verifiera KPI:n Errors (Type: UnresponsiveClients) för att se om dina klientvärdar håller jämna steg med plötsliga trafiktoppar. Du kan konfigurera dina ThreadPool-inställningar för att säkerställa att trådpoolen skalas upp snabbt under burst-scenarier.

Du kan använda timeoutException meddelanden från StackExchange.Redis för att undersöka ytterligare.

    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)

Föregående undantag visar flera problem.

  • I avsnittet IOCP och avsnittet WORKERBusy är värdet större än Min värdet, vilket innebär att ThreadPool inställningarna behöver justeras.
  • Värdet in: 64221 anger att 64 221 byte togs emot på klientens kernel socket-lager men inte lästes 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.

StackExchange.Redis 1.1.603 och senare inkluderar mätvärdet local-cpu i felmeddelanden timeoutException. Se till att använda den senaste versionen av NuGet-paketet StackExchange.Redis eftersom buggar regelbundet åtgärdas för att göra koden mer resistent mot tidsgränser. Mer information finns i Undersöka tidsgränsundantag i StackExchange.Redis.

Felsöka problem på serversidan

Följande problem på serversidan kan påverka prestanda och leda till tidsgränser.

Hög minnesanvändning

Minnesbelastning på servern kan leda till olika prestandaproblem som fördröjer bearbetningen av begäranden. När minnesbelastning uppstår, flyttar systemet data till disk, vilket gör att systemet fördröjs avsevärt.

Några möjliga orsaker till minnesbelastning är att cachen är fylld med data till nära sin maximala kapacitet, eller att Redis-servern har hög minnesfragmentering.

Fragmentering är sannolikt när ett belastningsmönster lagrar data med stor variation, till exempel när data sprids över storlekar på 1 KB och 1 MB. När en 1 KB-nyckel tas bort från befintligt minne kan en 1 MB-nyckel inte passa in i utrymmet, vilket orsakar fragmentering. Om en nyckel på 1 MB tas bort kan en tillagd 1,5 MB-nyckel inte passa in i det befintliga återvunna minnet. Det här oanvända lediga minnet resulterar i fragmentering.

Om en cache är fragmenterad och körs under högt minnestryck gör systemet en redundansväxling för att försöka återställa RSS-minnet (Resident Set Size). Redis exponerar två statistik, used_memory och used_memory_rss, via INFO-kommandot , som kan hjälpa dig att identifiera det här problemet. Du kan också visa dessa mått i Azure-portalen.

Om värdet used_memory_rss är högre än 1,5 gånger måttet used_memory finns det fragmentering i minnet. Fragmenteringen kan orsaka problem när:

  • Minnesanvändningen ligger nära den maximala minnesgränsen för cacheminnet.
  • Måttet used_memory_rss är högre än den maximala minnesgränsen, vilket kan leda till sidfel i minnet.

Du kan vidta flera åtgärder för att hålla minnesanvändningen felfri.

Fler rekommendationer om minneshantering finns i Metodtips för minneshantering.

Hög serverbelastning

Hög serverbelastning innebär att Redis-servern är upptagen och inte kan hålla jämna steg med begäranden, vilket leder till tidsgränser eller långsamma svar. För att minska hög serverbelastning undersöker du först orsaken, till exempel tidskrävande kommandon på grund av högt minnestryck.

Du kan övervaka metrik som serverbelastning från Azure-portalen. Om du vill kontrollera måttet Serverinläsning väljer du Insikter under Övervakning i den vänstra navigeringsmenyn på cachesidan och visar diagrammet Serverinläsning . Eller välj Mått under Övervakning i den vänstra navigeringsmenyn och välj sedan Serverbelastning under Mått.

Håll utkik efter toppar i serverbelastningsanvändningen som motsvarar tidsgränser. Skapa aviseringar för serverlastmetrik för att få tidiga varningar om potentiella effekter.

Spikar i serverbelastning

På C0- och C1-cacheminnen kan du se korta toppar i serverbelastningen som inte orsakas av en ökning av begäranden, medan intern Defender-genomsökning körs på de virtuella datorerna. På dessa nivåer ser du högre svarstid för begäranden medan interna Defender-genomsökningar sker.

Cacheminnen på C0- och C1-nivåerna har bara en enda kärna för multitasking, vilket innebär att uppgiften att hantera interna Defender-genomsökningar och Redis-begäranden delas upp. Om extra svarstid från interna Defender-genomsökningar påverkar produktionsarbetsbelastningen negativt på en C1-cache kan du skala till ett erbjudande på högre nivå med flera PROCESSORkärnor, till exempel C2. Mer information finns i Välja rätt nivå.

Mer information om snabba ändringar i antalet klientanslutningar finns i Undvik klientanslutningstoppar.

Skalning

Du kan skala ut till fler shards för att distribuera belastningen över flera Redis-processer eller skala upp till en större cachestorlek med fler CPU-kärnor. Skalningsåtgärder är processor- och minnesintensiva eftersom de kan innebära att data flyttas runt noder och att klustertopologin ändras. Mer information finns i Vanliga frågor och svar om planering av Azure Cache for Redis och skalning.

Långvariga kommandon

Vissa Redis-kommandon är mer kostsamma att köra än andra. Dokumentationen om Redis-kommandon visar tidskomplexiteten för varje kommando. Redis-kommandobearbetning är entrådad. Alla kommandon som tar lång tid att köra kan blockera andra som följer det.

Granska de kommandon som du utfärdar till Redis-servern för att förstå deras prestandapåverkan. Till exempel används kommandot KEYS ofta utan vetskap om att det är en O(N)-åtgärd (Big O Notation). Om du vill minska CPU-toppar kan du undvika KEYS genom att använda SCAN.

Du kan köra följande Redis-kommandon i en konsol för att undersöka tidskrävande och dyra kommandon.

  • KLIENTLISTA

    Kommandot CLIENT LIST returnerar information och statistik om klientanslutningsservern i ett mestadels mänskligt läsbart format.

  • INFORMATION

    Kommandot INFO returnerar information och statistik om servern i ett format som är enkelt för datorer att parsa och enkelt för människor att läsa. Avsnittet CPU kan vara användbart för att undersöka CPU-användning. Ett server_load av 100 (maximalt värde) betyder att Redis-servern var upptagen hela tiden och aldrig var inaktiv när begärandena bearbetades.

    I följande exempel visas utdata från INFO kommandot:

    # 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

  • MONITOR

    MONITOR är ett felsökningskommando som strömmar tillbaka varje kommando som bearbetas av Redis-servern. MONITOR kan hjälpa dig att förstå vad som händer med databasen. Det här kommandot är krävande och kan påverka och försämra prestanda negativt.

  • SLOWLOG

    Redis Slow Log är en funktion för att logga frågor som överskridit en angiven körtid. Körningstiden omfattar inte I/O-åtgärder som att prata med klienten eller skicka svaret, utan bara den tid som krävs för att faktiskt köra kommandot.

    Kommandot SLOWLOG läser och återställer loggen för långsamma Redis-frågor och kan även användas för att undersöka tidskrävande kommandon på klientsidan. Du kan övervaka och logga dyra kommandon som körs mot Redis-servern med hjälp av SLOWLOG GET.

Begränsning av nätverksbandbredd

Olika cachestorlekar har olika kapacitet för nätverksbandbredd. Om servern överskrider den tillgängliga bandbredden skickas inte data till klienten lika snabbt. Klientbegäranden kan gå ut på grund av att servern inte kan leverera data till klienten tillräckligt snabbt.

Du kan övervaka mått som cacheläsning och cacheskrivning i Azure-portalen för att se hur mycket bandbredd på serversidan som används. Skapa aviseringar för dessa mått för att meddelas tidigt om potentiella effekter.

Så här åtgärdar du situationer där användningen av nätverksbandbredd är nära maximal kapacitet:

  • Ändra beteendet för klientanrop för att minska nätverksefterfrågan.
  • Öka till en större cachestorlek med mer nätverksbandbreddskapacitet. Mer information finns i Vanliga frågor och svar om Azure Cache for Redis-planering.

Serverunderhåll

Planerat eller oplanerat underhåll kan orsaka avbrott i klientanslutningar. Antalet och typen av undantag beror på platsen för begäran i kodsökvägen och när cachen stänger sina anslutningar.

Om Din Azure Redis-cache genomgår en redundansväxling överförs alla klientanslutningar från noden som gick ned till den nod som fortfarande körs. Serverbelastningen kan öka på grund av de ökade anslutningarna. Du kan prova att starta om klientprogrammen så att alla klientanslutningar återskapas och distribueras om mellan de två noderna.

En operation som skickar en begäran men inte får något svar när failover (redundansväxling) inträffar kan få ett timeout undantag. Nya begäranden på det stängda anslutningsobjektet genererar anslutningsfel tills återanslutningen lyckas.

Kontrollera om din Azure Redis-cache hade en failover under tiden som dina timeout undantag inträffade genom att granska metrik Fel. På sidan i Azure-portalen för din cache väljer du Mått under Övervakning i den vänstra navigeringsmenyn. Skapa sedan ett nytt diagram som mäter måttet Fel , uppdelat efter ErrorType. När du har skapat det här diagrammet ser du ett antal för failöver. Mer information om redundans finns i Redundans och korrigering för Azure Cache for Redis.

Mer information om hur du åtgärdar problem på grund av serverunderhåll finns i följande artiklar:

Relaterat innehåll