Dela via

Felsöka svarstider och tidsgränser för Azure Managed Redis (förhandsversion)

  • Artikel

Klientåtgärder som inte får svar i tid kan resultera i långa svarstider eller timeout-undantag. En åtgärd kan överskrida tidsgränsen i olika skeden. Att ta reda på varifrån timeouten kommer hjälper till att fastställa orsaken och hitta en lösning.

I det här avsnittet beskrivs felsökning för problem med svarstid och timeout som uppstår vid anslutning till Azure Managed Redis (förhandsversion).

Kommentar

Flera av felsökningsstegen i denna guide innehåller anvisningar för att köra Redis-kommandon och övervaka olika prestandamått. Mer information och instruktioner finns i artiklarna i avsnittet Ytterligare information.

Felsöka problem på klientsidan

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

Trafiktoppar 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 måttet Fel (Typ: UnresponsiveClients) för att se om dina klientvärdar klarar att hantera en plötslig topp i trafiken.

Övervaka hur din ThreadPool statistik ändras över tid med hjälp av ett exempel ThreadPoolLogger. 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 dina ThreadPool-inställningar för att se till att trådpoolen skalar upp snabbt vid scenarier med toppar.

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 resursallokeringsmetod 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 tidsgränser. Hög processoranvändning kan också orsaka höga in: XXX värden i TimeoutException felmeddelanden enligt beskrivningen i avsnittet [Trafiktoppar] .

Kommentar

StackExchange.Redis 1.1.603 och senare innehåller local-cpu måttet TimeoutException felmeddelanden. Se till att du använder den senaste versionen av StackExchange.Redis NuGet-paketet. Buggar åtgärdas kontinuerligt i koden för att öka dess robusthet mot tidsgränser. Det är viktigt att ha den senaste versionen.

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 resultera i tidsgränser.

Övervaka hur bandbreddsanvändningen ändras över tid med hjälp av ett exempel BandwidthLogger. Den här koden kanske inte körs i vissa miljöer med begränsad behörighet (till exempel Azure-webbplatser).

För att åtgärda problemet, minska nätverksbandbreddens användning eller uppgradera den virtuella klientdatorn till en med större nätverkskapacitet. Mer information finns i Stor storlek på begäran 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. Mer information finns i ASP.NET sessionstillståndsprovider för Azure Managed Redis och Så här använder du konfigurationsparametrarna för sessionstillståndsprovider och utdatacacheprovider.

<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 redundansen 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.

Toppar i CPU

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 till flera uppgifter, vilket delar upp arbetet med att hantera intern Defender-skanning och Redis-begäranden.

Hög minnesanvändning

Mer information finns i Hög minnesanvändning.

Tidskrävande 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 frågor som överskridit en angiven körningstid. 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 överskrida tidsgränsen eftersom servern inte kan skicka 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:

StackExchange.Redis tidsgränsundantag

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