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

Bursts van 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 gebruikt. Controleer de metrische waarde Errors (type: UnresponsiveClients) om te controleren of uw clienthosts een plotselinge piek in het verkeer kunnen bijhouden.

Controleer hoe uw statistieken in de ThreadPool 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 IOCP sectie en de WORKER sectie een Busy waarde hebt die groter is dan de Min waarde. Dit verschil betekent dat uw ThreadPool instellingen moeten worden aangepast.
  • U kunt ook zien 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) geen gegevens leest uit het netwerk zo snel als de server deze naar u verzendt.

U kunt uw ThreadPool Instellingen configureren om ervoor te zorgen dat uw threadpool snel omhoog wordt geschaald onder 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 vermindert mogelijk de gegevensoverdrachttijden voor grotere antwoorden.
    • Vergelijk uw huidige netwerkgebruik op beide computers met de limieten van uw huidige VM-grootte. Meer bandbreedte op alleen de server of alleen op 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 van de client geeft aan dat het systeem niet kan bijhouden met het werk dat eraan is toegewezen. Hoewel de cache het antwoord snel heeft verzonden, kan de client het antwoord niet tijdig verwerken. Onze aanbeveling is om client-CPU minder dan 80% te houden. Controleer de metrische gegevens 'Fouten' (type: UnresponsiveClients) om te bepalen of uw clienthosts reacties 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 Azure Portal of via prestatiemeteritems op de computer. 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, zoals beschreven in de sectie [Verkeers burst].

Notitie

StackExchange.Redis 1.1.603 en hoger bevat de local-cpu metrische waarde in TimeoutException foutberichten. Zorg ervoor dat u de nieuwste versie van het NuGet-pakket StackExchange.Redis gebruikt. Bugs worden regelmatig opgelost in de code 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 wat cpu-pieken veroorzaakt.
  • Upgrade uw client naar een grotere VM-grootte met meer CPU-capaciteit.

Netwerkbandbreedtebeperking in clienthosts

Afhankelijk van de architectuur van clientcomputers hebben ze mogelijk beperkingen voor hoeveel netwerkbandbreedte ze beschikbaar hebben. 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 leiden tot time-outs.

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

Verminder het verbruik van de netwerkbandbreedte of verhoog de vm-grootte van de client naar een met meer netwerkcapaciteit. Zie Grote aanvraag- of antwoordgrootte voor meer informatie.

TCP-instellingen voor clienttoepassingen op basis van Linux

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

RedisSessionStateProvider: time-out voor opnieuw proberen

Als u de RedisSessionStateProvidertime-out voor opnieuw proberen gebruikt, moet u ervoor zorgen dat u de time-out voor opnieuw proberen correct instelt. De retryTimeoutInMilliseconds waarde moet hoger zijn dan de operationTimeoutInMilliseconds waarde. Anders treden er geen nieuwe pogingen op. In het volgende voorbeeld retryTimeoutInMilliseconds is ingesteld op 3000. Zie ASP.NET Sessiestatusprovider voor Azure Cache voor Redis en de configuratieparameters van Sessiestatusprovider en Uitvoercacheprovider gebruiken 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 verbindingsonderzondering 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.
  • Schaal uit naar meer shards om de belasting over meerdere Redis-processen te verdelen of omhoog te schalen 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 virusscans, kunt u het effect verminderen door te betalen voor 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 virusscans worden uitgevoerd op de VM's. U ziet een hogere latentie voor aanvragen terwijl virusscans plaatsvinden op deze lagen. Caches op de C0 - en C1-lagen hebben slechts één kern tot multitask, waardoor het werk van het verwerken van virusscans 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. De documentatie over Redis-opdrachten toont de tijdcomplexiteit van elke opdracht. Redis-opdrachtverwerking wordt uitgevoerd met één thread. Elke opdracht die lang duurt om uit te voeren, kan alle andere die erna komen blokkeren.

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

Met de OPDRACHT SLOWLOG GET kunt u dure opdrachten meten die worden uitgevoerd op de server.

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 verzenden van het antwoord, enzovoort, maar alleen de tijd die nodig is om de opdracht daadwerkelijk uit te voeren. Klanten kunnen dure opdrachten meten/registreren die worden uitgevoerd op hun Redis-server met behulp van de SLOWLOG opdracht.
  • MONITOR is een foutopsporingsopdracht waarmee elke opdracht die door de Redis-server wordt verwerkt, wordt teruggestreamd. Het kan helpen bij het begrijpen van 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.

Voorbeeld van uitvoer:

# 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 clientverbindingenserver in een voornamelijk leesbare indeling.

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

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 zich dicht bij de maximale capaciteit bevindt:

Time-outuitzondering stackExchange.Redis

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

Gerelateerde inhoud