Problemen met time-outs voor Azure Cache voor Redis oplossen

In deze sectie wordt het oplossen van time-outproblemen besproken die optreden bij het maken van verbinding met Azure Cache voor Redis.

• Redis-serverpatching
• Time-outuitzonderingen stackExchange.Redis

Redis-serverpatching

Azure Cache voor Redis worden de serversoftware regelmatig bijgewerkt als onderdeel van de beheerde-servicefunctionaliteit die het biedt. Deze patchactiviteit vindt grotendeels achter de schermen plaats. Tijdens de failovers wanneer Redis-serverknooppunten worden gepatcht, kunnen Redis-clients die zijn verbonden met deze knooppunten tijdelijke time-outs ervaren wanneer verbindingen tussen deze knooppunten worden geschakeld. Zie Hoe heeft een failover invloed op mijn clienttoepassing?voor meer informatie over de neveneffecten die patching kan hebben op uw toepassing en hoe u de verwerking van patchgebeurtenissen kunt verbeteren.

Time-outuitzonderingen stackExchange.Redis

StackExchange.Redis gebruikt een configuratie-instelling met de naam voor synchrone bewerkingen met een standaardwaarde synctimeout van 5000 ms. Als een synchrone aanroep niet binnen deze tijd wordt voltooid, wordt door de client StackExchange.Redis een time-outfout weergegeven die vergelijkbaar is met het volgende voorbeeld:

    System.TimeoutException: Timeout performing MGET 2728cc84-58ae-406b-8ec8-3f962419f641, inst: 1,mgr: Inactive, queue: 73, qu=6, qs=67, qc=0, wr=1/1, in=0/0 IOCP: (Busy=6, Free=999, Min=2,Max=1000), WORKER (Busy=7,Free=8184,Min=2,Max=8191)

Dit foutbericht bevat metrische gegevens die u kunnen helpen naar de oorzaak en mogelijke oplossing van het probleem te wijzen. De volgende tabel bevat details over de metrische gegevens van het foutbericht.

In het voorgaande uitzonderingsvoorbeeld bevatten de secties en elk een IOCP waarde die groter is dan de WORKER Busy Min waarde. Het verschil betekent dat u uw instellingen moet ThreadPool aanpassen. U kunt uw ThreadPool-instellingen configureren om ervoor te zorgen dat uw threadgroep snel omhoog wordt geschaald in burst-scenario's.

U kunt de volgende stappen gebruiken om mogelijke hoofdoorzaken te elimineren.

1. Zorg best practice dat u het ForceReconnect-patroon gebruikt om vastgelopen verbindingen te detecteren en te vervangen, zoals beschreven in het artikel Verbindings resilience.

   Zie Voor meer informatie over het gebruik van StackExchange.Redis Verbinding maken cache gebruiken met behulp van StackExchange.Redis.

2. Zorg ervoor dat uw server en de clienttoepassing zich in dezelfde regio in Azure hebben. U krijgt bijvoorbeeld time-outs wanneer uw cache zich in VS - oost belandt, maar de client zich in VS - west en de aanvraag niet binnen het interval voltooit of wanneer u een time-out krijgt bij het debuggen van uw lokale synctimeout ontwikkelmachine.

   Het wordt ten zeerste aanbevolen om de cache en in de client in dezelfde Azure-regio te hebben. Als u een scenario hebt met regio-overschrijdende aanroepen, moet u het interval instellen op een waarde die hoger is dan het standaardinterval van 5000 ms door een eigenschap op te synctimeout synctimeout connection string. In het volgende voorbeeld ziet u een fragment van een connection string voor StackExchange.Redis geleverd door Azure Cache voor Redis met een van synctimeout 8000 ms.

   synctimeout=8000,cachename.redis.cache.windows.net,abortConnect=false,ssl=true,password=...
   

3. Zorg ervoor dat u de nieuwste versie van het StackExchange.Redis NuGet-pakket gebruikt. Er worden voortdurend fouten in de code opgelost om de code robuuster te maken voor time-outs, dus het is belangrijk dat u over de nieuwste versie gaat.

4. Als uw aanvragen zijn gebonden aan bandbreedtebeperkingen op de server of client, duurt het langer om deze te voltooien en kan er time-outs worden veroorzaakt. Zie Bandbreedtebeperking aan serverzijde om te zien of uw time-outis vanwege de netwerkbandbreedte op de server. Zie Bandbreedtebeperking aan clientzijde om te zien of uw time-out wordt wegens bandbreedte van het clientnetwerk.

5. Krijgt u CPU-gebonden op de server of op de client?

   • Controleer of u gebonden bent aan de CPU op uw client. Hoge CPU kan ertoe leiden dat de aanvraag niet binnen het synctimeout interval wordt verwerkt en dat er een time-out voor een aanvraag wordt veroorzaakt. Het verplaatsen naar een grotere clientgrootte of het distribueren van de belasting kan helpen dit probleem te beheersen.
   • Controleer of u cpu-gebonden aan de server krijgt door de metrische gegevens van de CPU-cacheprestaties te controleren. Aanvragen die worden ontvangen terwijl Redis CPU-gebonden is, kunnen ertoe leiden dat er een time-out van deze aanvragen wordt veroorzaakt. Als u deze situatie wilt aanpakken, kunt u de belasting verdelen over meerdere shards in een Premium-cache of upgraden naar een grotere grootte of prijscategorie. Zie Bandbreedtebeperking aan serverzijde voor meer informatie.

6. Duurt het lang voordat opdrachten op de server zijn verwerkt? Langlopende opdrachten die lang duren om te verwerken op de redis-server kunnen time-outs veroorzaken. Zie Langlopende opdrachten voor meer informatie over langlopende opdrachten. U kunt verbinding maken met uw Azure Cache voor Redis met behulp van de redis-cli-client of de Redis-console. Voer vervolgens de opdracht SLOWLOG uit om te zien of er aanvragen langzamer zijn dan verwacht. Redis Server en StackExchange.Redis zijn geoptimaliseerd voor veel kleine aanvragen in plaats van minder grote aanvragen. Het opsplitsen van uw gegevens in kleinere segmenten kan hier de zaken verbeteren.

   Zie de blogpost Announcing ASP.NET Session State Provider for Redis Preview Release(Aankondiging van de preview-versie van ASP.NET Session State Provider voor Redis) voor meer informatie over het maken van verbinding met het TLS/SSL-eindpunt van uw cache met behulp van redis-cli en stunnel.

7. Een hoge belasting van de Redis-server kan time-outs veroorzaken. U kunt de belasting van de server bewaken door de metrische gegevens voor Redis Server Load cacheprestaties te bewaken. Een serverbelasting van 100 (maximale waarde) geeft aan dat de redis-server bezet is, zonder niet-actieve tijd, aanvragen te verwerken. Als u wilt zien of bepaalde aanvragen alle servermogelijkheden in gebruik nemen, moet u de opdracht SlowLog uitvoeren, zoals beschreven in de vorige alinea. Zie Hoog CPU-gebruik/serverbelasting voor meer informatie.

8. Is er een andere gebeurtenis aan de clientzijde die een netwerkverbinding kan hebben veroorzaakt? Veelvoorkomende gebeurtenissen zijn: het omhoog of omlaag schalen van het aantal client-exemplaren, het implementeren van een nieuwe versie van de client of automatisch schalen ingeschakeld. In onze tests hebben we geconstateerd dat automatisch schalen of omhoog/omlaag schalen ertoe kan leiden dat uitgaande netwerkconnectiviteit enkele seconden verloren gaat. StackExchange.Redis-code is bestand tegen dergelijke gebeurtenissen en maakt opnieuw verbinding. Tijdens het opnieuw verbinding maken kunnen er time-outs worden uitgevoerd voor alle aanvragen in de wachtrij.

9. Was er een grote aanvraag voorafgaand aan verschillende kleine aanvragen naar de cache die een time-out hebben gehad? De parameter in het foutbericht geeft aan hoeveel aanvragen van de client naar de server zijn verzonden, maar nog qs geen antwoord heeft verwerkt. Deze waarde kan blijven groeien omdat StackExchange.Redis gebruikmaakt van één TCP-verbinding en slechts één antwoord tegelijk kan lezen. Hoewel er een time-out is voor de eerste bewerking, worden er niet meer gegevens verzonden naar of van de server. Andere aanvragen worden geblokkeerd totdat de grote aanvraag is voltooid en er time-outs kunnen worden veroorzaakt. Eén oplossing is om de kans op time-outs te minimaliseren door ervoor te zorgen dat uw cache groot genoeg is voor uw workload en grote waarden te splitsen in kleinere segmenten. Een andere mogelijke oplossing is om een groep objecten in uw client te gebruiken en de minst geladen te kiezen bij ConnectionMultiplexer het verzenden van een nieuwe ConnectionMultiplexer aanvraag. Laden tussen meerdere verbindingsobjecten moet voorkomen dat een enkele time-out ervoor zorgt dat andere aanvragen ook een time-out veroorzaken.

10. Als u gebruikt, controleert u of u de time-out voor opnieuw proberen RedisSessionStateProvider correct hebt ingesteld. retryTimeoutInMilliseconds moet hoger zijn dan operationTimeoutInMilliseconds , anders worden er geen nieuwe proberen uitgevoerd. In het volgende voorbeeld retryTimeoutInMilliseconds is ingesteld op 3000. Zie voor meer informatie ASP.NET Session State Provider for Azure Cache voor Redis en How to use the configuration parameters of Session State Provider and Output Cache Provider (De configuratieparameters van Sessie state provider en Output Cache Provider gebruiken).

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

11. Controleer het geheugengebruik op Azure Cache voor Redis server door en te Used Memory RSS Used Memory controleren. Als er een uitzettingsbeleid is, begint Redis met het verwijderen van sleutels wanneer Used_Memory de cachegrootte wordt bereikt. In het Used Memory RSS ideale ideale ideale situatie is dit slechts iets hoger dan Used memory . Een groot verschil betekent dat er geheugenfragmentatie is (intern of extern). Wanneer kleiner is dan , betekent dit dat een deel van Used Memory RSS Used Memory het cachegeheugen is verwisseld door het besturingssysteem. Als deze wissel plaatsvindt, kunt u enkele aanzienlijke latentie verwachten. Omdat Redis geen controle heeft over hoe de toewijzingen worden toegewezen aan geheugenpagina's, is hoog vaak het resultaat van Used Memory RSS een piek in het geheugengebruik. Wanneer De Redis-server geheugen vrij maakt, neemt de allocator het geheugen, maar kan het geheugen al dan niet terug geven aan het systeem. Er kan een discrepantie zijn tussen de Used Memory waarde en het geheugenverbruik zoals gerapporteerd door het besturingssysteem. Het geheugen is mogelijk gebruikt en vrijgegeven door Redis, maar niet terug gegeven aan het systeem. Als u problemen met het geheugen wilt beperken, kunt u de volgende stappen volgen:

    • Upgrade de cache naar een grotere grootte, zodat u niet wordt uitgevoerd tegen geheugenbeperkingen op het systeem.
    • Stel de verlooptijden voor de sleutels in, zodat oudere waarden proactief worden weg gezet.
    • Controleer de used_memory_rss metrische gegevens van de cache. Wanneer deze waarde de grootte van de cache nadert, krijgt u waarschijnlijk prestatieproblemen te zien. Verdeel de gegevens over meerdere shards als u een Premium-cache gebruikt of upgrade naar een grotere cachegrootte.

    Zie Geheugendruk op Redis-server voor meer informatie.

Aanvullende informatie

• Problemen met Azure Cache voor Redis aan clientzijde oplossen
• Problemen met Azure Cache voor Redis aan serverzijde oplossen
• Hoe kan ik de prestaties van mijn cache benchmarken en testen?
• Azure Cache voor Redis bewaken