Delen via

Het oplossen van problemen met latentie en time-outs bij Azure Cache voor Redis

  • Van toepassing op: ✅ Azure Cache for Redis

Een Azure Cache voor Redis-clientbewerking die geen tijdige reactie ontvangt, kan een hoge latentie of een time-outuitzondering veroorzaken. In dit artikel wordt uitgelegd hoe u veelvoorkomende problemen oplost die kunnen leiden tot hoge latentie en time-outs.

Een bewerking kan in verschillende stadia problemen ondervinden of een time-out krijgen. De bron van het probleem helpt bij het bepalen van de oorzaak en de beperking. Dit artikel is onderverdeeld in problemen aan de clientzijde en aan de serverzijde.

Problemen aan de clientzijde

Problemen aan de serverzijde

Probleemoplossing aan de clientzijde

De volgende problemen aan de clientzijde kunnen van invloed zijn op latentie en prestaties en leiden tot time-outs.

Hoge clientverbindingen

Clientaanvragen voor clientverbindingen die buiten het maximum voor de cache vallen, kunnen mislukken. Hoge clientverbindingen kunnen ook een hoge serverbelasting veroorzaken bij het verwerken van herhaalde pogingen om opnieuw verbinding te maken.

Hoge clientverbindingen kunnen duiden op een verbindingslek in clientcode. Verbindingen worden mogelijk niet opnieuw gebruikt of gesloten. Controleer de clientcode voor verbindingsgebruik.

Als de hoge verbindingen allemaal legitieme en vereiste clientverbindingen zijn, moet u mogelijk uw cache upgraden naar een grootte met een hogere verbindingslimiet. Controleer of de metrische waarde Max voor verbonden clients dicht bij of hoger ligt dan het maximum aantal toegestane verbindingen voor de cachegrootte. Zie Azure Cache voor Redis prestaties voor meer informatie over het aanpassen van de grootte per clientverbinding.

Hoog CPU-gebruik op clienthosts

Hoog CPU-gebruik van de client geeft aan dat het systeem niet kan bijhouden met het werk dat eraan is toegewezen. Zelfs als de cache het antwoord snel verzendt, kan de client het antwoord niet snel genoeg verwerken. Het is raadzaam om de CPU van de client op minder dan 80%te houden.

Het hoge CPU-gebruik van een client beperken:

  • Onderzoek de oorzaak van CPU-pieken.
  • Werk uw client bij naar een grotere VM-grootte (virtuele machine) met meer CPU-capaciteit.

Bewaak het systeembrede CPU-gebruik van de client met behulp van metrische gegevens die beschikbaar zijn in Azure Portal of via prestatiemeteritems op de virtuele machine. Controleer de metrische fouten (type: Niet reagerendeClients) om te bepalen of uw clienthosts reacties van de Redis-server op tijd kunnen verwerken.

Wees voorzichtig met het niet bewaken van proces-CPU, omdat één proces een laag CPU-gebruik kan hebben, maar de cpu voor het hele systeem hoog kan zijn. Let op pieken in CPU-gebruik die overeenkomen met time-outs. Een hoog CPU-gebruik kan ook leiden tot hoge in: XXX waarden in timeoutException foutberichten. Zie de sectie Traffic Burst en Thread Pool-configuratie voor een voorbeeld.

StackExchange.Redis 1.1.603 en hoger bevat het metrische gegeven local-cpu in timeoutException-foutberichten. Zorg ervoor dat u de nieuwste versie van het StackExchange.Redis NuGet-pakket gebruikt, omdat bugs regelmatig worden opgelost om de code beter bestand te maken tegen time-outs. Zie Uitzonderingen onderzoeken timeout in StackExchange.Redis voor meer informatie.

Grote sleutelwaarden

U kunt de redis-cli --bigkeys-opdracht gebruiken om te controleren op grote sleutels in uw cache. Zie Redis CLI voor meer informatie over redis-cli, de Redis-opdrachtregelinterface.

Om het probleem te verhelpen:

  • Vergroot de grootte van uw VIRTUELE machine om meer bandbreedtemogelijkheden te krijgen. Meer bandbreedte op uw client- of server-VM kan tot kortere gegevensoverdrachttijden bij grotere responsen leiden. Vergelijk uw huidige netwerkgebruik op beide VM's met de limieten van uw huidige VM-grootten. Meer bandbreedte op alleen de server of client is mogelijk niet voldoende.

  • Verhoog het aantal verbindingsobjecten dat door uw toepassing wordt gebruikt. Gebruik een round robin-benadering om aanvragen uit te voeren via verschillende verbindingsobjecten. Zie Meer sleutels en kleinere waarden gebruiken voor informatie over het gebruik van meerdere sleutels en kleinere waarden.

Geheugendruk op Redis-client

Geheugenbelasting op de client kan leiden tot prestatieproblemen die de verwerking van cachereacties vertragen. Wanneer geheugendruk optreedt, kan het systeem gegevens naar de schijf wegschrijven. Deze paginafout zorgt ervoor dat het systeem aanzienlijk vertraagt.

Geheugenbelasting op de client detecteren:

  • Bewaak het geheugengebruik op de virtuele machine om ervoor te zorgen dat deze het beschikbare geheugen niet overschrijdt.
  • Bewaak de prestatiemeter van de client Page Faults/Sec. Tijdens de normale werking hebben de meeste systemen enkele paginafouten. Pieken in paginafouten die overeenkomen met time-outs van aanvragen kunnen duiden op geheugendruk.

Hoge geheugenbelasting op de client beperken:

  • Onderzoek uw geheugengebruikspatronen om het geheugenverbruik op de client te verminderen.
  • Upgrade uw client-VM naar een grotere grootte met meer geheugen.

Netwerkbandbreedtebeperking op client-hosts

Afhankelijk van hun architectuur kunnen clientcomputers beperkingen hebben voor de beschikbaarheid van netwerkbandbreedte. Als de client de beschikbare bandbreedte overschrijdt door de netwerkcapaciteit te overbelasten, worden gegevens niet zo snel verwerkt als de server deze verzendt. Deze situatie kan tot time-outs leiden.

U kunt dit beperken door het verbruik van de netwerkbandbreedte te verminderen of de VM-grootte van de client te vergroten naar een met meer netwerkcapaciteit. Zie Grote aanvraag- of antwoordgrootte voor meer informatie.

RedisSessionStateProvider opnieuw proberen uitlooptijd

Als u RedisSessionStateProvider gebruikt, zorg er dan voor dat u retryTimeout correct instelt. De waarde retryTimeoutInMilliseconds moet hoger zijn dan de waarde operationTimeoutInMilliseconds. Anders vinden er geen nieuwe pogingen plaats.

In het volgende voorbeeld retryTimeoutInMilliseconds is ingesteld op 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-instellingen voor op Linux gebaseerde clienttoepassingen

Clienttoepassingen die worden gehost op Linux kunnen connectiviteitsproblemen ondervinden vanwege optimistische TCP-instellingen in Linux. Zie TCP-instellingen voor door Linux gehoste clienttoepassingen voor meer informatie.

Verkeerspiek en configuratie van threadpool

Pieken in het verkeer in combinatie met slechte ThreadPool-instellingen kunnen leiden tot vertragingen bij het verwerken van data die al door de Redis-server is verzonden, maar nog niet door de cliënt is verwerkt. Controleer de metriek (Type: Niet reagerende Clients) om te controleren of uw clienthosts plotselinge pieken in het dataverkeer kunnen bijhouden. U kunt de ThreadPool-instellingen configureren om ervoor te zorgen dat uw threadpool snel omhoog wordt geschaald onder burst-scenario's.

U kunt berichten van StackExchange.Redis gebruiken timeoutException om verder te onderzoeken.

    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)

De voorgaande uitzondering toont verschillende problemen.

  • In de IOCP sectie en de WORKER sectie is de Busy waarde groter dan de Min waarde, wat betekent dat de ThreadPool instellingen moeten worden aangepast.
  • De waarde in: 64221 geeft aan dat er 64.221 bytes zijn ontvangen op de kernelsocketlaag van de client, maar niet is gelezen door de toepassing. Dit verschil betekent meestal dat uw toepassing, bijvoorbeeld StackExchange.Redis, geen gegevens leest uit het netwerk zo snel als de server deze verzendt.

StackExchange.Redis 1.1.603 en hoger bevat het metrische gegeven local-cpu in timeoutException-foutberichten. Zorg ervoor dat u de nieuwste versie van het StackExchange.Redis NuGet-pakket gebruikt, omdat bugs regelmatig worden opgelost om de code beter bestand te maken tegen time-outs. Zie Onderzoeken van time-outuitzonderingen in StackExchange.Redis voor meer informatie.

Probleemoplossing aan de serverzijde

De volgende problemen aan de serverzijde kunnen van invloed zijn op de prestaties en leiden tot time-outs.

Hoog geheugengebruik

Geheugenbelasting op de server kan leiden tot verschillende prestatieproblemen die de verwerking van aanvragen vertragen. Wanneer geheugenbelasting optreedt, worden de systeempaginagegevens naar de schijf weergegeven, waardoor het systeem aanzienlijk wordt vertraagd.

Sommige mogelijke oorzaken van geheugenbelasting zijn dat de cache wordt gevuld met gegevens tot bijna de maximale capaciteit, of dat de Redis-server een hoge geheugenfragmentatie heeft.

Fragmentatie is waarschijnlijk wanneer een laadpatroon gegevens opslaat met een grote variatie, bijvoorbeeld wanneer gegevens worden verdeeld over 1 kB- en 1 MB-grootten. Wanneer een sleutel van 1 kB uit het bestaande geheugen wordt verwijderd, kan een sleutel van 1 MB niet in de ruimte passen, wat fragmentatie veroorzaakt. Als een sleutel van 1 MB wordt verwijderd, kan een toegevoegde sleutel van 1,5 MB niet in het bestaande vrijgemaakte geheugen passen. Dit ongebruikte vrije geheugen resulteert in fragmentatie.

Als een cache is gefragmenteerd en onder hoge geheugendruk wordt uitgevoerd, voert het systeem een failover uit om te proberen Resident Set Size (RSS)-geheugen te herstellen. Redis geeft twee statistieken weer, used_memory en used_memory_rssvia de opdracht INFO , waarmee u dit probleem kunt identificeren. U kunt deze metrische gegevens ook bekijken in Azure Portal.

Als de used_memory_rss waarde hoger is dan 1,5 keer de used_memory metrische waarde, is er fragmentatie in het geheugen. De fragmentatie kan problemen veroorzaken wanneer:

  • Geheugengebruik ligt dicht bij de maximale geheugenlimiet voor de cache.
  • De used_memory_rss metrische waarde is hoger dan de maximale geheugenlimiet, wat kan leiden tot paginafouten in het geheugen.

U kunt verschillende acties uitvoeren om het geheugengebruik gezond te houden.

Zie Best practices voor geheugenbeheer voor meer aanbevelingen voor geheugenbeheer.

Hoge serverbelasting

Hoge serverbelasting betekent dat de Redis-server bezet is en geen aanvragen kan bijhouden, wat leidt tot time-outs of trage reacties. Als u de belasting van een hoge server wilt beperken, onderzoekt u eerst de oorzaak, zoals langlopende opdrachten vanwege hoge geheugenbelasting.

U kunt metrische gegevens bewaken , zoals serverbelasting vanuit Azure Portal. Als u de metrische gegevens voor serverbelasting wilt controleren, selecteert u Inzichten onder Bewaking in het linkernavigatiemenu op uw cachepagina en bekijkt u de grafiek Server laden . Of selecteer Metrische gegevens onder Bewaking in het linkernavigatiemenu en selecteer vervolgens Serverbelasting onder Metrische gegevens.

Let op pieken in serverbelasting die samenvallen met time-outs. Waarschuwingen maken voor metrische gegevens over serverbelastingen om vroegtijdig op de hoogte te worden gesteld van mogelijke gevolgen.

Pieken in serverbelasting

In C0- en C1-caches ziet u mogelijk korte pieken in serverbelasting die niet worden veroorzaakt door een toename van aanvragen, terwijl interne Defender-scans op de VM's worden uitgevoerd. In deze lagen ziet u een hogere latentie voor aanvragen terwijl interne Defender-scans plaatsvinden.

Caches op de C0- en C1-lagen hebben slechts één kern om te multitasken, waardoor het werk wordt verdeeld om interne Defender-scans en Redis-verzoeken te verwerken. Als extra latentie door scans van Defender een negatieve invloed heeft op uw productiewerklast op een C1-cache, kunt u schalen naar een hogere aanbodontie met meerdere CPU-kernen, zoals C2. Zie De juiste laag kiezenvoor meer informatie.

Zie Pieken in clientverbindingen vermijden voor meer informatie over snelle wijzigingen in het aantal clientverbindingen.

Opschalen

U kunt uitschalen naar meer shards om de belasting over meerdere Redis-processen te verdelen of omhoog schalen naar een grotere cachegrootte met meer CPU-kernen. Schaalbewerkingen zijn CPU- en geheugenintensief, omdat ze gegevens kunnen verplaatsen rond knooppunten en het wijzigen van de clustertopologie. Zie de veelgestelde vragen over het plannen en schalen van Azure Cache voor Redis voor meer informatie.

Langlopende opdrachten

Sommige Redis-opdrachten vergen meer uitvoeringstijd dan andere. De documentatie over Redis Commands toont de tijdcomplexiteit van elke opdracht. Redis-opdrachtverwerking wordt uitgevoerd met één thread. Elke opdracht die lang duurt om uit te voeren, kan anderen blokkeren die deze volgen.

Bekijk de opdrachten die u aan uw Redis-server geeft om inzicht te hebben in de invloed van de prestaties. De opdracht SLEUTELS wordt bijvoorbeeld vaak gebruikt zonder de wetenschap dat het een Big O Notation-bewerking (O(N)is. Als u CPU-pieken wilt verminderen, kunt u voorkomen KEYS door SCAN te gebruiken.

U kunt de volgende Redis-opdrachten uitvoeren in een console om langdurige en dure opdrachten te onderzoeken.

  • CLIENTLIJST

    De CLIENT LIST opdracht retourneert informatie en statistieken over de server voor clientverbindingen, voornamelijk in een voor mensen leesbare indeling.

  • INFO

    De INFO opdracht retourneert informatie en statistieken over de server in een indeling die eenvoudig is voor computers om te parseren en gemakkelijk te lezen voor mensen. De CPU sectie kan nuttig zijn om het CPU-gebruik te onderzoeken. Een server_load van 100 (de maximumwaarde) geeft aan dat de Redis-server constant bezet was en nooit inactief was bij het verwerken van de verzoeken.

    In het volgende voorbeeld ziet u een uitvoer van de INFO opdracht:

    # 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 is een foutopsporingsopdracht waarmee elke opdracht die door de Redis-server wordt verwerkt, wordt teruggestreamd. MONITOR kan u helpen begrijpen wat er met de database gebeurt. Deze opdracht is veeleisend en kan de prestaties negatief beïnvloeden en verminderen.

  • SLOWLOG

    Het Redis Slow Log is een systeem voor het vastleggen van query's die een opgegeven uitvoeringstijd hebben overschreden. De uitvoeringstijd bevat geen I/O-bewerkingen, zoals praten met de client of het verzenden van het antwoord, maar alleen de tijd die nodig is om de opdracht daadwerkelijk uit te voeren.

    De SLOWLOG opdracht leest en stelt het logboek voor langzame Redis-query's opnieuw in en kan ook worden gebruikt om langlopende opdrachten aan de clientzijde te onderzoeken. U kunt dure opdrachten bewaken en registreren die worden uitgevoerd op de Redis-server met behulp van SLOWLOG GET.

Beperkingen van netwerkbandbreedte

Verschillende cachegrootten hebben een verschillende netwerkbandbreedtecapaciteit. Als de server de beschikbare bandbreedte overschrijdt, worden gegevens niet zo snel naar de client verzonden. Bij clientaanvragen kan een time-out optreden omdat de gegevens niet snel genoeg van de server naar de client kunnen worden gepusht.

U kunt metrische gegevens bewaken , zoals Lezen en Schrijven in cache in Azure Portal om te zien hoeveel bandbreedte aan de serverzijde wordt gebruikt. Maak waarschuwingen voor deze metrische gegevens om vroegtijdig op de hoogte te worden gesteld van mogelijke gevolgen.

Om situaties te beperken waarin het netwerkbandbreedtegebruik de maximale capaciteit benadert:

Serveronderhoud

Gepland of ongepland onderhoud kan onderbrekingen met clientverbindingen veroorzaken. Het aantal en het type uitzonderingen zijn afhankelijk van de locatie van de aanvraag in het codepad en wanneer de cache de verbindingen sluit.

Als uw Azure Redis-cache een failover ondergaat, worden alle clientverbindingen van het knooppunt dat is uitgevallen, overgedragen naar het knooppunt dat nog steeds in werking is. De serverbelasting kan pieken vanwege de toegenomen verbindingen. U kunt proberen uw clienttoepassingen opnieuw op te starten, zodat alle clientverbindingen opnieuw worden gemaakt en opnieuw worden gedistribueerd tussen de twee knooppunten.

Een bewerking die een aanvraag verzendt, maar geen antwoord ontvangt wanneer de failover optreedt, kan een timeout uitzondering krijgen. Nieuwe aanvragen voor het gesloten verbindingsobject ontvangen verbindingsuitzonderingen totdat de nieuwe verbinding tot stand is gebracht.

Als u wilt controleren of uw Azure Redis-cache een failover heeft gehad tijdens het moment dat uw timeout uitzonderingen zijn opgetreden, controleert u de metrische gegevens over fouten . Selecteer op de azure-portalpagina voor uw cache metrische gegevens onder Bewaking in het linkernavigatiemenu. Maak vervolgens een nieuw diagram met de metrische gegevens Fouten , gesplitst op ErrorType. Zodra u deze grafiek hebt gemaakt, ziet u een telling voor Failover. Voor meer informatie over failovers, zie Failover en patching voor Azure Cache voor Redis.

Zie de volgende artikelen voor meer informatie over het beperken van problemen vanwege serveronderhoud:

Gerelateerde inhoud