Delen via

Problemen met latentie en time-outs van 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

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 Session State Provider voor Azure Managed Redis en how to use the configuration parameters of Session State Provider and Output Cache Provider (Sessiestatusprovider en Uitvoercacheprovider) 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 verbindingsonderzondering totdat de nieuwe verbinding tot stand is gebracht.

Zie Verbindingstolerantie voor meer informatie.

Hoog CPU-gebruik

Een hoog CPU-gebruik 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 , zoals CPU, bewaken. Let op pieken in CPU gebruik die overeenkomen met time-outs. Waarschuwingen maken voor metrische gegevens over CPU om vroegtijdig op de hoogte te worden gesteld van mogelijke gevolgen.

Er zijn verschillende wijzigingen die u kunt aanbrengen om een hoge CPU te beperken:

  • Onderzoek wat een hoge CPU veroorzaakt, zoals langlopende opdrachten, die in dit artikel worden vermeld vanwege hoge geheugendruk.
  • 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 de Azure Managed Redis-architectuur voor meer informatie.
  • 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 multitask, 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. 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 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.

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