Partager via

Résoudre les problèmes liés aux délais d’expiration et à la latence dans Azure Cache pour Redis

  • S’applique à: ✅ Azure Cache for Redis

Important

Azure Cache pour Redis a annoncé sa chronologie de mise hors service pour toutes les références SKU. Nous vous recommandons de déplacer vos instances Azure Cache pour Redis existantes vers Azure Managed Redis dès que vous le pouvez.

Pour plus d’informations sur la mise hors service :

Une opération de client Azure Cache pour Redis qui ne reçoit pas de réponse en temps opportun peut entraîner une latence élevée ou une exception de délai d’expiration. Cet article explique comment résoudre les problèmes courants qui peuvent entraîner une latence élevée et des délais d’expiration.

Une opération peut rencontrer des problèmes ou expirer à différentes étapes. La source du problème permet de déterminer la cause et l’atténuation. Cet article est divisé en problèmes côté client et côté serveur.

Problèmes côté client

Problèmes côté serveur

Résolution des problèmes côté client

Les problèmes côté client suivants peuvent affecter la latence et les performances et entraîner des délais de réponse.

Nombre de connexions clientes élevé

Les demandes de clients pour les connexions clients au-delà de la limite maximale du cache peuvent échouer. Un nombre élevé de connexions clientes peut également entraîner une charge de serveur élevée lors du traitement de tentatives de reconnexion répétées.

Un nombre élevé de connexions clientes peut indiquer une fuite des connexions dans le code client. Les connexions ne sont peut-être pas réutilisées ou fermées correctement. Passez en revue le code client pour l'utilisation des connexions.

Si les connexions élevées sont toutes légitimes et requises, vous devrez peut-être mettre à niveau votre cache vers une taille avec une limite de connexion plus élevée. Vérifiez si la métrique Max aggregate for Connected Clients est proche ou supérieure au nombre maximal de connexions autorisées pour votre taille de cache. Pour plus d’informations sur le dimensionnement des connexions par client, consultez Performances d’Azure Cache pour Redis.

Utilisation élevée du processeur sur les hôtes clients

Une utilisation élevée du processeur client indique que le système ne peut pas suivre le travail qui lui est attribué. Même si le cache envoie la réponse rapidement, le client risque de ne pas traiter la réponse suffisamment rapidement. Il est préférable de conserver le processeur client à moins de 80%.

Pour remédier à une utilisation élevée du processeur d’un client :

  • Examinez la cause des pics de processeur.
  • Mettez à niveau votre client vers une machine virtuelle plus grande avec une capacité de CPU accrue.

Surveillez l’utilisation du processeur à l’échelle du système du client à l’aide de métriques disponibles dans le portail Azure ou via des compteurs de performances sur la machine virtuelle. Examinez la métrique Erreurs (Type: UnresponsiveClients) pour déterminer si les hôtes du client peuvent traiter les réponses du serveur Redis dans les temps.

Veillez à ne pas surveiller l’UC du processus, car un seul processus peut avoir une faible utilisation du processeur, mais l’UC à l’échelle du système peut être élevée. Recherchez les pics d’utilisation du processeur qui correspondent à des délais d’expiration. Un processeur élevé peut également entraîner des valeurs élevées in: XXX dans les timeoutException messages d’erreur. Pour obtenir un exemple, consultez la section Configuration du pool de threads et des rafales de trafic.

StackExchange.Redis 1.1.603 et versions ultérieures inclut la mesure local-cpu dans les messages d’erreur timeoutException. Veillez à utiliser la dernière version du package NuGet StackExchange.Redis, car les bogues sont régulièrement corrigés pour rendre le code plus résistant aux délais d’expiration. Pour plus d’informations, consultez Examen des timeout exceptions dans StackExchange.Redis.

Valeurs de grandes clés

Vous pouvez utiliser la commande redis-cli --bigkeys pour rechercher les clés volumineuses dans votre cache. Pour plus d’informations sur redis-cli, l’interface de ligne de commande Redis, consultez Redis CLI.

Pour atténuer le problème :

  • Augmentez la taille de votre machine virtuelle pour obtenir des fonctionnalités de bande passante plus élevées. Une bande passante plus élevée sur votre machine virtuelle cliente ou serveur peut réduire le temps de transfert des données pour les réponses de plus grande taille. Comparez l’utilisation actuelle de votre réseau sur les deux machines virtuelles aux limites de vos tailles de machine virtuelle actuelles. Plus de bande passante sur le serveur ou le client n’est peut-être pas suffisant.

  • Augmenter le nombre d’objets de connexion qu’utilise votre application Utilisez un tourniquet (round-robin) pour envoyer des requêtes vers différents objets de connexion. Pour plus d’informations sur l’utilisation de plusieurs clés et de valeurs plus petites, consultez Prendre en compte d’autres clés et des valeurs plus petites.

Pression de la mémoire sur le client Redis

La sollicitation de la mémoire sur le client peut entraîner des problèmes de performances qui retardent le traitement des réponses du cache. En cas de sollicitation de la mémoire, le système peut paginer les données sur le disque. Cette défaut de page provoque un ralentissement significatif du système.

Pour détecter une sollicitation de la mémoire sur le client :

  • Surveillez l’utilisation de la mémoire sur la machine virtuelle pour vous assurer qu’elle ne dépasse pas la mémoire disponible.
  • Supervisez le compteur de performances Page Faults/Sec du client. Lors d’un fonctionnement normal, la plupart des systèmes peuvent rencontrer des défauts de page. Les pics de défauts de page correspondant à des délais d’attente de requêtes peuvent indiquer une sollicitation de la mémoire.

Pour atténuer la forte sollicitation de la mémoire sur le client :

  • Examinez vos modèles d’utilisation de la mémoire pour réduire la consommation de mémoire sur le client.
  • Mettez à niveau votre machine virtuelle cliente pour bénéficier de davantage de mémoire.

Limitation de la bande passante réseau sur les hôtes du client

Selon leur architecture, les ordinateurs clients peuvent avoir des limitations sur la disponibilité de la bande passante réseau. Si le client dépasse la bande passante disponible en surchargeant la capacité réseau, les données ne sont pas traitées côté client aussi rapidement que le serveur l’envoie. Cette situation peut entraîner des délais d’expiration.

Réduisez l’utilisation de la bande passante réseau ou augmentez la taille de la machine virtuelle cliente pour bénéficier d’une plus grande capacité réseau. Pour plus d’informations, consultez Taille importante de la demande ou de la réponse.

RedisSessionStateProvider délai d'attente de nouvelle tentative

Si vous utilisez RedisSessionStateProvider, vérifiez que vous définissez correctement retryTimeout . La valeur retryTimeoutInMilliseconds doit être supérieure à la valeur operationTimeoutInMilliseconds. Dans le cas contraire, aucune nouvelle tentative ne se produit.

Dans l’exemple suivant, retryTimeoutInMilliseconds est défini sur 3000.

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

Paramètres TCP pour les applications clientes basées sur Linux

Les applications clientes hébergées sur Linux peuvent rencontrer des problèmes de connectivité en raison de paramètres TCP optimistes dans Linux. Pour plus d’informations, consultez les paramètres TCP pour les applications clientes hébergées sur Linux.

Configuration du pool de threads et des rafales de trafic

Les augmentations de trafic combinées à des paramètres ThreadPool insatisfaisants peuvent retarder le traitement des données déjà envoyées par le serveur Redis, mais pas encore consommées côté client. Vérifiez la métrique Erreurs (Type : UnresponsiveClients) pour vérifier si vos hôtes de votre client peuvent soutenir des pics soudains de trafic. Vous pouvez configurer vos paramètres ThreadPool pour vous assurer que votre pool de threads augmente rapidement dans les scénarios de rafale.

Pour investiguer plus avant, vous pouvez utiliser les messages timeoutException de StackExchange.Redis.

    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)

L’exception précédente illustre plusieurs problèmes.

  • Dans la IOCP section et la WORKER section, la Busy valeur est supérieure à la Min valeur, ce qui signifie que les ThreadPool paramètres doivent être ajustés.
  • La valeur in: 64221 indique que 64 221 octets ont été reçus au niveau de la couche de socket du noyau du client, mais pas lus par l’application. Cette différence signifie généralement que votre application, par exemple StackExchange.Redis, ne lit pas les données du réseau aussi rapidement que le serveur l’envoie.

StackExchange.Redis 1.1.603 et versions ultérieures inclut la mesure local-cpu dans les messages d’erreur timeoutException. Veillez à utiliser la dernière version du package NuGet StackExchange.Redis, car les bogues sont régulièrement corrigés pour rendre le code plus résistant aux délais d’expiration. Pour plus d’informations, consultez Examen des exceptions de délai d’expiration dans StackExchange.Redis.

Résolution des problèmes côté serveur

Les problèmes côté serveur suivants peuvent affecter les performances et entraîner des temps d'attente.

Utilisation élévée de la mémoire

La sollicitation de la mémoire sur le serveur peut entraîner différents problèmes de performances qui retardent le traitement des demandes. Quand il y a pression sur la mémoire, le système transfère les données sur le disque, ce qui ralentit considérablement le système.

Certaines causes possibles de la sollicitation de la mémoire sont que le cache est rempli de données à proximité de sa capacité maximale, ou que le serveur Redis a une fragmentation élevée de la mémoire.

La fragmentation est probablement lorsqu’un modèle de charge stocke des données avec une variation de taille élevée, par exemple lorsque les données sont réparties sur des tailles de 1 Ko et de 1 Mo. Lorsqu’une clé de 1 Ko est supprimée de la mémoire existante, une clé de 1 Mo ne peut pas s’adapter à l’espace, provoquant une fragmentation. De même, si une clé de 1 Mo est supprimée, une clé ajoutée de 1,5 Mo ne peut pas s’adapter à la mémoire récupérée existante. Cette mémoire libre inutilisée entraîne une fragmentation.

Si un cache est fragmenté et s’exécute sous une pression de mémoire élevée, le système effectue un basculement pour essayer de récupérer la mémoire RSS (Resident Set Size). Redis expose les deux statistiques used_memory et used_memory_rss via la commande INFO, ce qui peut vous aider à détecter le problème. Vous pouvez également afficher ces métriques dans le portail Azure.

Si la valeur used_memory_rss est supérieure à 1,5 fois la métrique used_memory, une fragmentation de la mémoire se produit. La fragmentation peut provoquer des problèmes dans les cas suivants :

  • L’utilisation de la mémoire est proche de la limite maximale de mémoire pour le cache.
  • La used_memory_rss métrique est supérieure à la limite maximale de mémoire, ce qui peut entraîner une panne de page en mémoire.

Vous pouvez effectuer plusieurs actions pour aider à maintenir l’utilisation de la mémoire saine.

Pour plus d’informations sur la gestion de la mémoire, consultez les meilleures pratiques pour la gestion de la mémoire.

Charge de serveur élevée

Une charge de serveur élevée signifie que le serveur Redis est occupé et ne peut pas suivre les requêtes, ce qui entraîne des délais d’expiration ou des réponses lentes. Pour atténuer la charge élevée du serveur, examinez d’abord la cause, par exemple les commandes de longue durée en raison d’une forte sollicitation de la mémoire.

Vous pouvez surveiller les métriques telles que la charge du serveur à partir du portail Azure. Pour vérifier la métrique de chargement du serveur , sélectionnez Insights sous Surveillance dans le menu de navigation de gauche de votre page de cache et affichez le graphique de chargement du serveur . Ou sélectionnez Métriques sous Surveillance dans le menu de navigation de gauche, puis sélectionnez Chargement du serveur sous Métriques.

Recherchez des pics d’utilisation de Charge du serveur qui correspondent à des délais d’expiration. Créez des alertes sur les métriques de chargement du serveur pour être avertie au début des impacts potentiels.

Pics de chargement du serveur

Sur les caches C0 et C1, vous pouvez voir de courts pics de charge du serveur non provoqués par une augmentation des demandes, tandis que l’analyse interne de Defender s’exécute sur les machines virtuelles. Sur ces niveaux, vous voyez une latence plus élevée pour les requêtes pendant que des analyses internes de Defender ont lieu.

Les caches sur les niveaux C0 et C1 ont un seul cœur capable de gérer plusieurs tâches, répartissant le traitement des analyses internes de Defender et les requêtes Redis. Si la latence supplémentaire des analyses Defender internes affecte négativement votre charge de travail de production sur un cache C1, vous pouvez effectuer une mise à l’échelle vers une offre de niveau supérieur avec plusieurs cœurs de processeur, tels que C2. Pour plus d’informations, consultez Choisir le niveau approprié.

Pour plus d’informations sur les changements rapides dans le nombre de connexions clientes, consultez Éviter les pics de connexion client.

Mise à l’échelle

Effectuez un scale-out vers plus de partitions pour répartir la charge sur plusieurs processus Redis ou effectuez un scale-up vers une plus grande taille de cache avec plus de cœurs de processeur. Les opérations de mise à l’échelle sont gourmandes en processeur et en mémoire, car elles peuvent impliquer le déplacement de données autour des nœuds et la modification de la topologie de cluster. Pour plus d’informations, consultez les FAQ de planification de Cache Azure pour Redis et mise à l’échelle.

Commandes durables

Certaines commandes Redis sont plus coûteuses à exécuter que d’autres. La documentation sur les commandes Redis montre la complexité temporelle de chaque commande. Le traitement des commandes Redis ne fait appel qu’à un seul thread. Toute commande qui prend beaucoup de temps pour s’exécuter peut bloquer d’autres personnes qui le suivent.

Passez en revue les commandes que vous émettez sur votre serveur Redis pour comprendre leurs impacts sur les performances. Par exemple, la commande KEYS est souvent utilisée sans savoir qu’il s’agit d’une opération de notation de big O (O(N).. Pour réduire les pics d'utilisation du processeur, vous pouvez éviter KEYS en passant par SCAN.

Vous pouvez exécuter les commandes Redis suivantes dans une console pour examiner les commandes durables et coûteuses.

  • LISTE DES CLIENTS

    La CLIENT LIST commande retourne des informations et des statistiques sur le serveur de connexions clientes dans un format principalement lisible par l’homme.

  • INFORMATION

    La INFO commande retourne des informations et des statistiques sur le serveur dans un format simple pour que les ordinateurs analysent et facilitent la lecture des humains. La CPU section peut être utile pour examiner l’utilisation du processeur. Une server_load valeur 100 (valeur maximale) signifie que le serveur Redis était occupé tout le temps et n’était jamais inactif lors du traitement des demandes.

    L’exemple suivant montre une sortie de la INFO commande :

    # 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

  • MONITEUR

    MONITOR est une commande de débogage qui diffuse chaque commande traitée par le serveur Redis. MONITOR peut vous aider à comprendre ce qui se passe dans la base de données. Cette commande est exigeante et peut affecter et dégrader les performances.

  • SLOWLOG

    Le journal des requêtes lentes Redis est un système de journalisation des requêtes qui ont dépassé une durée d’exécution spécifiée. Le temps d’exécution n’inclut pas d’opérations d’E/S telles que la communication avec le client ou l’envoi de la réponse, mais seulement le temps nécessaire pour exécuter réellement la commande.

    La SLOWLOG commande lit et réinitialise le journal des requêtes lentes Redis, et peut également être utilisée pour examiner les commandes de longue exécution côté client. Vous pouvez surveiller et journaliser les commandes coûteuses exécutées sur le serveur Redis à l’aide de SLOWLOG GET.

Limitations de la bande passante réseau

La capacité de la bande passante réseau varie selon la taille du cache. Si le serveur dépasse la bande passante disponible, les données ne sont pas envoyées au client aussi rapidement. Les demandes du client risquent d’expirer, car le serveur ne peut pas envoyer (push) les données au client assez rapidement.

Vous pouvez surveiller les métriques telles que la lecture du cache et l’écriture du cache dans le portail Azure pour voir la quantité de bande passante côté serveur utilisée. Créez des alertes sur ces métriques pour être avertie au début des impacts potentiels.

Pour réduire une utilisation de la bande passante réseau proche de la capacité maximale :

Maintenance des serveurs

Une maintenance planifiée ou non planifiée peut entraîner des interruptions des connexions clientes. Le nombre et le type d’exceptions dépendent de l’emplacement de la requête dans le chemin du code et du moment où le cache ferme ses connexions.

Si votre cache Redis Azure subit un basculement, toutes les connexions clientes depuis le nœud qui est tombé en panne sont transférées vers le nœud qui fonctionne toujours. La charge de serveur peut fortement augmenter en raison du nombre accru de connexions. Vous pouvez essayer de redémarrer vos applications clientes afin que toutes les connexions clientes soient recréées et réparties entre les deux nœuds.

Une opération qui envoie une requête, mais qui ne reçoit pas de réponse lorsque le basculement se produit peut obtenir une timeout exception. Les nouvelles requêtes sur l’objet de connexion fermé reçoivent des exceptions de connexion jusqu’à ce que la connexion soit rétablie.

Pour vérifier si votre cache Redis Azure a subi un basculement pendant le temps où vos timeout exceptions se sont produites, vérifiez la métrique Erreurs . Dans la page du portail Azure de votre cache, sélectionnez Métriques sous Surveillance dans le menu de navigation de gauche. Créez ensuite un graphique qui mesure la métrique Errors , fractionnée par ErrorType. Une fois que vous avez créé ce graphique, vous voyez un nombre de Basculements. Pour plus d’informations sur les basculements, consultez Basculement et mise à jour corrective pour Azure Cache pour Redis.

Pour plus d’informations sur l’atténuation des problèmes en raison de la maintenance du serveur, consultez les articles suivants :

Contenu connexe

  • Last updated on