Felsöka fördröjning och tidsavbrott i Azure Managed Redis

Klientåtgärder som inte får svar i tid kan resultera i långa svarstider eller timeout-undantag. En operation kan överskrida tidsgränsen i olika skeden. Att ta reda på varifrån timeouten kommer hjälper till att avgöra orsaken och åtgärda problemet.

I det här avsnittet beskrivs felsökning av problem med svarstider och tidsgränser som uppstår vid anslutning till Azure Managed Redis.

• Felsöka problem på klientsidan
  • Trafiktoppar och konfiguration av trådpool
  • Stort nyckelvärde
  • Hög processoranvändning på klientvärdar
  • Begränsning av nätverksbandbredd på klientvärdar
  • TCP-inställningar för Linux-baserade klientprogram
  • RedisSessionStateProvider – tidsgräns för återförsök
• Felsöka problem på serversidan
  • Serverunderhåll
  • Hög processoranvändning
  • Toppar i CPU
  • Hög minnesanvändning
  • Tidskrävande kommandon
  • Begränsning av nätverksbandbredd
  • Undantag för tidsgräns i StackExchange.Redis

Felsöka problem på klientsidan

Här är felsökning på klientsidan.

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. Kontrollera metrikken "Fel" (Typ: UnresponsiveClients) för att kontrollera om dina klientvärdar kan hantera en plötslig topp i trafiken.

Du kan använda TimeoutException meddelanden från StackExchange.Redis för att undersöka följande 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)

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

• Observera att i avsnittet IOCP och avsnittet WORKER finns ett Busy värde som är större än värdet Min . Den här skillnaden innebär att dina ThreadPool-inställningar behöver justeras.
• Du kan även se in: 64221. Det här värdet anger att 64 221 byte togs emot på klientens kernelsocketlager 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 till dig.

Du kan konfigurera din ThreadPool-inställning för att säkerställa att din trådpool skalar upp snabbt vid toppscenarier.

Stort nyckelvärde

Information om hur du använder flera nycklar och mindre värden finns i Överväg fler nycklar och mindre värden.

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

• Ö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 datorerna med gränserna för din aktuella storlek på virtuell dator. Högre bandbredd enbart på servern eller enbart på klienten kanske inte är tillräckligt.
• Öka antalet anslutningsobjekt som programmet använder.
  • Använd en rundgångsmetod för att göra begäranden över olika anslutningsobjekt

Hög processoranvändning på klientvärdar

Hög processoranvändning på klienten är ett tecken på att systemet inte hinner med tilldelat arbete. Även om cachen skickade svaret snabbt kan klienten misslyckas med att bearbeta svaret i rätt tid. Vår rekommendation är att hålla klientens processor mindre än 80 %. Kontrollera måttet "Fel" (typ: UnresponsiveClients) för att avgöra om klientvärdarna kan bearbeta svar från Redis-servern i tid.

Övervaka klientens systemomfattande processoranvändning med hjälp av mått som är tillgängliga i Azure-portalen eller via prestandaräknare på datorn. Var försiktig med att övervaka processoranvändningen för enskilda processer, eftersom en process kan ha låg processoranvändning medan den systemomfattande processoranvändningen är hög. Håll utkik efter toppar i processoranvändningen som motsvarar utgångstider. Hög processoranvändning kan också orsaka höga in: XXX värden i TimeoutException felmeddelanden enligt beskrivningen i avsnittet [Trafiktoppar] .

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

• Undersöka vad som orsakar processoranvändningstoppar.
• Uppgradera klienten till en större storlek på virtuell dator med mer processorkapacitet.

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

Beroende på klientdatorernas arkitektur kan de ha begränsningar för hur mycket nätverksbandbredd som är 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ä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.

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

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

RedisSessionStateProvider – tidsgräns för återförsök

Om du använder RedisSessionStateProvider kontrollerar du att tidsgränsen för återförsök är korrekt. Värdet retryTimeoutInMilliseconds ska vara högre än värdet operationTimeoutInMilliseconds. Annars görs inga återförsök. I följande exempel är retryTimeoutInMilliseconds inställd på 3 000. För mer information, se Hur man använder konfigurationsparametrarna för sessionstillståndsprovider och utdata-cacheprovider.

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

Felsöka problem på serversidan

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. En åtgärd som till exempel skickar en begäran men inte får något svar när en felövergång inträffar kan få ett tidsgränsundantag. Nya begäranden på det stängda anslutningsobjektet genererar anslutningsfel tills återanslutningen lyckas.

Mer information finns i Anslutningsresiliens.

Hög CPU

Hög CPU-användning innebär att Redis-servern inte hinner slutföra alla förfrågningar, vilket leder till tidsgräns. Servern kan vara långsam att svara och kan inte hålla samma takt som förfrågningsfrekvensen.

Övervaka mått som CPU. Håll utkik efter toppar i CPU processoranvändningen som motsvarar tidsgränser. Skapa aviseringar för olika mått på CPU så att du i god tid varnas om det finns risk för problem.

Det finns flera ändringar du kan göra för att minimera hög CPU:

• Undersök vad som orsakar hög CPU, till exempel tidskrävande kommandon som anges i den här artikeln, på grund av högt minnestryck.
• Skala ut till fler shards för att fördela belastningen över flera Redis-processer, eller skala upp till en större cachestorlek med fler CPU-kärnor. För ytterligare information, se Arkitektur för Azure Managed Redis.
• Om din produktionsarbetsbelastning på en cache påverkas negativt av extra svarstid från interna Defender-skanningar kan du minska effekten genom att migrera cachen till en beräkningsoptimerad nivå eller genom att skala upp till en högre plan med fler CPU-kärnor.

CPU-spikar

På cacheminnen B0, B1, B3 och B5 kan du uppleva korta toppar i CPU-användningen som inte orsakas av en ökning av begäranden, ett par gånger om dagen, när interna Defender-skanningar körs på de virtuella datorerna. Du ser högre svarstid för begäranden medan interna Defender-skanningar sker på dessa nivåer. Cacheminnen på dessa nivåer har bara två kärnor för multitasking, vilket delar upp arbetet med att hantera internätförsvarsskanning och Redis-begäranden.

Hög minnesanvändning

Mer information finns i Hög minnesanvändning.

Långvariga kommandon

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

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 kunskap om att det är en O(N)-åtgärd. Du kan undvika KEYS genom att använda kommandot SCAN för att minska CPU-toppar.

Med hjälp av kommandot SLOWLOG GET kan du mäta kostsamma kommandon som körs mot servern.

Kunder kan använda en konsol för att köra dessa Redis-kommandon för att undersöka tidskrävande och dyra kommandon.

• SLOWLOG används för att läsa och återställa Redis-loggen för långsamma frågor. Den kan användas för att undersöka tidskrävande kommandon på klientsidan. Redis Slow Log är ett system för att logga förfrågningar som överskridit en angiven körtid. Körningstiden omfattar inte I/O-åtgärder som att prata med klienten, skicka svaret och så vidare, utan endast den tid som krävs för att faktiskt köra kommandot. Kunder kan mäta och logga resurskrävande kommandon som körs mot deras Redis-server med hjälp av kommandot SLOWLOG.
• MONITOR är ett felsökningskommando som strömmar tillbaka varje kommando som bearbetas av Redis-servern. Det kan hjälpa dig att förstå vad som händer med databasen. Det här kommandot är krävande och kan påverka prestandan negativt. Det kan försämra prestandan.
• INFO – kommandot returnerar information och statistik om servern i ett format som är enkelt att parsa efter datorer och är lättläst av människor. I det här fallet kan CPU-avsnittet vara användbart för att undersöka processoranvändningen. En processor på 100 (maximalt värde) innebär att Redis-servern var upptagen hela tiden och aldrig var inaktiv när begärandena bearbetades.

Utdataexempel:

# 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

• CLIENT LIST – returnerar information och statistik om klientanslutningsservern i ett format som till största delen är lättläst för människor.

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 använda måtten Cacheläsning och Cacheskrivning för att se hur mycket bandbredd som används på serversidan. Du kan visa dessa mått i portalen. Skapa aviseringar för mått såsom cacheläsning och cacheskrivning så att du tidigt varnas om potentiella problem.

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 Prestandatestning med Azure Managed Redis.

StackExchange.Redis tidsbegränsningsundantag

Mer specifik information för att hantera timeouter när du använder StackExchange.Redis finns i Undersöka tidsgränsundantag i StackExchange.Redis.

Relaterat innehåll

• Felsöka problem på Azure Managed Redis-klientsidan
• Felsöka problem på Azure Managed Redis-serversidan
• Prestandatestning med Azure Managed Redis
• Övervaka Azure Managed Redis