Partager via

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

  • Article

Une opération de client qui ne reçoit pas de réponse en temps utile peut entraîner une exception de latence élevée ou de délai d’expiration. Une opération peut expirer lors de différentes phases. L’origine du délai d’expiration vous aide à déterminer la cause et la correction.

Cette section traite de la résolution des problèmes liés à la latence et au délai d’expiration qui se produisent lors de la connexion à Azure Cache pour Redis.

Notes

Dans ce guide, plusieurs procédures de résolution de problèmes comprennent des instructions pour exécuter des commandes Redis et surveiller diverses mesures de performances. Pour plus d’informations et d’instructions, consultez les articles dans la section Informations supplémentaires .

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

Voici comment résoudre les problèmes côté client.

Configuration de l’augmentation de trafic et des pools de threads

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. Examinez la métrique « Erreurs » (type : UnresponsiveClients) pour vérifier si les hôtes du client peuvent suivre un pic soudain du trafic.

Supervisez la façon dont évoluent vos statistiques ThreadPool au fil du temps à l’aide d’un exemple ThreadPoolLogger. 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)

Dans l’exception précédente, plusieurs problèmes sont intéressants :

  • Notez que dans les sections IOCP et WORKER, la valeur de Busy est supérieure à la valeur de Min. Cette différence signifie que vos paramètres ThreadPool ont besoin d’être ajustés.
  • Vous pouvez également voir in: 64221. Cette valeur indique que 64 221 octets ont été reçus au niveau de la couche de socket du noyau du client, mais qu’ils n’ont pas été lus par l’application. En général, cette différence signifie que votre application (par exemple, StackExchange.Redis) ne lit pas les données du réseau aussi rapidement que le serveur les lui envoie.

Vous pouvez configurer vos paramètres ThreadPool pour que votre pool de threads puisse rapidement faire l’objet d’un scale-up en cas d’augmentation du trafic.

Valeur de clé importante

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.

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

  • Augmenter la taille de votre machine virtuelle pour obtenir des capacité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 du réseau par les deux ordinateurs aux limites associées à la taille de votre machine virtuelle. Une bande passante plus élevée seulement sur le serveur ou sur le client peut ne pas suffire.
  • Augmenter le nombre d’objets de connexion qu’utilise votre application
    • Utilisez un tourniquet (round-robin) pour envoyer des demandes vers différents objets de connexion

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

Une utilisation élevée du processeur du client indique que le système n’arrive pas à faire face au travail qui lui est assigné. Même si le cache a envoyé la réponse rapidement, le client peut échouer à traiter la réponse en temps voulu. Nous vous recommandons de maintenir une utilisation du processeur du client inférieure à 80 %. 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.

Supervisez l’utilisation du processeur du client à l’échelle du système à l’aide des métriques qui sont disponibles dans le portail Azure ou via les compteurs de performances de l’ordinateur. Ne tenez pas compte du processeur de processus, car le processeur peut très bien être faiblement utilisé par un processus tout en étant fortement sollicité à l’échelle du système. Regardez les pics d’utilisation du processeur qui correspondent à des délais d’expiration. Quand le processeur est très utilisé, vous pouvez également voir s’afficher des valeurs in: XXX élevées dans les messages d’erreur TimeoutException, comme décrit dans la section [Augmentation de trafic].

Remarque

StackExchange.Redis 1.1.603 et versions ultérieures inclut la mesure local-cpu dans les messages d’erreur TimeoutException. Vérifiez que vous utilisez la dernière version en date du package NuGet StackExchange.Redis. Nous corrigeons en permanence le code pour le rendre plus robuste aux délais d’expiration. Il est donc primordial d’utiliser la dernière version.

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

  • Recherchez la cause des pics d’utilisation du processeur.
  • Mettez à niveau votre machine virtuelle cliente pour bénéficier d’une plus grande capacité de processeur.

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

Selon l’architecture des machines clientes, elles peuvent avoir des limitations quant à la bande passante réseau disponible. Si le client dépasse la bande passante disponible en surchargeant la capacité du réseau, les données ne sont pas traitées côté client aussi rapidement que le serveur les envoie. Cette situation peut entraîner des délais d’attente.

Supervisez la façon dont votre utilisation de la bande passante évolue au fil du temps, à l’aide d’un exemple BandwidthLogger. Ce code peut ne pas s’exécuter correctement dans certains environnements avec des autorisations restreintes (comme des sites web Azure).

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.

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

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

Délai d’expiration de la nouvelle tentative RedisSessionStateProvider

Si vous utilisez RedisSessionStateProvider, vérifiez que vous avez configuré correctement le délai d’expiration de nouvelle tentative. 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 réglé sur 3000. Pour plus d’informations, consultez la page Fournisseur d’état de session ASP.NET pour cache Azure pour Redis et How to use the configuration parameters of Session State Provider and Output Cache Provider (Comment utiliser les paramètres de configuration du fournisseur d’état de session et du fournisseur de caches de sortie).

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

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

Voici comment résoudre les problèmes côté serveur.

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 demande dans le chemin du code, et du moment où le cache ferme ses connexions. Par exemple, une opération qui envoie une requête mais qui ne reçoit pas de réponse quand le basculement se produit peut recevoir une exception de dépassement du délai d’expiration. 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 plus d’informations, consultez les sections suivantes :

Pour vérifier si Azure Cache pour Redis a subi un basculement quand les délais d’expiration se sont produits, examinez la métrique Erreurs. Dans le menu Ressources du portail Azure, sélectionnez Métriques. Créez ensuite un graphique mesurant la métrique Errors, fractionnée par ErrorType. Une fois que vous avez créé ce graphique, vous voyez un nombre pour Basculement.

Pour plus d’informations sur les basculements, consultez Basculement et mise à jour corrective pour Azure Cache pour Redis.

Charge de serveur élevée

Une charge de serveur élevée signifie que le serveur Redis ne parvient pas à suivre les demandes, ce qui entraîne des délais d’expiration. Le serveur peut être lent et ne pas être capable de répondre aux requêtes en temps voulu.

Supervisez les métriques comme la charge de serveur. Surveillez les pics d’utilisation de Server Load qui correspondent à des délais d’expiration. Créez des alertes relatives aux métriques sur la charge de serveur afin d’être averti le plus tôt possible des impacts potentiels.

Plusieurs modifications sont possibles pour réduire la charge serveur :

  • Recherchez la cause de la charge élevée du serveur, comme des commandes de longue durée mentionnées dans cet article, en raison d’une sollicitation élevée de la mémoire.
  • 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. Pour plus d’informations, consultez FAQ sur la planification d’Azure Cache pour Redis.
  • Si votre charge de travail de production sur un cache C1 est affectée négativement par une latence supplémentaire provenant des exécutions d’une analyse antivirus interne, vous pouvez réduire l’effet en mettant à l’échelle vers une offre de niveau supérieur avec plusieurs cœurs de processeur, comme C2.

Pics dans la charge du serveur

Sur les caches C0 et C1, il est possible que vous voyiez dans une journée de brefs pics de charge du serveur, qui ne sont pas provoqués par une augmentation des requêtes lors de l’exécution d’une analyse antivirus interne sur les machines virtuelles. Vous voyez une latence supérieure pour les requêtes pendant que des analyses antivirus internes se produisent sur ces niveaux. Les caches sur les niveaux C0 et C1 n’ont qu’un seul cœur pour le multitâche, divisant le travail pour servir l’analyse antivirus interne et les requêtes Redis.

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

Cette section a été déplacée. Pour plus d’informations, consultez Utilisation élevée de la mémoire.

Commandes de longue durée

Certaines commandes Redis sont plus coûteuses à exécuter que d’autres. La documentation concernant les commandes Redis montre la complexité temporelle de chaque commande. Le traitement des commandes Redis ne fait appel qu’à un seul thread. Toute commande dont l’exécution prend du temps peut bloquer toutes les autres qui suivent.

Passez en revue les commandes que vous émettez à votre serveur Redis pour comprendre leur impact sur le niveau de performance. Par exemple, les utilisateurs se servent souvent de la commande KEYS sans savoir qu’il s’agit d’une opération O(N). Vous pouvez éviter la commande KEYS en utilisant SCAN pour réduire les pics d’utilisation du processeur.

Grâce à la commande SLOWLOG GET, vous pouvez mesurer les commandes consommant beaucoup de ressources qui sont actuellement exécutées sur le serveur.

Les clients peuvent utiliser une console pour exécuter ces commandes Redis pour investiguer les commandes de longue durée et coûteuses.

  • SLOWLOG est utilisé pour lire et réinitialiser le journal des requêtes lentes Redis. Il peut être utilisé pour investiguer les commandes de longue durée côté client. 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. La durée d’exécution n’inclut pas les opérations d’E/S, comme la communication avec le client, l’envoi de la réponse, etc., mais seulement le temps nécessaire à l’exécution de la commande. Les clients peuvent mesurer/journaliser les commandes coûteuses en ressources exécutées sur leur serveur Redis en utilisant la commande SLOWLOG.
  • MONITOR est une commande de débogage qui retourne chaque commande traitée par le serveur Redis. Elle peut aider à comprendre ce qui se passe pour la base de données. Cette commande est exigeante et peut avoir un impact négatif sur les performances. Elle peut nuire aux performances.
  • La commande INFO retourne des informations et des statistiques sur le serveur dans un format qui est simple à analyser par les ordinateurs et facile à lire par les êtres humains. Dans ce cas, la section Processeur peut être utile pour investiguer l’utilisation du processeur. Une valeur de 100 pour la charge du serveur (la valeur maximale) signifie que le serveur Redis a été occupé à plein temps et n’a jamais été inactif lors du traitement des requêtes.

Exemple de sortie :

# 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 retourne des informations et des statistiques sur le serveur de connexions clientes dans un format en grande partie humainement lisible.

Limitation 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 vous servir des métriques « Lecture du cache » et « Écriture dans le cache » pour voir la quantité de bande passante qui est utilisée côté serveur. Vous pouvez afficher ces métriques dans le portail. Créez des alertes pour des métriques comme la lecture du cache ou l’écriture dans le cache, afin d’être averti le plus tôt possible des impacts potentiels.

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

Exceptions au délai d’expiration de StackExchange.Redis

Pour obtenir des informations plus spécifiques afin de traiter les délais d’expiration lors de l’utilisation de StackExchange.Redis, consultez Examen des exceptions de délai d’expiration dans StackExchange.Redis.

Contenu connexe