Felsöka svarstider och överskridna tidsgränser för Azure Cache for Redis

Artikel
12/09/2023

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 tidsgränser som uppstår vid anslutning till Azure Cache for Redis.

Felsökning på klientsidan
Felsökning på serversidan

Kommentar

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

Felsökning 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 problem som är intressanta:

Observera att du i avsnittet IOCP och avsnittet WORKER har 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 också se in: 64221. Det här värdet 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 till dig.

Du kan konfigurera Inställningar ThreadPool för att se till att trådpoolen skalas upp snabbt under burst-scenarier.

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 redis-cli --bigkeys kommandot för att söka efter stora nycklar i cacheminnet. Mer information finns i redis-cli, Redis-kommandoradsgränssnittet - 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 VM-storlek. Mer bandbredd på bara servern eller bara på klienten kanske inte räcker.
Ö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 klient-CPU-användning indikerar att systemet inte kan hålla jämna problem med det arbete som tilldelats det. Även om cachen skickade svaret snabbt kan klienten misslyckas med att bearbeta svaret i tid. Vår rekommendation är att hålla klientens CPU 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 CPU-användning med hjälp av mått som är tillgängliga i Azure-portalen eller via prestandaräknare på datorn. 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 CPU-användningen som motsvarar timeouter. Hög CPU kan också orsaka höga in: XXX värden i TimeoutException felmeddelanden enligt beskrivningen i avsnittet [Trafiksprängning].

Kommentar

StackExchange.Redis 1.1.603 och senare innehåller måttet i TimeoutException felmeddelandenlocal-cpu. Se till att du använder den senaste versionen av NuGet-paketet StackExchange.Redis. Buggar åtgärdas regelbundet i koden för att göra den mer robust för timeouter. Det är viktigt att ha den senaste versionen.

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

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

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

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

Ö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).

Minska förbrukningen av nätverksbandbredd eller öka storleken på den virtuella klientdatorn till en med mer nätverkskapacitet för att minska förbrukningen av nätverksbandbredd. 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 RedisSessionStateProviderkontrollerar 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 retryTimeoutInMilliseconds anges till 3 000. Mer information finns i ASP.NET Sessionstillståndsprovider för Azure Cache for Redis och Använda konfigurationsparametrarna för Sessionstillståndsprovider och Utdatacacheprovider.

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

Felsökning på serversidan

Här är felsökning 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 redundansväxlingen inträffar kan få ett timeout-undantag. Nya begäranden om det stängda anslutningsobjektet tar emot anslutningsfel tills återanslutningen lyckas.

Mer information finns i följande andra avsnitt:

Uppdatera kanal- och schemauppdateringar
Anslutningsresiliens
AzureRedisEventsMeddelanden

Kontrollera om Azure Cache for Redis hade en redundansväxling när tidsgränsen inträffade genom att kontrollera måttfelen. På menyn Resurs i Azure-portalen väljer du Mått. Skapa sedan ett nytt diagram som mäter måttet Errors , uppdelat efter ErrorType. När du har skapat det här diagrammet ser du ett antal för redundans.

Mer information om redundans finns i Redundans och korrigering för Azure Cache for Redis.

Hög serverbelastning

Hög serverbelastning innebär att Redis-servern inte kan hålla jämna steg med begäranden, vilket leder till tidsgränser. Servern kan vara långsam att svara och kan inte hålla samma takt som förfrågningsfrekvensen.

Övervaka mått , till exempel serverbelastning. Håll utkik efter toppar i Server Load användningen som motsvarar tidsgränser. Skapa aviseringar om mått vid serverbelastning för att meddelas tidigt om potentiella effekter.

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

Undersök vad som orsakar hög serverbelastning, 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 distribuera belastningen över flera Redis-processer eller skala upp till en större cachestorlek med fler CPU-kärnor. Mer information finns i Vanliga frågor och svar om Azure Cache for Redis-planering.
Om din produktionsarbetsbelastning på en C1-cache påverkas negativt av extra svarstid från virusgenomsökning kan du minska effekten genom att betala för ett erbjudande på högre nivå med flera CPU-kärnor, till exempel C2.

Toppar i serverbelastning

På C0 - och C1-cacheminnen kan du se korta toppar i serverbelastningen som inte orsakas av en ökning av begäranden ett par gånger om dagen när virusgenomsökningen körs på de virtuella datorerna. Du ser högre svarstid för begäranden när virusgenomsökning sker på dessa nivåer. Cacheminnen på nivåerna C0 och C1 har bara en enda kärna till multitask, vilket delar upp arbetet med att hantera virusgenomsökning och Redis-begäranden.

Hög minnesanvändning

Det här avsnittet har flyttats. 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 tidskomplexiteten för varje kommando. Redis-kommandobearbetning är entrådad. Alla kommandon som tar lång tid att köra kan blockera alla andra som kommer efter 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 att veta att det är en O(N)-åtgärd. Du kan undvika NYCKLAR genom att använda GENOMSÖKNING för att minska CPU-toppar.

Med kommandot SLOWLOG GET kan du mäta dyra 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 logg 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 bara den tid som krävs för att faktiskt köra kommandot. Kunder kan mäta/logga dyra kommandon som körs mot deras Redis-server med hjälp av SLOWLOG kommandot .
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 prestanda negativt. Det kan försämra prestanda.
INFO – kommandot returnerar information och statistik om servern i ett format som är enkelt att parsa efter datorer och lättläst av människor. I det här fallet kan avsnittet CPU vara användbart för att undersöka CPU-användningen. En serverbelastning på 100 (högsta 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

KLIENTLISTA – returnerar information och statistik om klientanslutningsservern i ett mestadels mänskligt läsbart format.

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:

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

StackExchange.Redis-timeoutundantag

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