Problemen met Azure Cache voor Redis aan serverzijde oplossen
In deze sectie worden problemen besproken die zich voordoen als gevolg van een voorwaarde op een Azure Cache voor Redis of de virtuele machine(s) die deze hosten.
- Geheugenbelasting op de Redis-server
- Hoog CPU-gebruik of hoge serverbelasting
- Langlopende opdrachten
- Bandbreedtebeperking aan serverzijde
Notitie
Enkele van de stappen voor probleemoplossing in deze handleiding bevatten instructies voor het uitvoeren van Redis-opdrachten en het bewaken van verschillende prestatiemetrieken. Zie de artikelen in de sectie Aanvullende informatie voor meer informatie en instructies.
Geheugenbelasting op de Redis-server
Geheugendruk aan de serverzijde leidt tot allerlei soorten prestatieproblemen die de verwerking van aanvragen kunnen vertragen. Wanneer de geheugendruk toeslaat, kan het systeem gegevens naar de schijf pagina's. Deze paginafout zorgt ervoor dat het systeem aanzienlijk wordt vertraagd. Er zijn verschillende mogelijke oorzaken van deze geheugendruk:
- De cache is gevuld met gegevens die de maximale capaciteit naderen.
- Er is een hoge geheugenfragmentatie in Redis. Deze fragmentatie wordt meestal veroorzaakt door het opslaan van grote objecten, omdat Redis is geoptimaliseerd voor kleine objecten.
Redis geeft twee statistieken weer via de INFO-opdracht die u kan helpen bij het identificeren van dit probleem: 'used_memory' en 'used_memory_rss'. U kunt deze metrische gegevens weergeven via de portal.
Er zijn verschillende mogelijke wijzigingen die u kunt aanbrengen om het geheugengebruik in balans te houden:
- Configureer een geheugenbeleid en stel de verlooptijden voor uw sleutels in. Dit beleid is mogelijk niet voldoende als u te maken hebt met fragmentatie.
- Configureer een door maxmemory gereserveerde waarde die groot genoeg is om geheugenfragmentatie te compenseren.
- Splits uw grote objecten in de cache op in kleinere gerelateerde objecten.
- Maak waarschuwingen voor metrische gegevens, zoals het gebruikte geheugen, zodat u tijdig een melding krijgt over mogelijke gevolgen.
- Schaal naar een grotere cachegrootte met meer geheugencapaciteit.
- Schaal naar een grotere cachegrootte met meer geheugencapaciteit. Zie veelgestelde vragen over Azure Cache voor Redis planning voor meer informatie.
Hoog CPU-gebruik of hoge serverbelasting
Een hoge serverbelasting of een hoog CPU-gebruik betekent dat de server aanvragen niet tijdig kan verwerken. De server reageert mogelijk traag en kan de aanvraagsnelheden niet bij houden.
Metrische gegevens bewaken, zoals CPU- of serverbelasting. Kijk naar pieken in het CPU-gebruik die overeenkomen met time-outs.
Er zijn verschillende wijzigingen die u kunt aanbrengen om de hoge serverbelasting te beperken:
- Onderzoek wat de oorzaak is van CPU-pieken, zoals langlopende opdrachten die hieronder worden vermeld of paginafouten vanwege een hoge geheugendruk.
- Maak waarschuwingen voor metrische gegevens zoals CPU- of serverbelasting om vroegtijdig op de hoogte te worden gesteld van mogelijke gevolgen.
- Schaal uit naar meer shards om de belasting over meerdere Redis-processen te verdelen of schaal omhoog naar een grotere cachegrootte met meer CPU-kernen. Zie veelgestelde vragen over Azure Cache voor Redis planning voor meer informatie.
Langlopende opdrachten
Sommige Redis-opdrachten vergen meer uitvoeringstijd dan andere. In de documentatie voor Redis-opdrachten ziet u de tijdscomplexiteit van elke opdracht. Omdat de Redis-opdrachtverwerking uit één thread bestaat, blokkeert een opdracht waarvan de uitvoering tijd vergt, alle andere die erna komen. Bekijk de opdrachten die u aan uw Redis-server geeft om inzicht te krijgen 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 vermijden door SCAN te gebruiken om CPU-pieken te verminderen.
Met de opdracht SLOWLOG GET kunt u dure opdrachten meten die op de server worden uitgevoerd.
Bandbreedtebeperking aan serverzijde
Verschillende cachegrootten hebben een verschillende netwerkbandbreedtecapaciteit. Als de beschikbare bandbreedte voor de server wordt overschreden, worden gegevens minder snel naar de client verzonden. Aanvragen van clients kunnen een time-out hebben omdat de server gegevens niet snel genoeg naar de client kan pushen.
De metrische gegevens 'Cache lezen' en 'Schrijven in cache' kunnen worden gebruikt om te zien hoeveel bandbreedte aan de serverzijde wordt gebruikt. U kunt deze metrische gegevens weergeven in de portal.
Om situaties te beperken waarin het gebruik van netwerkbandbreedte dicht bij de maximale capaciteit ligt:
- Gedrag van clientoproepen wijzigen om de netwerkvraag te verminderen.
- 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.
- Schaal naar een grotere cachegrootte met meer netwerkbandbreedtecapaciteit. Zie veelgestelde vragen over Azure Cache voor Redis planning voor meer informatie.