Tair (Redis® OSS-Compatible):Dépanner une utilisation élevée du CPU

Causes d'une utilisation élevée du CPU

• Commande gourmande en CPU : ces commandes, telles que KEYS, HGETALL, ou l'utilisation de MGET, MSET, HMSET et HMGET pour opérer sur de nombreuses clés simultanément, ont une complexité temporelle de O(N), où N est une valeur élevée. Les commandes ayant une complexité temporelle plus élevée consomment davantage de ressources CPU, ce qui entraîne une augmentation de l'utilisation du CPU.

  Les commandes s'exécutant sur un seul thread, leur exécution peut bloquer l'instance, mettre les autres requêtes en file d'attente et augmenter la latence de l'application. Dans les cas extrêmes, cela peut entraîner des délais d'expiration et provoquer un effet d'avalanche sur le cache, où le trafic contourne la couche de cache et atteint directement votre base de données backend.

  Remarque

  Pour plus d'informations sur la complexité temporelle de chaque commande, consultez Commands.

• Hotkey : lorsqu'un petit nombre de clés reçoit un nombre disproportionné de requêtes, elles deviennent des hotkeys. Une hotkey peut consommer d'importantes ressources CPU et augmenter la latence des autres opérations. Dans une architecture en cluster, si les hotkeys sont concentrées sur quelques nœuds de données, cela peut provoquer un déséquilibre de l'utilisation du CPU, où l'utilisation du CPU de ces nœuds devient beaucoup plus élevée que celle des autres nœuds.

• Large key : l'accès à une large key consomme plus de mémoire, de ressources CPU et de bande passante réseau. Une large key est plus susceptible de devenir une hotkey, contribuant ainsi à une utilisation élevée du CPU. Si des large keys sont concentrées sur des nœuds de données spécifiques, cela peut entraîner un déséquilibre de l'utilisation du CPU, ainsi qu'un déséquilibre de l'utilisation de la mémoire et de la bande passante.

• Connexion éphémère : la création et la fermeture fréquentes de connexions consomment d'importantes ressources CPU pour la gestion des connexions plutôt que pour le traitement des données.

• AOF : la persistance par fichier append-only (AOF) est activée par défaut. Lorsqu'une instance est soumise à une charge lourde, les E/S disque du processus AOF peuvent augmenter l'utilisation du CPU et la latence des commandes.

• Éviction des clés expirées : lorsqu'un grand nombre de clés expirent simultanément, Redis consomme d'importantes ressources CPU pour récupérer les clés expirées, ce qui peut provoquer des pics d'utilisation du CPU.

  Pour dépanner ce scénario :

  1. Vérifiez si l'utilisation de la mémoire a baissé au moment où l'utilisation du CPU a augmenté. Une baisse de la mémoire accompagnée d'une expiration massive des clés indique que la récupération des clés expirées en est la cause.

  2. Exécutez la commande INFO pour vérifier si les compteurs expired_keys et evicted_keys ont augmenté de manière significative à ce moment-là.

  3. Pour plus d'informations, consultez la documentation sur Quelle est la politique d'éviction par défaut et sur Comment effacer les clés expirées.

Scénarios d'utilisation élevée du CPU

Une utilisation élevée du CPU se manifeste généralement dans trois scénarios courants :

• Pendant une période spécifique, l'utilisation du CPU augmente soudainement, atteignant parfois 100 %. Pour connaître les causes et les solutions, consultez Pic soudain de l'utilisation du CPU.

• Un nœud de données spécifique présente une utilisation élevée du CPU tandis que les autres nœuds de données ont une utilisation faible. Pour connaître les causes et les solutions, consultez Déséquilibre de l'utilisation du CPU entre les nœuds de données.

• Un nœud proxy spécifique présente une utilisation élevée du CPU tandis que les autres nœuds proxy ont une utilisation faible. Pour connaître les causes et les solutions, consultez Déséquilibre de l'utilisation du CPU entre les nœuds proxy.

Appliquez les mesures appropriées pour réduire l'utilisation du CPU en fonction de votre scénario.

Pic soudain de l'utilisation du CPU

Si l'utilisation globale du CPU de votre instance augmente soudainement, suivez ces étapes pour enquêter et résoudre le problème.

Identifier et désactiver les commandes gourmandes en CPU

Procédure

1. Utilisez la fonctionnalité de surveillance des performances pour identifier la plage horaire spécifique durant laquelle l'utilisation du CPU était élevée. Pour plus d'informations, consultez Afficher les données de surveillance des performances.

2. Utilisez les outils suivants pour identifier les commandes gourmandes en CPU :

   • La fonctionnalité latency insights enregistre la latence de toutes les commandes et événements personnalisés. Vous pouvez l'utiliser pour trouver les commandes présentant une latence élevée pendant une période spécifique sur un nœud donné.

   • La fonctionnalité slow query log enregistre les commandes qui dépassent un temps d'exécution spécifié (20 ms par défaut). Vous pouvez l'utiliser pour trouver les commandes de longue durée et gourmandes en CPU.

Solutions

• Évaluez et désactivez les commandes à haut risque et gourmandes en CPU, telles que FLUSHALL, KEYS et HGETALL. Pour plus d'informations, consultez Désactiver les commandes à haut risque.

• Facultatif : En fonction de vos besoins métier, envisagez les ajustements d'instance suivants :

  Remarque

  Si ni le journal des requêtes lentes ni le journal d'audit ne révèlent de commandes gourmandes en ressources, une utilisation élevée du CPU a généralement l'une des deux causes suivantes. Premièrement, un grand volume de commandes O(1) (telles que GET et SET) s'accumulant sous un QPS élevé — celles-ci s'exécutent plus rapidement que le seuil du journal des requêtes lentes (20 ms par défaut) et ne sont pas enregistrées, donc la désactivation des commandes n'aide pas ; adaptez plutôt l'architecture comme décrit ci-dessous pour répartir la pression des requêtes. Deuxièmement, des connexions éphémères fréquemment établies, qui consomment également du CPU et n'apparaissent pas dans le journal des requêtes lentes ; pour le dépannage et l'optimisation, consultez « Optimiser les connexions éphémères » dans cette rubrique.

  • Modifiez l'instance pour utiliser une architecture de séparation lecture/écriture afin de décharger les commandes ou applications gourmandes en CPU.

  • Modifiez l'instance pour utiliser une instance basée sur DRAM afin de tirer parti de ses capacités multithread et de réduire l'utilisation du CPU.

  Remarque

  Pour obtenir des instructions sur la modification de l'architecture et du type d'une instance, consultez Modifier les configurations d'une instance.

Optimiser les connexions éphémères

Procédure

1. Utilisez la fonctionnalité de surveillance des performances pour identifier la plage horaire spécifique durant laquelle l'utilisation du CPU était élevée. Pour plus d'informations, consultez Afficher les données de surveillance des performances.

2. Sur la page de surveillance des performances, vérifiez la présence d'une combinaison comprenant une utilisation élevée du CPU, un nombre élevé de connexions et un nombre de requêtes par seconde (QPS) inférieur aux attentes. Ce schéma indique un problème lié aux connexions éphémères.

Solutions

• Passez des connexions éphémères aux connexions persistantes, par exemple en utilisant un pool de connexions tel que JedisPool. Pour plus d'informations, consultez Utiliser un client pour se connecter à une instance.

• Modifiez l'instance pour utiliser une instance basée sur DRAM, qui est optimisée pour les connexions éphémères.

Désactiver AOF

AOF est activé par défaut. Sous une charge lourde, les opérations AOF fréquentes peuvent contribuer à une utilisation élevée du CPU.

Si vos exigences métier le permettent, envisagez de désactiver la persistance et de planifier les sauvegardes de données pendant les heures creuses afin de minimiser l'impact.

Évaluer la capacité du service

Si l'utilisation moyenne du CPU reste élevée (supérieure à 70 %) lors des opérations normales après avoir effectué les optimisations précédentes, votre instance présente probablement un goulot d'étranglement de performance.

Commencez par vérifier la présence de modèles d'accès anormaux, tels que des commandes inhabituelles ou un volume élevé de requêtes provenant d'un hôte d'application spécifique. Ces problèmes doivent être résolus au niveau de l'application. Si tous les accès sont légitimes, la charge élevée est un résultat normal de votre charge de travail. Pour garantir un fonctionnement stable, nous vous recommandons de mettre à niveau les spécifications de votre instance ou de passer à une architecture en cluster ou à une architecture de séparation lecture/écriture. Pour plus d'informations, consultez Modifier les configurations d'une instance.

Déséquilibre de l'utilisation du CPU sur les nœuds de données

Si vous utilisez une architecture en cluster ou une architecture de séparation lecture/écriture, vous pouvez constater que certains nœuds de données présentent une utilisation élevée du CPU tandis que d'autres ont une utilisation faible. Suivez ces étapes pour enquêter et résoudre le problème.

Dépanner et optimiser les hotkeys

Procédure

1. Utilisez la fonctionnalité de surveillance des performances pour identifier la plage horaire spécifique durant laquelle l'utilisation du CPU était élevée. Pour plus d'informations, consultez Afficher les données de surveillance des performances.

2. Sur la page d'historique de Real-time Key Statistics, sélectionnez le nœud de données présentant une utilisation élevée du CPU, spécifiez la plage horaire de l'étape 1, puis cliquez sur Search. Cela affiche les hotkeys pendant la période d'utilisation élevée du CPU.

Solutions

• Divisez la hotkey en fonction de votre logique métier. Par exemple, ajoutez un ID utilisateur ou une plage d'horodatage au nom de la clé.

• Si un volume élevé de requêtes de lecture provoque la hotkey, envisagez de modifier l'instance pour utiliser une architecture de séparation lecture/écriture afin de réduire la pression de lecture sur chaque nœud de données.

  Remarque

  Dans les scénarios avec des volumes de requêtes extrêmement élevés, une architecture de séparation lecture/écriture peut introduire une latence de réplication inévitable, ce qui peut entraîner la lecture de données obsolètes. Par conséquent, cette architecture peut ne pas être la solution optimale pour les charges de travail avec une pression élevée en lecture et en écriture qui nécessitent également une forte cohérence des données.

Identifier et désactiver les commandes gourmandes en CPU

Procédure

1. Utilisez la fonctionnalité de surveillance des performances pour identifier la plage horaire spécifique durant laquelle l'utilisation du CPU était élevée. Pour plus d'informations, consultez Afficher les données de surveillance des performances.

2. Utilisez les outils suivants pour identifier les commandes gourmandes en CPU :

   • La fonctionnalité latency insights enregistre la latence de toutes les commandes et événements personnalisés. Vous pouvez l'utiliser pour trouver les commandes présentant une latence élevée pendant une période spécifique sur un nœud donné.

   • La fonctionnalité slow query log enregistre les commandes qui dépassent un temps d'exécution spécifié (20 ms par défaut). Vous pouvez l'utiliser pour trouver les commandes de longue durée et gourmandes en CPU.

Solution

Évaluez et désactivez les commandes à haut risque et gourmandes en CPU, telles que FLUSHALL, KEYS et HGETALL. Pour plus d'informations, consultez Désactiver les commandes à haut risque.

Dépanner et optimiser les large keys

Procédure

1. Utilisez la fonctionnalité de surveillance des performances pour identifier la plage horaire spécifique durant laquelle l'utilisation du CPU était élevée. Pour plus d'informations, consultez Afficher les données de surveillance des performances.

2. Sur la page Cache Analysis, cliquez sur Analyze Now. Sélectionnez le nœud de données présentant une utilisation élevée du CPU et cliquez sur OK. Cela affiche les large keys qui existaient pendant la période d'utilisation élevée du CPU.

Solution

En fonction de vos exigences métier, divisez les large keys en clés plus petites pour répartir la charge des requêtes.

Déséquilibre de l'utilisation du CPU sur les nœuds proxy

Si vous utilisez une architecture en cluster ou une architecture de séparation lecture/écriture, vous pouvez constater que certains nœuds proxy présentent une utilisation élevée du CPU tandis que d'autres ont une utilisation faible. Suivez ces étapes pour enquêter et résoudre le problème.

Procédure

Dans l'onglet Proxy Node de la page Performance Trends, vérifiez si l'utilisation des connexions est équilibrée entre les nœuds. Pour plus d'informations, consultez Performance Trends.

Solutions

Effectuez l'une des opérations suivantes selon que l'utilisation des connexions est équilibrée ou non :

• Si l'utilisation des connexions est équilibrée : redémarrez votre application cliente ou les nœuds proxy pour rééquilibrer les connexions. Pour redémarrer un nœud proxy, consultez Redémarrer ou reconstruire les nœuds proxy.

• Si l'utilisation des connexions est déséquilibrée : ce déséquilibre est généralement causé par des opérations pipeline ou batch à grande échelle. Réduisez la taille de ces opérations, par exemple en divisant une opération batch volumineuse en plusieurs opérations plus petites.