Surveillance des performances de Redis

Introduction

Dans ce laboratoire, vous apprendrez à surveiller et à dépanner les problèmes de performance de Redis. Le laboratoire se concentre sur l'identification et la résolution des problèmes de latence, l'analyse de l'utilisation de la mémoire et l'optimisation des performances des requêtes.

Vous utiliserez la commande LATENCY DOCTOR pour diagnostiquer la latence, MEMORY STATS pour vérifier l'utilisation de la mémoire, SLOWLOG GET pour analyser les requêtes lentes et MEMORY PURGE pour optimiser la mémoire. En suivant le guide étape par étape, vous acquerrez une expérience pratique dans le maintien d'un déploiement Redis réactif et efficace.

Environnement pré-configuré

Pour garantir des démonstrations fiables, cet environnement de laboratoire a été pré-configuré avec :

• 1000 clés de type chaîne (user:1 à user:1000) contenant des données utilisateur
• 50 objets de type hash (profile:1 à profile:50) avec des informations de profil utilisateur
• 20 objets de type liste (logs:app1 à logs:app20) contenant des entrées de journal
• 10 objets de type set (tags:1 à tags:10) avec des données de tags
• Configuration Redis optimisée pour la surveillance des performances
• Données de latence et de slowlog pré-générées pour une analyse immédiate

Surveiller la latence avec LATENCY DOCTOR

Dans cette étape, nous allons explorer comment utiliser la commande LATENCY DOCTOR dans Redis pour diagnostiquer et résoudre les problèmes de latence. Comprendre et résoudre la latence est crucial pour maintenir un déploiement Redis réactif et efficace.

Qu'est-ce que la latence ?

La latence fait référence au délai entre l'envoi d'une requête à un serveur Redis et la réception d'une réponse. Une latence élevée peut avoir un impact négatif sur les performances de l'application, entraînant des temps de réponse lents et une mauvaise expérience utilisateur.

Présentation de LATENCY DOCTOR

La commande LATENCY DOCTOR est un outil puissant intégré à Redis qui aide à identifier les sources potentielles de latence. Elle analyse divers aspects du fonctionnement de Redis et fournit des informations sur ce qui pourrait causer des retards.

Guide étape par étape

1. Se connecter à Redis :

   Tout d'abord, connectez-vous à votre serveur Redis en utilisant la commande redis-cli. Ouvrez un terminal dans votre VM LabEx et exécutez la commande suivante :

   redis-cli

   Cela ouvrira l'interface en ligne de commande de Redis.

2. Vérifier la configuration actuelle :

   L'environnement a été pré-configuré avec la surveillance de la latence activée. Vous pouvez vérifier les paramètres actuels :

   CONFIG GET latency-monitor-threshold

   Cela devrait indiquer que le seuil est défini sur 10 millisecondes.

3. Exécuter LATENCY DOCTOR :

   Exécutez maintenant la commande LATENCY DOCTOR pour analyser le système :

   LATENCY DOCTOR

   Étant donné qu'il s'agit d'une instance Redis saine sans problèmes de latence significatifs, vous verrez probablement une sortie similaire à :

   Dave, no latency spike was observed during the lifetime of this Redis instance, not in the slightest bit. I honestly think you ought to sit down calmly, take a stress pill, and think things over.

   Ce message humoristique (une référence à HAL 9000 de "2001 : L'Odyssée de l'espace") indique que Redis fonctionne bien sans pics de latence détectés au-dessus du seuil configuré.

4. Comprendre la réponse de LATENCY DOCTOR :

   Lorsque LATENCY DOCTOR affiche le message "Dave", cela signifie :

   • Aucune commande n'a dépassé le seuil de surveillance de la latence (10 ms dans notre cas)
   • Redis fonctionne efficacement sans goulots d'étranglement de performance
   • Le système est sain du point de vue de la latence

   Dans les environnements de production avec des problèmes de latence réels, vous verriez une analyse détaillée comprenant :

   • Des pics de latence spécifiques et leurs causes
   • Des recommandations d'optimisation
   • Des ventilations détaillées des opérations lentes

5. Examiner le Slowlog (Analyse alternative) :

   Même lorsque LATENCY DOCTOR n'indique aucun problème, nous pouvons toujours examiner le slowlog pour voir quelles opérations prennent le plus de temps par rapport aux autres :

   SLOWLOG GET 10

   Vous verrez une sortie montrant les commandes récentes avec leurs temps d'exécution. Les entrées montrent :

   • ID unique : Identifiant séquentiel pour chaque entrée
   • Horodatage : Horodatage Unix lorsque la commande a été exécutée
   • Temps d'exécution : Temps en microsecondes (par exemple, 1954 microsecondes = 1,954 milliseconde)
   • Commande : La commande exécutée (affiche souvent "COMMAND" pour les opérations internes de Redis)
   • Informations client : Adresse IP et port du client

   Par exemple :

   1) 1) (integer) 10
      2) (integer) 1753255495
      3) (integer) 1954
      4) 1) "COMMAND"
      5) "127.0.0.1:42212"
      6) ""

   Cela montre une commande qui a pris 1 954 microsecondes (environ 2 millisecondes) pour s'exécuter.

6. Quitter redis-cli :

   Pour vous assurer que les commandes sont enregistrées, quittez redis-cli en tapant :

   exit

Comprendre l'importance

En utilisant LATENCY DOCTOR et en analysant le slowlog, vous pouvez obtenir des informations précieuses sur les performances de votre déploiement Redis. Même lorsque tout semble sain (comme l'indique le message "Dave"), une surveillance régulière permet d'assurer de bonnes performances continues et une détection précoce de tout problème émergent.

Vérifier la mémoire avec MEMORY STATS

Dans cette étape, nous allons apprendre à utiliser la commande MEMORY STATS dans Redis pour surveiller et comprendre l'utilisation de la mémoire. Une gestion efficace de la mémoire est cruciale pour la stabilité et les performances de votre serveur Redis.

Pourquoi surveiller la mémoire ?

Redis est un magasin de données en mémoire, ce qui signifie qu'il stocke toutes ses données dans la RAM. Si Redis manque de mémoire, cela peut entraîner une dégradation des performances, une perte de données, voire des plantages. La surveillance de l'utilisation de la mémoire vous permet d'identifier et de résoudre de manière proactive les problèmes potentiels liés à la mémoire.

Présentation de MEMORY STATS

La commande MEMORY STATS fournit un aperçu détaillé de la consommation de mémoire de Redis. Elle décompose l'utilisation de la mémoire en diverses catégories, vous donnant un aperçu de l'endroit où votre mémoire est utilisée.

Guide étape par étape

1. Se connecter à Redis :

   Connectez-vous à votre serveur Redis en utilisant la commande redis-cli. Ouvrez un terminal dans votre VM LabEx et exécutez la commande suivante :

   redis-cli

   Cela ouvrira l'interface en ligne de commande de Redis.

2. Exécuter MEMORY STATS :

   Une fois connecté, exécutez la commande MEMORY STATS :

   MEMORY STATS

   Redis rassemblera alors les statistiques de mémoire et affichera les résultats.

3. Interpréter la sortie :

   La sortie de MEMORY STATS est un dictionnaire de paires clé-valeur, où chaque clé représente une statistique de mémoire et la valeur représente sa valeur correspondante. Examinons un exemple de sortie et expliquons certaines des métriques clés :

   127.0.0.1:6379> MEMORY STATS
    1) "peak.allocated"
    2) (integer) 1114480
    3) "total.allocated"
    4) (integer) 1114480
    5) "startup.allocated"
    6) (integer) 948480
    7) "replication.buffer"
    8) (integer) 0
    9) "clients.slaves"
   10) (integer) 0
   11) "clients.normal"
   12) (integer) 6456
   13) "aof.buffer"
   14) (integer) 0
   15) "lua.vm"
   16) (integer) 0
   17) "overhead.total"
   18) (integer) 165992
   19) "keys.count"
   20) (integer) 0
   21) "keys.bytes-per-key"
   22) (integer) 0
   23) "dataset.bytes"
   24) (integer) 948488
   25) "dataset.percentage"
   26) "0.00%"
   27) "bytes-per-replica.avg"
   28) (integer) 0
   29) "bytes-per-replica.min"
   30) (integer) 0
   31) "bytes-per-replica.max"
   32) (integer) 0
   33) "allocator.fragratio"
   34) "1.00"
   35) "allocator.fragbytes"
   36) (integer) 0
   37) "allocator.rss"
   38) (integer) 835584
   39) "allocator.peak"
   40) (integer) 1114112
   41) "total.system"
   42) (integer) 4194304
   43) "allocator.resident"
   44) (integer) 835584

   Voici une explication de certaines des métriques clés :

   • peak.allocated : La quantité maximale de mémoire que Redis a allouée depuis son démarrage.
   • total.allocated : La quantité totale de mémoire actuellement allouée par Redis.
   • dataset.bytes : La taille totale des données stockées dans Redis (hors surcharge).
   • overhead.total : La quantité totale de mémoire utilisée pour la surcharge de Redis (par exemple, structures de données, métadonnées).
   • keys.count : Le nombre de clés actuellement stockées dans Redis.
   • allocator.fragratio : Le ratio de fragmentation de l'allocateur de mémoire. Une valeur plus élevée indique une fragmentation plus importante.
   • allocator.rss : La quantité de mémoire utilisée par Redis telle que rapportée par le système d'exploitation (Resident Set Size).
   • total.system : La quantité totale de mémoire disponible sur le système.

4. Quitter redis-cli :

   Pour vous assurer que les commandes sont enregistrées, quittez redis-cli en tapant :

   exit

Utiliser les informations

Les informations fournies par MEMORY STATS peuvent être utilisées pour :

• Identifier les fuites de mémoire.
• Optimiser les structures de données pour réduire l'utilisation de la mémoire.
• Ajuster les paramètres de configuration de Redis pour améliorer l'efficacité de la mémoire.
• Déterminer si vous devez augmenter la quantité de RAM disponible pour votre serveur Redis.

Analyser les requêtes lentes avec SLOWLOG GET

Dans cette étape, nous allons nous plonger dans l'analyse des requêtes lentes à l'aide de la commande SLOWLOG GET dans Redis. Identifier et optimiser les requêtes lentes est essentiel pour maintenir un déploiement Redis réactif et efficace. Comme suggéré par LATENCY DOCTOR dans la première étape, l'analyse du slowlog est une étape cruciale pour déboguer les problèmes de latence.

Qu'est-ce que le Slowlog ?

Le slowlog est un système dans Redis qui enregistre les requêtes qui dépassent un temps d'exécution spécifié. Cela vous permet d'identifier les requêtes qui prennent plus de temps que prévu et qui pourraient potentiellement affecter les performances.

Guide étape par étape

1. Se connecter à Redis :

   Connectez-vous à votre serveur Redis en utilisant la commande redis-cli. Ouvrez un terminal dans votre VM LabEx et exécutez la commande suivante :

   redis-cli

   Cela ouvrira l'interface en ligne de commande de Redis.

2. Vérifier la configuration du Slowlog :

   L'environnement a été pré-configuré avec des paramètres de slowlog appropriés. Vous pouvez vérifier la configuration actuelle :

   CONFIG GET slowlog-log-slower-than

   CONFIG GET slowlog-max-len

   Ces commandes devraient indiquer que Redis est configuré pour enregistrer les commandes prenant plus de 1000 microsecondes (1 milliseconde) et stocker jusqu'à 128 entrées de slowlog.

3. Récupérer les entrées du Slowlog :

   Utilisez la commande SLOWLOG GET pour récupérer les entrées du slowlog. Pour récupérer les 10 entrées de slowlog les plus récentes, utilisez la commande suivante :

   SLOWLOG GET 10

   Vous verrez une sortie similaire à celle-ci (montrant les opérations internes récentes de Redis) :

    1) 1) (integer) 10
       2) (integer) 1753255495
       3) (integer) 1954
       4) 1) "COMMAND"
       5) "127.0.0.1:42212"
       6) ""
    2) 1) (integer) 9
       2) (integer) 1753255494
       3) (integer) 4795
       4) 1) "COMMAND"
       5) "127.0.0.1:41444"
       6) ""
    3) 1) (integer) 8
       2) (integer) 1753255494
       3) (integer) 1599
       4) 1) "COMMAND"
       5) "127.0.0.1:41004"
       6) ""

4. Interpréter la sortie :

   La sortie de SLOWLOG GET est un tableau d'entrées de slowlog. Chaque entrée contient six informations :

   1. ID unique : Un identifiant séquentiel pour l'entrée du slowlog (par exemple, 10, 9, 8...)
   2. Horodatage : L'horodatage Unix lorsque la requête a été exécutée
   3. Temps d'exécution : Le temps d'exécution en microsecondes (par exemple, 1954 = 1,954 milliseconde)
   4. Tableau de commandes : La commande qui a été exécutée (affiche souvent "COMMAND" pour les opérations internes de Redis)
   5. IP et port du client : L'adresse IP et le port du client (par exemple, "127.0.0.1:42212")
   6. Nom du client : Le nom du client (généralement vide, affiché comme "")

   Comprendre les temps :

   • 1954 microsecondes = 1,954 milliseconde
   • 4795 microsecondes = 4,795 millisecondes
   • 1599 microsecondes = 1,599 milliseconde

5. Analyser les modèles courants :

   Dans l'environnement, vous verrez généralement :

   • Entrées "COMMAND" : Celles-ci représentent les opérations internes de Redis comme l'analyse et le traitement des commandes.
   • Temps en microsecondes : La plupart des opérations sont très rapides (1-5 millisecondes).
   • Connexions locales : Toutes les connexions proviennent de 127.0.0.1 (localhost).

6. Générer des requêtes lentes plus détaillées :

   Pour voir des requêtes lentes plus spécifiques avec les données préexistantes, exécutons des opérations qui parcourront le jeu de données :

   KEYS user:*

   Cette commande parcourra toutes les clés utilisateur (1000 clés), qui devraient apparaître dans le slowlog.

   Vérifiez maintenant le slowlog mis à jour :

   SLOWLOG GET 3

   Vous devriez maintenant voir la commande KEYS user:* dans le slowlog avec un format tel que :

   1) 1) (integer) 11
      2) (integer) [timestamp]
      3) (integer) [execution_time]
      4) 1) "KEYS"
         2) "user:*"
      5) "127.0.0.1:[port]"
      6) ""

7. Optimisation de la mémoire avec MEMORY PURGE :

   Démontrons également l'optimisation de la mémoire. Tout d'abord, vérifiez l'utilisation actuelle de la mémoire :

   MEMORY STATS

   Recherchez la valeur total.allocated dans la sortie. Maintenant, libérons de la mémoire en purgeant la mémoire inutilisée :

   MEMORY PURGE

   Vérifiez à nouveau l'utilisation de la mémoire :

   MEMORY STATS

   Comparez les valeurs total.allocated pour voir si de la mémoire a été libérée. La commande MEMORY PURGE tente de libérer la mémoire qui n'est pas activement utilisée par Redis.

8. Quitter redis-cli :

   Pour vous assurer que les commandes sont enregistrées, quittez redis-cli en tapant :

   exit

Utiliser les informations

En analysant le slowlog, vous pouvez identifier les requêtes lentes et prendre des mesures pour les optimiser. Les informations clés comprennent :

• Fréquence des commandes : La fréquence à laquelle les commandes lentes apparaissent.
• Modèles d'exécution : Si certaines opérations apparaissent systématiquement dans le slowlog.
• Tendances de performance : Les changements dans les temps d'exécution au fil du temps.
• Utilisation des ressources : Les commandes qui peuvent consommer excessivement de CPU ou de mémoire.

Ces informations vous aident à :

• Optimiser les requêtes de l'application.
• Identifier les modèles problématiques.
• Planifier la mise à l'échelle et la capacité.
• Déboguer les problèmes de performance en production.

Résumé

Dans ce laboratoire, nous avons exploré les techniques de surveillance des performances de Redis en utilisant un environnement pré-configuré qui démontre les outils réels de surveillance des performances de Redis.

Nous avons commencé par utiliser la commande LATENCY DOCTOR pour comprendre comment Redis diagnostique les problèmes de latence. Dans notre environnement sain, nous avons vu le message caractéristique "Dave" indiquant qu'aucune pointe de latence n'a été détectée, ce qui nous a appris à interpréter le retour d'information de la surveillance de la latence de Redis lorsque les systèmes fonctionnent bien.

Ensuite, nous avons examiné la commande MEMORY STATS pour analyser les modèles d'utilisation de la mémoire de Redis. Avec le jeu de données pré-configuré de 1000 clés de type chaîne, 50 objets hash, 20 listes et 10 ensembles, nous avons observé une allocation de mémoire réaliste et appris à identifier les métriques de mémoire clés comme total.allocated, dataset.bytes et overhead.total.

Nous avons ensuite exploré la commande SLOWLOG GET pour analyser les performances des requêtes. Nous avons appris à interpréter les entrées du slowlog en six éléments, à comprendre les temps d'exécution en microsecondes, et nous avons observé comment les opérations internes de Redis "COMMAND" apparaissent dans le slowlog. Nous avons également démontré la génération de requêtes lentes personnalisées à l'aide de commandes de correspondance de motifs comme KEYS user:*.

Enfin, nous avons démontré l'optimisation de la mémoire à l'aide de la commande MEMORY PURGE, en comparant l'utilisation de la mémoire avant et après la purge pour comprendre comment Redis gère la mémoire efficacement.

Tout au long du laboratoire, nous avons appris à :

1. Interpréter la sortie de LATENCY DOCTOR, y compris le message "système sain".
2. Analyser les modèles d'utilisation de la mémoire avec MEMORY STATS en utilisant des métriques de jeu de données réelles.
3. Lire et comprendre les entrées du slowlog avec leur structure en six éléments.
4. Générer et analyser des requêtes lentes à l'aide d'opérations de correspondance de motifs.
5. Optimiser l'utilisation de la mémoire avec MEMORY PURGE.
6. Distinguer les opérations internes de Redis des commandes utilisateur dans la surveillance des performances.

Cette expérience pratique avec les outils de surveillance des performances intégrés de Redis fournit la base pour maintenir des déploiements Redis réactifs et efficaces dans les environnements de production.