Delen via

Problemen met latentie en time-outs voor Azure Managed Redis (preview) 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 Managed Redis (preview).

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 Managed Redis en De configuratieparameters van Session State Provider (Sessiestatusprovider) en Output Cache Provider (Uitvoercacheprovider) gebruiken voor meer informatie.

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

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.

Zie Verbindingstolerantie voor meer informatie.

Hoog CPU-gebruik

Hoge CPU betekent dat de Redis-server bezet is en de aanvragen niet kan bijhouden, wat tot time-outs kan leiden. De server reageert mogelijk traag en kan de aanvraagsnelheden niet bijhouden.

Bewaak metrische gegevens, zoals CPU. Let op pieken in CPU-gebruik die overeenkomen met time-outs. Stel waarschuwingen in voor metrische gegevens over de CPU, zoals het gebruikte geheugen, zodat u tijdig een melding krijgt over mogelijke gevolgen.

Er zijn verschillende wijzigingen die u kunt aanbrengen om de hoge CPU-gebruik te beperken:

  • Onderzoek wat een hoge CPU veroorzaakt, zoals langlopende opdrachten, die in dit artikel worden vermeld vanwege hoge geheugendruk.
  • 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. Voor meer informatie raadpleegt u de veelgestelde vragen over Azure Managed Redis-architectuur.
  • Als uw productieworkload in een cache negatief wordt beïnvloed door extra latentie van sommige interne defender-scanuitvoeringen, kunt u het effect verminderen door de cache te migreren naar een geoptimaliseerde laag of te schalen naar een hoger aanbod met meer CPU-kernen.

Pieken in CPU

In B0-, B1-, B3- en B5-caches ziet u mogelijk korte pieken in CPU 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 deze lagen hebben slechts twee kernen voor multitasking, waardoor het werk van het verwerken van interne defenderscans en Redis-aanvragen wordt verdeeld.

Hoog geheugengebruik

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 CPU van 100 (maximumwaarde) geeft aan dat de Redis-server de hele tijd bezig 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:

  • Wijzig het gedrag van clientaanroepen om de netwerkvraag te verminderen.
  • Schaal naar een grotere cachegrootte met meer bandbreedtecapaciteit voor het netwerk. Zie Prestatietests met Azure Managed Redis voor meer informatie.

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