Hub de Connaissances DevOps
Hub de Connaissances DevOps

Diagnostic et résolution des requêtes Redis lentes à l'aide de la commande SLOWLOG

Exploitez la puissance de la commande SLOWLOG de Redis pour identifier et résoudre les goulots d'étranglement de la base de données. Ce guide complet vous explique comment configurer `slowlog-log-slower-than` et `slowlog-max-len`, récupérer et interpréter les entrées de requêtes lentes, et appliquer des stratégies d'optimisation pratiques telles que le pipelining et l'ajustement des structures de données. Apprenez à diagnostiquer efficacement la dégradation des performances, à identifier les commandes coûteuses et à garantir que votre déploiement Redis reste rapide et efficace, améliorant ainsi la réactivité et la stabilité de votre application.

46 vues

Diagnostic et résolution des requêtes Redis lentes à l'aide de la commande SLOWLOG

Redis est un magasin de données en mémoire incroyablement rapide, largement utilisé pour la mise en cache, l'analyse en temps réel, la gestion de session et le courtage de messages. Ses performances sont souvent critiques pour la réactivité des applications construites sur celui-ci. Cependant, même avec la vitesse de Redis, des commandes mal optimisées ou une charge inattendue peuvent entraîner des requêtes lentes, créant des goulots d'étranglement qui dégradent les performances globales de l'application.

Identifier la cause profonde de ces problèmes de performance est la première étape pour les résoudre. C'est là que la fonctionnalité intégrée SLOWLOG de Redis devient un outil inestimable. Elle permet aux développeurs et aux équipes d'exploitation de consigner et d'analyser méticuleusement les commandes qui dépassent un temps d'exécution spécifié, fournissant des informations cruciales sur les goulots d'étranglement potentiels de la base de données et les opérations coûteuses. Cet article vous guidera dans la compréhension, la configuration et l'utilisation de la commande SLOWLOG pour diagnostiquer et résoudre la dégradation des performances dans vos déploiements Redis.

Comprendre la fonctionnalité Redis SLOWLOG

La SLOWLOG est un système qui enregistre les requêtes dépassant un temps d'exécution spécifié. Il s'agit essentiellement d'un journal en mémoire des commandes qui ont mis plus de temps qu'un seuil configuré pour s'exécuter. Contrairement à un journal traditionnel basé sur des fichiers, SLOWLOG est stocké directement dans la mémoire de Redis, ce qui le rend rapide à accéder et à gérer sans encourir de surcharge d'E/S disque.

Chaque entrée dans le SLOWLOG contient plusieurs informations : un ID séquentiel unique, l'horodatage Unix auquel la commande a été enregistrée, le temps d'exécution total de la commande (en microsecondes), la commande elle-même (avec ses arguments), l'adresse IP et le port du client qui a exécuté la commande, et le nom du client (s'il est défini). En examinant ces entrées, vous pouvez identifier des commandes spécifiques, détecter des modèles et, finalement, optimiser l'interaction de votre application avec Redis.

Comment fonctionne SLOWLOG : paramètres de configuration

Avant de pouvoir utiliser efficacement SLOWLOG, il est important de comprendre et de configurer ses deux paramètres principaux. Ces paramètres contrôlent ce qui est enregistré et combien d'entrées sont conservées.

slowlog-log-slower-than

Ce paramètre définit le seuil de temps d'exécution (en microsecondes) pour qu'une commande soit enregistrée. Seules les commandes qui prennent plus de temps que cette valeur spécifiée seront enregistrées dans le SLOWLOG. Définir cette valeur trop bas pourrait enregistrer trop de commandes, consommer potentiellement une quantité significative de mémoire et rendre l'analyse difficile. La définir trop haut pourrait vous faire manquer des requêtes véritablement lentes.

  • Valeur par défaut: 10000 (10 millisecondes)
  • Recommandation: Commencez avec la valeur par défaut et ajustez-la en fonction des exigences de performance de votre application. Pour les systèmes haute performance, vous pourriez la réduire à 1000 microsecondes (1 milliseconde) ou même 100 microsecondes.
  • Valeur spéciale: La définir à 0 enregistrera toutes les commandes. La définir à une valeur négative désactivera SLOWLOG entièrement.

Vous pouvez afficher la valeur actuelle de ce paramètre :

redis-cli config get slowlog-log-slower-than

Pour définir une nouvelle valeur (par exemple, 5000 microsecondes, soit 5 millisecondes) :

redis-cli config set slowlog-log-slower-than 5000

Pour rendre ce changement permanent, vous devrez mettre à jour votre fichier redis.conf ou utiliser CONFIG REWRITE s'il est pris en charge par votre version et votre configuration Redis.

slowlog-max-len

Ce paramètre spécifie le nombre maximum d'entrées que Redis conservera dans le SLOWLOG. Lorsque le journal atteint sa longueur maximale, les nouvelles entrées entraîneront la suppression automatique des entrées les plus anciennes (FIFO - First In, First Out).

  • Valeur par défaut: 128 entrées
  • Recommandation: La valeur par défaut est souvent trop faible pour les systèmes de production très sollicités. Envisagez de l'augmenter à 1024 ou même 4096 pour vous assurer de capturer suffisamment d'historique pour une analyse approfondie, en tenant compte des implications en matière de mémoire.

Vous pouvez afficher la valeur actuelle :

redis-cli config get slowlog-max-len

Pour définir une nouvelle valeur (par exemple, 1024 entrées) :

redis-cli config set slowlog-max-len 1024

Encore une fois, n'oubliez pas de persister ce changement dans votre fichier redis.conf.

Récupération et analyse des entrées SLOWLOG

Une fois SLOWLOG configuré, vous pouvez interagir avec lui à l'aide d'un ensemble de commandes.

SLOWLOG GET

Cette commande est utilisée pour récupérer des entrées du SLOWLOG. Vous pouvez éventuellement spécifier un count pour récupérer un certain nombre des entrées les plus récentes.

  • SLOWLOG GET: Récupère toutes les entrées actuellement dans le journal.
  • SLOWLOG GET <count>: Récupère les <count> dernières entrées.

Exemple :

# Récupérer les 10 dernières entrées du journal lent
redis-cli slowlog get 10

Exemple de sortie (simplifié pour plus de clarté) :

1) 1) (integer) 12345        # ID unique de l'entrée du journal
   2) (integer) 1678886400   # Horodatage Unix (par exemple, 15 mars 2023, 12:00:00 UTC)
   3) (integer) 25000        # Temps d'exécution en microsecondes (25 ms)
   4) 1) "LRANGE"           # La commande
      2) "mybiglist"       # Argument 1
      3) "0"               # Argument 2
      4) "-1"              # Argument 3
   5) "127.0.0.1:54321"  # IP et port du client
   6) "client-name-app" # Nom du client (s'il est défini)
...

SLOWLOG LEN

Cette commande renvoie le nombre actuel d'entrées dans le SLOWLOG.

redis-cli slowlog len

Sortie :

(integer) 5

SLOWLOG RESET

Cette commande efface toutes les entrées du SLOWLOG. Ceci est utile après avoir analysé les entrées existantes et que vous souhaitez commencer avec un nouveau journal pour capturer de nouvelles données de performance.

redis-cli slowlog reset

Sortie :

OK

Interprétation de la sortie SLOWLOG

Chaque entrée fournit des informations critiques :

  1. ID unique: Un identifiant séquentiel. Utile pour suivre des événements spécifiques.
  2. Horodatage: Quand la commande a été exécutée. Aide à corréler les requêtes lentes avec les changements de déploiement d'application ou les périodes de charge spécifiques.
  3. Temps d'exécution (microsecondes): La métrique la plus importante. Ceci vous indique exactement combien de temps la commande a pris pour s'exécuter. Des valeurs élevées indiquent un goulot d'étranglement potentiel.
  4. Commande et arguments: La commande Redis exacte et ses paramètres. Ceci est crucial pour comprendre quelle opération était lente (par exemple, KEYS *, LRANGE 0 -1 sur une très grande liste, SORT sans LIMIT).
  5. Adresse du client: L'adresse IP et le port du client qui a émis la commande. Aide à retracer l'application ou le service source.
  6. Nom du client: Si votre application définit un CLIENT SETNAME (fortement recommandé pour une meilleure observabilité), cela fournit une couche de contexte supplémentaire, indiquant quelle partie de votre application a effectué la requête lente.

Exemple pratique : Identification d'une commande lente

Simulons une commande lente et voyons comment SLOWLOG la capture.

Tout d'abord, définissez slowlog-log-slower-than à une valeur faible pour la démonstration, par exemple, 1000 microsecondes (1 milliseconde) :

redis-cli config set slowlog-log-slower-than 1000

Ensuite, effectuez une opération connue pour être potentiellement lente si elle est appliquée à un grand ensemble de données, comme KEYS * ou un LRANGE sur une liste contenant de nombreux éléments.

Créons une grande liste :

for i in {1..100000}; do redis-cli LPUSH mybiglist $i; done

Maintenant, exécutez une commande LRANGE qui récupère tous les éléments de cette grande liste :

redis-cli LRANGE mybiglist 0 -1

Cette commande prendra probablement plus d'une milliseconde.

Enfin, vérifiez le SLOWLOG :

redis-cli slowlog get 1

Vous devriez voir une sortie similaire à celle-ci (les valeurs varieront) :

1) 1) (integer) 12346
   2) (integer) 1678886450
   3) (integer) 15432 # C'est notre temps d'exécution lent en microsecondes
   4) 1) "LRANGE"
      2) "mybiglist"
      3) "0"
      4) "-1"
   5) "127.0.0.1:54322"
   6) ""

La sortie montre clairement la commande LRANGE mybiglist 0 -1, son temps d'exécution (15432 microsecondes ou 15,432 ms) et quand elle s'est produite. Cela nous indique immédiatement que la récupération d'une liste entière de grande taille consomme un temps considérable.

Stratégies pour résoudre les requêtes lentes

Une fois que vous avez identifié les requêtes lentes à l'aide de SLOWLOG, la prochaine étape consiste à les optimiser. Voici des stratégies courantes :

  1. Optimiser les structures de données et les modèles d'accès :

    • Évitez les commandes O(N) sur de grands ensembles de données: Les commandes comme LRANGE 0 -1 (obtenir tous les éléments), SMEMBERS (obtenir tous les membres d'un ensemble), HGETALL (obtenir tous les champs/valeurs d'un hash), SORT (sans LIMIT) peuvent être lentes. Si vous devez traiter de grandes collections, envisagez d'itérer avec SCAN, SSCAN, HSCAN ou ZSCAN plutôt que de tout récupérer en une seule fois.
    • Utilisez des structures de données appropriées: Par exemple, si vous avez besoin d'obtenir fréquemment des attributs d'un objet, utilisez un Hash au lieu de stocker des clés individuelles pour chaque attribut.
    • Limitez les résultats: Pour les listes ou les ensembles triés, utilisez LRANGE <début> <fin> ou ZRANGE <début> <fin> avec des limites raisonnables au lieu de récupérer la structure entière.

  2. Pipelining: Au lieu d'envoyer des commandes une par une, regroupez plusieurs commandes dans une seule requête à l'aide du pipelining. Cela réduit la surcharge du temps d'aller-retour réseau (RTT), ce qui peut considérablement accélérer les applications, même si les commandes individuelles sont rapides.

    ```python

    Sans pipelining (plus lent en raison de multiples RTT)

    r.set('key1', 'value1')
    r.set('key2', 'value2')

    Avec pipelining (plus rapide, un seul RTT)

    pipe = r.pipeline()
    pipe.set('key1', 'value1')
    pipe.set('key2', 'value2')
    pipe.execute()
    ```

  3. Scripting Lua (EVAL): Pour les opérations complexes impliquant plusieurs commandes Redis qui doivent être exécutées de manière atomique ou avec des RTT minimaux, envisagez d'utiliser des scripts Lua. Les scripts sont exécutés directement sur le serveur Redis, réduisant la latence réseau et garantissant l'atomicité. Cependant, les scripts Lua à exécution longue peuvent bloquer Redis, ils doivent donc être soigneusement optimisés.

  4. Évitez KEYS en production: La commande KEYS est O(N) (où N est le nombre de clés dans la base de données) et peut bloquer le serveur Redis pendant une période prolongée, surtout sur de grandes bases de données. Utilisez SCAN pour itérer sur les clés dans les environnements de production. SCAN fournit une fonctionnalité de type itérateur qui peut être mise en pause et reprise, évitant les longues opérations de blocage.

    ```bash

    Mauvais en production

    redis-cli KEYS *

    Bon en production pour l'itération

    redis-cli SCAN 0 MATCH user:* COUNT 100
    ```

  5. Pooling de connexions: Assurez-vous que votre application utilise un pooling de connexions approprié pour gérer efficacement les connexions à Redis. Ouvrir et fermer des connexions pour chaque commande peut être gourmand en ressources.

  6. Sharding et clustering: Si votre ensemble de données ou votre charge de travail dépasse ce qu'une seule instance Redis peut gérer, envisagez de répartir votre stockage (sharding) sur plusieurs instances Redis ou d'adopter Redis Cluster. Cela distribue la charge et les données, empêchant une seule instance de devenir un goulot d'étranglement.

  7. Réplicas de lecture: Pour les charges de travail axées sur la lecture, déchargez les requêtes de lecture vers des réplicas de lecture Redis. Cela augmente le débit de lecture et réduit la charge sur l'instance principale, lui permettant de se concentrer sur les écritures.

Bonnes pratiques pour l'utilisation de SLOWLOG

  • Surveillance régulière: Ne vous contentez pas de le configurer et de l'oublier. Vérifiez régulièrement les entrées SLOWLOG, en particulier après les déploiements ou pendant les heures de pointe.
  • Seuils appropriés: Ajustez slowlog-log-slower-than en fonction de la latence acceptable de votre application. Ce qui est lent pour une application peut être normal pour une autre.
  • Longueur de journal suffisante: Définissez slowlog-max-len suffisamment grand pour conserver un historique significatif, mais pas trop grand au point de consommer une mémoire excessive.
  • Effacer périodiquement: Utilisez SLOWLOG RESET après avoir analysé les entrées pour obtenir de nouvelles données, ou envisagez d'automatiser ce processus si vous intégrez SLOWLOG à un système de surveillance.
  • Noms des clients: Utilisez CLIENT SETNAME <nom> dans le code de votre application. Cela ajoute un contexte précieux aux entrées SLOWLOG, facilitant le traçage des commandes lentes jusqu'à des parties spécifiques de votre application.

Conclusion

La commande SLOWLOG de Redis est un outil indispensable pour maintenir les performances et la stabilité de vos applications basées sur Redis. En configurant efficacement et en analysant régulièrement sa sortie, vous pouvez identifier, diagnostiquer et résoudre de manière proactive les requêtes lentes qui pourraient autrement passer inaperçues, conduisant à une meilleure réactivité de l'application et à une meilleure expérience utilisateur. N'oubliez pas que l'optimisation des performances de Redis est un processus continu qui implique la compréhension des modèles d'accès aux données de votre application, le choix des bonnes commandes et structures de données Redis, et une surveillance continue. SLOWLOG fournit la visibilité essentielle nécessaire pour prendre des décisions d'optimisation éclairées.