Passer au contenu 
Le Slow Log de Redis m'indique précisément quelles commandes bloquent le thread du serveur et combien de temps leur exécution dure (à la microseconde près), ce qui me permet d'éliminer de manière ciblée les sources de latence. Grâce à des seuils fiables, une exportation propre et des métriques corrélées, j'optimise la Performance durable.
Points centraux
Avant d'approfondir le sujet, je définis les points clés afin de procéder de manière ciblée. Je me concentre sur des configurations claires, des schémas récurrents et des contre-mesures efficaces. Je veille également à tenir compte du contexte du client et de l'environnement système. C'est ainsi que j'obtiens une approche cohérente Analyse sans bruit. Ensuite, je transpose directement ces conclusions dans des modifications du code, du modèle de données et du système de surveillance.
- Seuil et choisir judicieusement la longueur du journal
- Modèles sur Temps, reconnaître les commandes et les clients
- Exécution des commandes au ralenti Alternatives remplacer
- Modèle de données et Mise en cache resserrer
- Connexions lentes Suivi intègrent
Slow Log : explication succincte du fonctionnement
Je conçois le « Slow Log » comme une vision ciblée de la pure Temps d'exécution d’une commande dans le thread unique de Redis. Le serveur enregistre automatiquement une entrée dès que la durée dépasse le seuil défini en microsecondes via l’option `slowlog-log-slower-than`. Chaque enregistrement me fournit un ID, un horodatage Unix, la durée d’exécution, la commande avec ses arguments, l’adresse IP et le port du client, ainsi qu’un nom de client (facultatif). Le Slow Log exclut délibérément les E/S réseau et la transmission des réponses, ce qui me permet de voir le temps de blocage réel du thread. C’est précisément cette distinction qui m’aide à différencier clairement les causes logiques de la latence réseau ou client et à Cause mieux cerner.
Configuration : seuil et longueur du journal
Pour bien démarrer la journée, je mets le Seuil souvent à 10 000 microsecondes (environ 10 ms) ; lors des tests, je le réduis temporairement afin de capturer des détails plus fins. Je contrôle le nombre d’entrées enregistrées à l’aide de slowlog-max-len, généralement compris entre 128 et 4 096, afin que les pics de charge restent bien visibles. Je modifie ces deux valeurs soit dans le fichier redis.conf, soit à l’exécution à l’aide de CONFIG SET, ce qui me permet de disposer de fenêtres de diagnostic flexibles. Avant de lancer des tests de charge importants, j’abaisse le seuil ; une fois ceux-ci terminés, je le remets à une valeur de production réaliste. Je garde ainsi le journal allégé, sans pour autant omettre des informations importantes Signaux de perdre.
| Paramètre/Commande | Signification | valeur pratique |
|---|---|---|
| slowlog-log-plus lent que | Seuil en microsecondes pour les entrées | Production : 10 000 µs ; test : 1 000 à 5 000 µs |
| slowlog-max-len | Nombre maximal d'entrées enregistrées | 128 à 4 096 entrées selon le volume |
| SLOWLOG GET N | Affiche les N derniers enregistrements | N = 10 à 100 pour les contrôles ponctuels |
| SLOWLOG LEN | Renvoie la longueur actuelle du journal | Vérifier régulièrement |
| SLOWLOG RESET | Vide le journal | Exporter/sauvegarder au préalable |
Consulter le « Slow Log » au quotidien
Dans le cadre de mon travail quotidien, je récupère les dernières entrées à l'aide de la commande SLOWLOG GET et je vérifie, avec SLOWLOG LEN, dans quelle mesure les commandes lentes s'accumulent, avant de vider le journal si nécessaire à l'aide de SLOWLOG RESET. Une exportation avant la réinitialisation m'évite de perdre de précieuses Historique je perds des informations, surtout lorsque je souhaite comparer les tendances sur plusieurs jours. Dans les configurations en cluster, j'intègre chaque instance et chaque réplique, car le Slow Log est spécifique à chaque instance et il resterait sinon des angles morts. Pour les analyses structurées, je relie les entrées à des informations client telles que l’adresse IP, le port et le nom défini, afin d’identifier sans ambiguïté la source dans le code de l’application. De plus, je consulte les statistiques INFO pour évaluer les fréquences et les latences dans le contexte de l’utilisation globale.
Des événements aux modèles : analyse systématique
Je vais d'abord examiner les commandes les plus courantes et les plus importantes Durée de validité puis je vérifie à quelle fréquence elles apparaissent au total sur l'instance. Une commande qui dépasse rarement le seuil dérange moins qu'une autre qui, bien que dépassant très légèrement ce seuil, s'exécute pourtant des milliers de fois par minute. Les regroupements temporels observés lors des tâches Cron, des sauvegardes ou des pics de trafic m’indiquent si ces phénomènes sont dus à des pics d’activité ou à des routines applicatives. La commande `INFO commandstats` me fournit des informations contextuelles sur le nombre d’appels et leur durée moyenne, que je peux facilement consulter dans l’article INFO commandstats approfondis. J'associe les noms de clients identifiés dans la liste CLIENT LIST à des services ou à des microservices, ce qui me permet d'attribuer les responsabilités et de Optimisation planifie de manière ciblée.
Stratégies d'optimisation : commandes et modèle de données
Je remplace les instructions coûteuses telles que KEYS sur de grands volumes de données par SCAN avec des curseurs personnalisés, afin d'éviter les blocages et d'optimiser la Latence réduire. Lorsque les scripts Lua s'exécutent trop longtemps, je décompose la logique en plusieurs petites étapes ou j'utilise des données pré-agrégées. Souvent, les temps d'exécution longs sont le symptôme d'un problème au niveau du modèle de données : je divise les très grandes listes, les ensembles ou les hachages, j'utilise des index supplémentaires ou des types de données plus adaptés. Pour les calculs coûteux et récurrents, je mets les résultats en cache plus près de l’application et je les invalide de manière contrôlée, au lieu de forcer sans cesse leur recalcul. Je résume de manière pratique les erreurs de configuration et les anti-modèles typiques via les erreurs de configuration typiques ensemble, afin que je puisse corriger plus rapidement les erreurs évitables et que la Efficacité augmente.
Contexte client et code d'application
Dans le code, je réduis le nombre d'allers-retours grâce au pipelining et au regroupement, ce qui me permet de réduire le temps de Temps de serveur sans pour autant les modifier, mais en réduisant considérablement la latence perçue par appel. Les paramètres issus des entrées du Slow Log m'indiquent où se trouvent les boucles inutiles ou les accès répétés. Je veille à ce que les clients attribuent des noms pertinents via CLIENT SETNAME, afin que l’affectation soit immédiatement claire au sein de l’équipe. Je répartis les charges d’écriture en identifiant les touches de raccourci, en diversifiant les modèles d’accès et en vérifiant les stratégies TTL. Lors des phases de migration ou de l’activation de drapeaux de fonctionnalité, j’observe de manière ciblée les entrées des chemins concernés afin d’identifier rapidement les répercussions et de Qualité de sécuriser.
Ressources, topologie et sources de latence
La lenteur n'est pas toujours due à des commandes inefficaces ; c'est pourquoi je vérifie les pics d'utilisation du processeur, les goulots d'étranglement de la mémoire et la latence du réseau parallèlement aux Entrées dans le Slow Log. Une répartition défavorable des shards, un nombre insuffisant de répliques ou des chemins inter-zones trop longs augmentent la durée perçue. Je vérifie également les paramètres RDB/AOF et les tâches en arrière-plan qui sollicitent brièvement le processus serveur. En cas de charge élevée, j’envisage des options de mise à l’échelle si le modèle de données est déjà optimisé et que le choix des commandes est approprié. Ce n’est qu’après avoir établi une corrélation avec les métriques du système que j’obtiens des résultats clairs Causalité‑chaînes visibles.
Intégrer Slow Log dans la surveillance
Un tableau de bord dédié me permet de suivre l'évolution de la longueur des journaux, le nombre de commandes lentes par service et les indicateurs associés, tels que l'utilisation du processeur et de la mémoire. J'intègre les données du journal des commandes lentes dans les pipelines d'observabilité existants, créant ainsi un flux continu de Suivi. Dans les interfaces graphiques, je filtre par commandes, dates et clients afin d'isoler plus rapidement les anomalies. Pour les workflows pratiques, je privilégie les outils proposant des vues « Slow Log », un environnement de travail et des fonctions d'exportation, comme ceux que j'utilise dans le Guide RedisInsight décrire. Cela me permet de raccourcir considérablement le processus de diagnostic et d'améliorer la pertinence de la Métriques.
Guide pratique : étape par étape
Je commence par m'assurer que les paramètres « slowlog-log-slower-than » et « slowlog-max-len » sont correctement définis, afin de ne pas générer de bruit ni d'omettre des données pertinentes Signaux perds. Ensuite, je lis les derniers enregistrements, je les sauvegarde et j’identifie les commandes suspectes en tenant compte de leur fréquence et de leur durée. À l’étape suivante, j’analyse les plages horaires, je recoupe les noms de CLIENTS et je recherche des schémas récurrents dans les paramètres. J’en déduis ensuite des mesures concrètes à prendre au niveau du code, du modèle de données et des concepts de mise en cache. Pour finir, j’intègre cette analyse dans mon système de surveillance permanente afin de détecter les tendances à un stade précoce et Régressions empêcher.
Données empiriques et critères de réglage
Une valeur initiale de 10 ms comme seuil convient bien à de nombreux environnements de production, tandis que des valeurs plus faibles peuvent s'avérer utiles lors des tests Détails fournir. J'ajuste la longueur du journal de manière à ce qu'elle reflète les tendances quotidiennes ou hebdomadaires typiques, sans gaspiller d'espace de stockage. Je définis une valeur de référence, je documente les répartitions typiques des commandes et je reste attentif aux changements insidieux. Après chaque déploiement, je consulte systématiquement le Slow Log afin de détecter rapidement si de nouvelles fonctionnalités génèrent des chemins de latence indésirables. Cette discipline permet d’obtenir des indications fiables sur le moment où je dois procéder à des ajustements et sur la manière dont je dois Performance maintenir à un niveau élevé à long terme.
Limites et remarques d'interprétation du « Slow Log »
Je tiens compte du fait que le Slow Log ne mesure que le temps d'exécution pur dans le thread du serveur. Les temps d'attente dans la file d'attente des commandes, les coûts liés à la négociation TLS ou le transport de réponses volumineuses sur le réseau n'y apparaissent pas. De même, pour des raisons de mémoire, les arguments de commande sont limités et peuvent être tronqués dans le Slow Log ; c’est pourquoi je considère ces paramètres uniquement à titre indicatif et non comme une réalité exhaustive. Comme le journal fonctionne sur la base de seuils, j’obtiens un échantillon des cas les plus lents et non une distribution complète. C’est pourquoi je complète ces analyses avec les percentiles de latence issus de la surveillance et j’utilise, si nécessaire, le moniteur LATENCY intégré (seuil défini via `latency-monitor-threshold`) pour détecter les pics sporadiques.
Particularités des clusters et de la réplication
Dans les configurations en cluster, je vérifie si les commandes lentes sont concentrées sur des slots ou des shards spécifiques. Les opérations inter-slots (par exemple, MGET sur des clés sans balise de hachage) entraînent des erreurs ou des détours et génèrent des allers-retours inutiles qui ne sont pas visibles dans le journal des ralentissements (Slow Log), mais qui augmentent la latence perçue. Les rééquilibrages, les basculements et les rattrapages de réplication influencent la charge du système : des commandes telles que WAIT peuvent délibérément prendre plus de temps jusqu’à ce que les accusés de réception soient reçus. Sur les répliques de secours, les profils d’accès sont différents ; j’y examine les entrées du slow log séparément, car les charges de lecture, les efforts de synchronisation et les processus d’arrière-plan diffèrent les uns des autres. Pour un diagnostic précis, j’exporte le slow log de chaque instance et je corrèle les horodatages sur tous les nœuds.
Persistance, bifurcations et comportement de la mémoire
Je surveille de près les instantanés RDB et les réécritures AOF : lors de la création d'un fork du processus Redis, le „ copy-on-write “ peut entraîner temporairement des besoins élevés en mémoire et des pics d'utilisation du processeur, ce qui prolonge à son tour le temps d'exécution des commandes. Les paramètres AOF (par exemple appendfsync) influencent les latences d'écriture ; „ everysec “ constitue généralement un bon compromis, tandis que « always » augmente la durabilité, mais peut favoriser l'apparition de pics. Je tiens également compte de la défragmentation active de la mémoire, des évictions et du traitement des clés expirées. Les clés individuelles volumineuses (par exemple, des hachages comportant des dizaines de milliers de champs) provoquent des pauses perceptibles lors des cycles d’expiration ou des suppressions. Grâce aux options `lazyfree` (par exemple `lazyfree-lazy-eviction`), je soulage le thread principal en effectuant la libération des grandes structures de manière asynchrone, à condition que le profil de charge de travail s’y prête.
Commandes de blocage, Multi-Key et de script
Je fais la distinction entre les commandes dont la complexité est linéaire (O(N)) et celles dont la complexité est logarithmique ou constante. Les commandes SORT, SUNIONSTORE, ZUNIONSTORE ou HGETALL, lorsqu'elles sont appliquées à de grandes structures, apparaissent souvent dans le « Slow Log ». EVAL/EVALSHA sont certes atomiques et pratiques, mais peuvent bloquer longtemps le thread serveur en raison de boucles internes ; il vaut mieux ici recourir à des étapes intermédiaires plus petites et bien optimisées. Les commandes bloquantes telles que BLPOP ou XREAD BLOCK bloquent principalement le client, et non le thread serveur ; elles deviennent toutefois critiques lorsqu’elles sont associées à de très grandes structures de données. Lors de l’analyse, j’évite les motifs MATCH larges sans logique d’index et je calibre COUNT de manière à maintenir la charge sous contrôle ; SCAN protège contre les blocages complets, mais ne constitue pas un passe-droit pour les recherches non ciblées.
Exportation, automatisation et traitement des données
Pour garantir la reproductibilité des analyses, j'exporte régulièrement le Slow Log et j'uniformise son format. J'ajoute aux entrées le nom du client, les utilisateurs (ACL) et les balises de service afin que la propriété soit clairement identifiée. Un workflow simple via le shell m'aide à réaliser des exportations ponctuelles :
# Exportation au format similaire à JSON des 500 dernières entrées
redis-cli SLOWLOG GET 500 > slowlog.raw
# Exemple au format CSV (ID ; horodatage ; durée en µs ; commande ; client)
# Remarque : les arguments peuvent être tronqués dans le Slow Log
redis-cli --raw SLOWLOG GET 200 | awk '
BEGIN{FS="\n"; OFS=";"}
/1\)/{id=$2} /2\)/{ts=$2} /3\)/{dur=$2} /4\)/{cmd=$0; gsub(/^[^"]*"/,"",cmd); gsub(/"[^$]*/,"",cmd)} /5\)/{client=$0}
/5\)/{print id,ts,dur,cmd,client}
' > slowlog.csv
Dans les pipelines d'automatisation, je récupère les données sur tous les nœuds, je normalise les horodatages (UTC) et je génère des métriques par commande, par client et par fenêtre temporelle. Je veille à exporter les données avant chaque SLOWLOG RESET et à adapter la fréquence de rotation à la longueur du journal afin qu'aucun pic ne soit perdu.
Modèles de procédure pour la gestion des incidents
Dans les cas urgents, je commence par préserver le statu quo : je vérifie la valeur de SLOWLOG LEN, j'exporte généreusement les dernières entrées et j'augmente temporairement la valeur de slowlog-max-len afin qu'aucune donnée ne soit supprimée. Ensuite, j'abaisse modérément le seuil afin de détecter également les modèles se situant juste en dessous du seuil précédent. En parallèle, je surveille l’utilisation du CPU, la mémoire RSS, les erreurs de page (Page Faults), le temps de transit réseau (RTT) ainsi que les événements de persistance (RDB/AOF). Si certaines commandes apparaissent en masse, je les réduis temporairement à l’aide de feature flags ou de limites de débit plus strictes. Pour les raccourcis clavier, je répartis les accès (hachage des touches/répartition des fragments) et j’augmente la capacité de réplication si nécessaire. Dès que le pic est passé, je procède à une analyse approfondie des causes et je mets en place des correctifs permanents dans le code et le modèle de données.
Assurance qualité avant et après les déploiements
Avant chaque mise en production, j’abaisse considérablement le seuil du Slow Log dans l’environnement de staging afin de détecter rapidement les micro-inefficacités. Je définis des budgets de latence acceptables (par exemple p95/p99 par commande) et je les compare à une référence documentée. Après le déploiement, je surveille de près les entrées du Slow Log pour les services concernés ; tout écart entraîne une annulation rapide du déploiement ou des optimisations ciblées. Un déploiement « canary » par shard/zone m’aide à observer les effets de manière isolée. La communication est essentielle : chaque client attribue un nom évocateur afin que je puisse immédiatement associer les entrées du « slow log » à un responsable – cela accélère considérablement la résolution des problèmes.
Logique de décision pour le seuil et la longueur du logarithme
Je ne définis pas le seuil de manière absolue, mais en fonction du contexte : sur les nœuds très rapides équipés de NVMe et disposant d’une puissance CPU importante, j’ai tendance à le réduire à 5–8 ms en période de production afin de détecter les points chauds subtils ; avec du matériel économique ou un trafic en rafales intense, je reste plus prudent afin que le journal conserve un signal fort. J’adapte la longueur du journal en fonction du débit de commandes et de l’intervalle d’exportation : plus la fréquence des commandes est élevée, plus la fenêtre est grande (par exemple 2 048 à 4 096), afin de capturer des cycles de trafic complets. Lors des tests de charge, je règle délibérément une longueur élevée et je planifie les exportations en temps réel afin de ne perdre aucun pic. Pendant les phases de repos, je réduis ces valeurs pour économiser de la mémoire et maintenir une analyse ciblée.
Modèles fréquents dans la pratique
En général, je distingue trois catégories de causes : premièrement, les opérations O(N) coûteuses sur des structures volumineuses (tri, unions de grands ensembles/tableaux de hachage, itérations complètes) ; deuxièmement, les effets secondaires du système (forks, défragmentation, évictions) et, troisièmement, les modèles d’application (accès N+1, calculs redondants, absence de mise en cache). Les mesures correctives en découlent directement : remplacement d’instructions et limitation du volume de données, décuplage des opérations lourdes dans des tâches/files d’attente, libération asynchrone d’objets volumineux, stratégies de TTL et d’invalidation rigoureuses, ainsi qu’une agrégation accrue au plus près du consommateur. J’associe toujours ces mesures à des métriques afin que les progrès soient mesurables et que les régressions soient rapidement visibles.
Résumé concis
J'utilise le Slow Log pour enregistrer la simple Temps de serveur Je mets en évidence les commandes coûteuses, je définis des seuils adaptés et je protège les enregistrements contre les réinitialisations. Grâce aux configurations via redis.conf ou CONFIG SET, je garde une certaine flexibilité dans la période de diagnostic sans consommer inutilement de mémoire. À partir des entrées, je déduis des tendances concernant les commandes, les durées et les clients, puis j’optimise le choix des commandes, le modèle de données, la mise en cache et le code de l’application. En parallèle, je corrèle les statistiques du Slow Log avec les métriques système ainsi que les signaux APM afin d’identifier clairement les causes. Ainsi, la Performance Cela devient prévisible et les problèmes de latence perdent leur effet de surprise.
