Introduction
Dans ce laboratoire, vous apprendrez à surveiller et à résoudre 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 ce 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 balises - Une configuration Redis optimisée pour la surveillance des performances
- Des 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 traiter la latence est crucial pour maintenir un déploiement Redis réactif et efficace.
Qu'est-ce que la latence ?
La latence désigne le 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 nuire aux 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
Connexion à Redis :
Tout d'abord, connectez-vous à votre serveur Redis en utilisant la commande `redis-cli`. Ouvrez un terminal dans votre machine virtuelle LabEx et exécutez ce qui suit :
```bash
redis-cli
```
Cela ouvrira l'interface de ligne de commande Redis.
Vérification de 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 :
```bash
CONFIG GET latency-monitor-threshold
```
Cela devrait indiquer que le seuil est fixé à 10 millisecondes.
Exécution de LATENCY DOCTOR :
Exécutez maintenant la commande `LATENCY DOCTOR` pour analyser le système :
```bash
LATENCY DOCTOR
```
Comme il s'agit d'une instance Redis saine sans problème de latence significatif, vous verrez probablement une sortie similaire à celle-ci :
```
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 dans "2001, l'Odyssée de l'espace") indique que Redis fonctionne correctement, sans pic de latence détecté au-dessus du seuil configuré.
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 goulot d'étranglement de performance
- Le système est sain du point de vue de la latence
Dans des environnements de production rencontrant des problèmes de latence réels, vous verriez une analyse détaillée incluant :
- Des pics de latence spécifiques et leurs causes
- Des recommandations d'optimisation
- Des ventilations détaillées des opérations lentes
Examen du 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 :
```bash
SLOWLOG GET 10
```
Vous verrez une sortie affichant les commandes récentes avec leurs temps d'exécution. Les entrées indiquent :
- **ID unique :** Identifiant séquentiel pour chaque entrée
- **Horodatage :** Horodatage Unix de l'exécution de la commande
- **Temps d'exécution :** Temps en microsecondes (par exemple, 1954 microsecondes = 1,954 millisecondes)
- **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.
Quitter redis-cli :
Pour vous assurer que les commandes sont enregistrées, quittez `redis-cli` en tapant :
```bash
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 une bonne performance continue et de détecter rapidement tout problème émergent.
Vérifier la mémoire avec MEMORY STATS
Dans cette étape, nous apprendrons à 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 plusieurs catégories, vous donnant des indications sur l'endroit où votre mémoire est utilisée.
Guide étape par étape
Connexion à Redis :
Connectez-vous à votre serveur Redis en utilisant la commande `redis-cli`. Ouvrez un terminal dans votre machine virtuelle LabEx et exécutez ce qui suit :
```bash
redis-cli
```
Cela ouvrira l'interface de ligne de commande Redis.
Exécution de MEMORY STATS :
Une fois connecté, exécutez la commande `MEMORY STATS` :
```bash
MEMORY STATS
```
Redis collectera alors les statistiques de mémoire et affichera les résultats.
Interprétation de 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 ventilation de certaines 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 overhead).
- **`overhead.total` :** La quantité totale de mémoire utilisée pour l'overhead 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 taux 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.
Quitter redis-cli :
Pour vous assurer que les commandes sont enregistrées, quittez `redis-cli` en tapant :
```bash
exit
```
Utilisation des 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 approfondir l'analyse des requêtes lentes en utilisant 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 dépassant 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
Connexion à Redis :
Connectez-vous à votre serveur Redis en utilisant la commande `redis-cli`. Ouvrez un terminal dans votre machine virtuelle LabEx et exécutez ce qui suit :
```bash
redis-cli
```
Cela ouvrira l'interface de ligne de commande Redis.
Vérification de 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 :
```bash
CONFIG GET slowlog-log-slower-than
```
```bash
CONFIG GET slowlog-max-len
```
Ces commandes devraient montrer que Redis est configuré pour enregistrer chaque commande pendant ce laboratoire (`slowlog-log-slower-than` est à `0`) et stocker jusqu'à 128 entrées de slowlog. En production, vous utiliseriez généralement un seuil plus élevé afin que seules les commandes plus lentes que votre objectif de performance soient enregistrées.
Récupération des 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 :
```bash
SLOWLOG GET 10
```
Vous verrez une sortie similaire à celle-ci. Les ID exacts, les horodatages, les temps d'exécution et les numéros de port seront différents dans votre environnement :
```
1) 1) (integer) 10
2) (integer) 1753255495
3) (integer) 321
4) 1) "EVAL"
2) "local total = 0; for i=1,1000 do local value = redis.call('GET', 'user:' .. i); if value then total = total + string.len(value) end end; return total"
3) "0"
5) "127.0.0.1:42212"
6) ""
2) 1) (integer) 9
2) (integer) 1753255494
3) (integer) 225
4) 1) "KEYS"
2) "*"
5) "127.0.0.1:41444"
6) ""
3) 1) (integer) 8
2) (integer) 1753255494
3) (integer) 5
4) 1) "SLOWLOG"
2) "RESET"
5) "127.0.0.1:41004"
6) ""
```
Interprétation de la sortie :
La sortie de `SLOWLOG GET` est un tableau d'entrées de slowlog. Chaque entrée contient six informations :
- **ID unique :** Un identifiant séquentiel pour l'entrée du slowlog (par exemple, 10, 9, 8...)
- **Horodatage :** L'horodatage Unix de l'exécution de la requête
- **Temps d'exécution :** Le temps d'exécution en microsecondes (par exemple, 1954 = 1,954 millisecondes)
- **Tableau de commande :** La commande qui a été exécutée et ses arguments
- **IP et port du client :** L'adresse IP et le port du client (par exemple, "127.0.0.1:42212")
- **Nom du client :** Le nom du client (généralement vide, affiché comme "")
**Comprendre les temps :**
- 321 microsecondes = 0,321 millisecondes
- 225 microsecondes = 0,225 millisecondes
- 5 microsecondes = 0,005 millisecondes
Analyse des modèles courants :
Dans l'environnement, vous verrez généralement :
- **Tableaux de commandes :** Des entrées telles que `EVAL`, `KEYS`, `CONFIG` et `SLOWLOG`, suivies de leurs arguments
- **Temps en microsecondes :** La plupart des opérations sont très rapides, souvent inférieures à 1 milliseconde
- **Connexions locales :** Toutes les connexions proviennent de 127.0.0.1 (localhost)
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 vont parcourir l'ensemble de données :
```bash
KEYS user:*
```
Cette commande va parcourir toutes les clés utilisateur (1000 clés), ce qui devrait apparaître dans le slowlog.
Vérifiez maintenant le slowlog mis à jour :
```bash
SLOWLOG GET 3
```
Vous devriez maintenant voir la commande `KEYS user:*` dans le slowlog avec un format comme :
```
1) 1) (integer) 11
2) (integer) [timestamp]
3) (integer) [execution_time]
4) 1) "KEYS"
2) "user:*"
5) "127.0.0.1:[port]"
6) ""
```
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 :
```bash
MEMORY STATS
```
Recherchez la valeur `total.allocated` dans la sortie. Maintenant, libérons de la mémoire en purgeant la mémoire inutilisée :
```bash
MEMORY PURGE
```
Vérifiez à nouveau l'utilisation de la mémoire :
```bash
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.
Quitter redis-cli :
Pour vous assurer que les commandes sont enregistrées, quittez `redis-cli` en tapant :
```bash
exit
```
Utilisation des informations
En analysant le slowlog, vous pouvez identifier les requêtes lentes et prendre des mesures pour les optimiser. Les informations clés incluent :
- Fréquence des commandes : À quelle fréquence les commandes lentes apparaissent
- Modèles d'exécution : Si certaines opérations apparaissent systématiquement dans le slowlog
- Tendances de performance : Évolution des temps d'exécution au fil du temps
- Utilisation des ressources : Commandes susceptibles de consommer trop 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'aucun pic de latence n'a été détecté, ce qui nous a appris à interpréter les retours de 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 l'ensemble de données préconfiguré de 1000 clés de type chaîne, 50 objets hash, 20 listes et 10 sets, 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 de slowlog à six éléments, en comprenant les temps d'exécution en microsecondes, et avons observé comment les opérations internes "COMMAND" de Redis apparaissent dans le slowlog. Nous avons également démontré la génération de requêtes lentes personnalisées en utilisant des commandes de correspondance de motifs comme KEYS user:*.
Enfin, nous avons démontré l'optimisation de la mémoire en utilisant la commande MEMORY PURGE, en comparant l'utilisation de la mémoire avant et après la purge pour comprendre comment Redis gère efficacement la mémoire.
Tout au long du laboratoire, nous avons appris à :
- Interpréter la sortie de
LATENCY DOCTOR, y compris le message de "système sain" - Analyser les modèles d'utilisation de la mémoire avec
MEMORY STATSen utilisant des métriques d'ensemble de données réelles - Lire et comprendre les entrées de slowlog avec leur structure à six éléments
- Générer et analyser des requêtes lentes en utilisant des opérations de correspondance de motifs
- Optimiser l'utilisation de la mémoire avec
MEMORY PURGE - Distinguer les opérations internes de Redis des commandes utilisateur lors de la surveillance des performances
Cette expérience pratique avec les outils de surveillance des performances intégrés de Redis constitue la base pour maintenir des déploiements Redis réactifs et efficaces dans des environnements de production.
