Delen via

Problemen met latentie en time-outs voor Azure Cache voor Redis oplossen

  • Artikel

Een clientbewerking die geen tijdige reactie ontvangt, kan leiden tot een hoge latentie of een time-outuitzondering. Een bewerking kan in verschillende fasen een time-out krijgen. De locatie van de time-out is nuttig bij het bepalen van de oorzaak en de beperking.

In deze sectie wordt beschreven hoe u problemen met latentie en time-outs kunt oplossen die optreden bij het maken van verbinding met Azure Cache voor Redis.

Notitie

Verschillende van de stappen voor probleemoplossing in deze handleiding bevatten instructies voor het uitvoeren van Redis-opdrachten en het bewaken van verschillende prestatiegegevens. Zie de artikelen in de sectie Aanvullende informatie voor meer informatie en instructies.

Probleemoplossing aan de clientzijde

Dit is de probleemoplossing aan de clientzijde.

Pieken in verkeer en configuratie van threadpool

Pieken in het verkeer in combinatie met slechte ThreadPool-instellingen kunnen leiden tot vertragingen bij het verwerken van gegevens die al zijn verzonden door de Redis-server, maar nog niet aan de clientzijde worden verbruikt. Controleer de metrische waarde Errors (type: UnresponsiveClients) om te controleren of uw clienthosts een plotselinge piek in het verkeer kunnen bijhouden.

Controleer hoe uw ThreadPool statistieken in de loop van de tijd veranderen met behulp van een voorbeeld ThreadPoolLogger. U kunt berichten van StackExchange.Redis gebruiken TimeoutException om het volgende 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)

In de voorgaande uitzondering zijn er verschillende problemen die interessant zijn:

  • U ziet dat u in de sectie IOCP en de sectie WORKER een waarde Busy hebt die groter is dan de waarde Min. Dit verschil betekent dat uw ThreadPool-instellingen moeten worden aangepast.
  • U kunt ook het volgende bekijken: in: 64221. Deze waarde geeft aan dat 64.221 bytes zijn ontvangen op de kernelsocketlaag van de client, maar niet zijn gelezen door de toepassing. Dit verschil betekent meestal dat uw toepassing (bijvoorbeeld StackExchange.Redis) de gegevens niet zo snel van het netwerk leest als de server ze naar u toestuurt.

U kunt uw ThreadPool-instellingen configureren om ervoor te zorgen dat uw threadpool snel omhoog wordt geschaald bij burst-scenario's.

Grote sleutelwaarde

Zie Meer sleutels en kleinere waarden gebruiken voor informatie over het gebruik van meerdere sleutels en kleinere waarden.

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

  • 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 computers met de limieten van uw huidige VM-grootte. Meer bandbreedte op alleen de server of alleen de client is mogelijk niet voldoende.
  • Verhoog het aantal verbindingsobjecten dat door uw toepassing wordt gebruikt.
    • Een round robin-benadering gebruiken om aanvragen te maken via verschillende verbindingsobjecten

Hoog CPU-gebruik op clienthosts

Hoog CPU-gebruik op clienthosts geeft aan dat het systeem het toegewezen werk niet kan bijbenen. Hoewel de cache het antwoord snel heeft verzonden, kan de client het antwoord mogelijk niet tijdig verwerken. Onze aanbeveling is om client-CPU op minder dan 80% te houden. Controleer het metrische gegeven 'Fouten' (type: UnresponsiveClients) om te bepalen of uw clienthosts responsen van de Redis-server op tijd kunnen verwerken.

Bewaak het systeembrede CPU-gebruik van de client met behulp van metrische gegevens die beschikbaar zijn in de Azure-portal of via prestatiemeteritems op de computer. Wees voorzichtig bij het bewaken van proces-CPU omdat een enkel proces een laag CPU-gebruik kan hebben, terwijl 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, zoals beschreven in de sectie [Pieken in verkeer].

Notitie

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. Regelmatig worden bugs in de code opgelost om deze robuuster te maken voor time-outs. Het is belangrijk om de nieuwste versie te hebben.

Het hoge CPU-gebruik van een client beperken:

  • Onderzoek de oorzaak van CPU-pieken.
  • Upgrade uw client naar een grotere VM-grootte met meer CPU-capaciteit.

Netwerkbandbreedtebeperking in clienthosts

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

Bewaak hoe uw bandbreedtegebruik in de loop van de tijd verandert met behulp van een voorbeeld BandwidthLogger. Deze code wordt mogelijk niet uitgevoerd in sommige omgevingen met beperkte machtigingen (zoals Azure-websites).

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.

TCP-instellingen voor op Linux gebaseerde clienttoepassingen

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

RedisSessionStateProvider: time-out voor opnieuw proberen

Als u gebruikmaakt van RedisSessionStateProvider, moet u ervoor zorgen dat u de time-out voor opnieuw proberen correct instelt. De waarde retryTimeoutInMilliseconds moet hoger zijn dan de waarde operationTimeoutInMilliseconds. Anders vinden er geen nieuwe pogingen plaats. In het volgende voorbeeld is retryTimeoutInMilliseconds ingesteld op 3000. Zie ASP.NET Session State Provider voor Azure Cache voor Redis en ASP.NET Output Cache Provider voor Azure Cache voor Redis voor meer informatie.

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

Probleemoplossing aan de serverzijde

Dit is de probleemoplossing aan de serverzijde.

Serveronderhoud

Gepland of ongepland onderhoud kan onderbrekingen met clientverbindingen veroorzaken. Het aantal en het type uitzonderingen is afhankelijk van de locatie van de aanvraag in het codepad en van het tijdstip waarop de cache de verbindingen sluit. Een bewerking die bijvoorbeeld een aanvraag verzendt, maar geen antwoord ontvangt wanneer de failover optreedt, kan een time-outuitzondering krijgen. Nieuwe aanvragen voor het gesloten verbindingsobject ontvangen verbindingsuitzonderingen totdat de nieuwe verbinding tot stand is gebracht.

Raadpleeg de volgende andere secties voor meer informatie:

Als u wilt controleren of uw Azure Cache voor Redis een failover had tijdens het optreden van time-outs, controleert u de metrische fouten. Selecteer Metrische gegevens in het menu Resource van Azure Portal. Maak vervolgens een nieuw diagram met het meten van de Errors metrische waarde, gesplitst op ErrorType. Zodra u deze grafiek hebt gemaakt, ziet u een telling voor Failover.

Zie Failover en patching voor Azure Cache voor Redis voor meer informatie over failovers.

Hoge serverbelasting

Hoge serverbelasting betekent dat de Redis-server de aanvragen niet kan bijhouden, wat leidt tot time-outs. De server reageert mogelijk traag en kan de aanvraagsnelheden niet bijhouden.

Metrische gegevens bewaken, zoals serverbelasting. Let op pieken in Server Load-gebruik die overeenkomen met time-outs. Waarschuwingen maken voor metrische gegevens bij serverbelasting om vroeg op de hoogte te worden gesteld van mogelijke gevolgen.

Er zijn verschillende wijzigingen die u kunt aanbrengen om de hoge serverbelasting te beperken:

  • Onderzoek wat een hoge serverbelasting veroorzaakt, zoals langlopende opdrachten, die in dit artikel worden vermeld vanwege hoge geheugenbelasting.
  • Breid uit naar meer gebieden om de belasting over meerdere Redis-processen te verdelen of schaal omhoog naar een grotere cachegrootte met meer CPU-kernen. Zie Azure Cache voor Redis veelgestelde vragen over planningen voor meer informatie.
  • Als uw productieworkload op een C1-cache negatief wordt beïnvloed door extra latentie van sommige interne defender-scanuitvoeringen, kunt u het effect verminderen door te schalen naar een hogere laag met meerdere CPU-kernen, zoals C2.

Pieken in serverbelasting

In C0 - en C1-caches ziet u mogelijk korte pieken in serverbelasting die niet worden veroorzaakt door een toename van aanvragen een paar keer per dag terwijl interne defenderscans worden uitgevoerd op de VM's. U ziet een hogere latentie voor aanvragen terwijl interne defenderscans plaatsvinden op deze lagen. Caches op de C0 - en C1-lagen hebben slechts één kern voor multitask, waarbij het werk van het verwerken van interne defenderscans en Redis-aanvragen wordt verdeeld.

Hoog geheugengebruik

Deze sectie is verplaatst. Zie Hoog geheugengebruik voor meer informatie.

Langlopende opdrachten

Sommige Redis-opdrachten vergen meer uitvoeringstijd dan andere. In de documentatie over Redis-opdrachten wordt de tijdcomplexiteit van elke opdracht weergegeven. Redis-opdrachtverwerking wordt uitgevoerd met één thread. Elke opdracht die lang duurt, kan alle andere opdrachten blokkeren die erna komen.

Bekijk de opdrachten die u aan uw Redis-server verstrekt om inzicht te hebben in de invloed van de prestaties. De opdracht KEYS wordt bijvoorbeeld vaak gebruikt zonder dat men weet dat het een O(N)-bewerking is. U kunt KEYS vermijden door SCAN te gebruiken om CPU-pieken te verminderen.

Met de opdracht SLOWLOG GET kunt u langdurige opdrachten meten die op de server worden uitgevoerd.

Klanten kunnen een console gebruiken om deze Redis-opdrachten uit te voeren om langdurige en dure opdrachten te onderzoeken.

  • SLOWLOG wordt gebruikt om het logboek met trage Redis-query's te lezen en opnieuw in te stellen. Het kan worden gebruikt om langlopende opdrachten aan clientzijde te onderzoeken. 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, het antwoord verzenden enzovoort, maar alleen de tijd die nodig is om de opdracht daadwerkelijk uit te voeren. Met de opdracht SLOWLOG kunnen klanten dure opdrachten meten/vastleggen die op hun Redis-server worden uitgevoerd.
  • MONITOR is een foutopsporingsopdracht waarmee elke opdracht die door de Redis-server wordt verwerkt, wordt teruggestreamd. Het kan helpen om te begrijpen wat er met de database gebeurt. Deze opdracht is veeleisend en kan een negatieve invloed hebben op de prestaties. De prestaties kunnen afnemen.
  • INFO - opdracht retourneert informatie en statistieken over de server in een indeling die eenvoudig te parseren is door computers en gemakkelijk te lezen door mensen. In dit geval kan de CPU-sectie nuttig zijn om het CPU-gebruik te onderzoeken. Een serverbelasting van 100 (maximumwaarde) geeft aan dat de Redis-server de hele tijd bezet was en nooit inactief was bij het verwerken van de aanvragen.

Uitvoervoorbeeld:

# 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: retourneert informatie en statistieken over de server voor clientverbindingen in een voornamelijk door mensen leesbare indeling.

Beperking van netwerkbandbreedte

Verschillende cachegrootten hebben een verschillende netwerkbandbreedtecapaciteit. Als de beschikbare bandbreedte voor de server wordt overschreden, worden gegevens minder 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.

De metrische gegevens Gelezen uit cache en Geschreven naar cache kunnen worden gebruikt om te zien hoeveel bandbreedte er op de server wordt gebruikt. U kunt deze metrische gegevens weergeven in de portal. Maak waarschuwingen voor metrische gegevens, zoals het lezen van de cache of schrijven naar de cache, zodat u tijdig een melding krijgt over mogelijke gevolgen.

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

Time-outuitzonderingen stackExchange.Redis

Zie Time-outuitzonderingen onderzoeken in StackExchange.Redis voor meer specifieke informatie over het oplossen van time-outs in StackExchange.Redis.

Gerelateerde inhoud