data / redis
Performance et monitoring niveau expert
Explication
Ce que vous allez apprendre
- Diagnostiquer la latence d'un Redis en production avec les outils intégrés
- Identifier les commandes lentes avec le
SLOWLOG - Analyser l'usage mémoire et choisir une politique d'éviction adaptée
- Comprendre pourquoi Redis étant mono-thread change les règles de performance
- Utiliser
UNLINKet le lazy freeing pour éviter qu'une suppression ne bloque le serveur
Dans quel contexte ?
Une équipe SRE reçoit une alerte : les temps de réponse de l'API ont doublé depuis une heure, et Redis est identifié comme le maillon suspect. Sans outils de diagnostic, il est tentant de redémarrer le service en espérant que le problème disparaisse — mais sans comprendre la cause, il reviendra. Cette leçon donne la méthode pour identifier précisément ce qui ralentit un Redis en production, plutôt que de deviner.
D'abord, le réflexe numéro un : mesurer la latence
redis-cli --latency mesure en continu le temps de réponse moyen du serveur, tandis que LATENCY HISTORY et LATENCY LATEST remontent les pics de latence déjà enregistrés par Redis lui-même, classés par catégorie d'événement (fork, expire-cycle, etc.). C'est toujours le point de départ d'un diagnostic, avant de chercher plus loin.
Prérequis
Cette leçon suppose que tu connais déjà les bases de la persistance et de la réplication, car certains pics de latence proviennent justement d'un BGSAVE ou d'une resynchronisation en cours.
Une fois un problème de latence détecté, il faut trouver la commande responsable
Le SLOWLOG enregistre automatiquement toute commande dépassant un seuil configurable (slowlog-log-slower-than, en microsecondes). SLOWLOG GET 10 affiche les dix dernières commandes lentes enregistrées — souvent la piste la plus directe vers la cause réelle d'un ralentissement.
| Outil | Ce qu'il révèle |
|---|---|
redis-cli --latency | Latence moyenne en temps réel |
SLOWLOG GET | Les commandes ayant dépassé un seuil de durée |
INFO memory | Mémoire utilisée et taux de fragmentation |
redis-cli --bigkeys | Les plus grosses clés par type de donnée |
Piège courant
Redis exécute les commandes sur un seul thread : une commande lente (par exemple un KEYS * sur des millions de clés, ou un SORT sans LIMIT sur un immense set) bloque littéralement tout le serveur pendant son exécution, y compris pour les autres clients qui attendent une simple lecture triviale. C'est la raison principale pour laquelle certaines commandes O(n) sont à bannir absolument du chemin critique.
Il reste un aspect tout aussi important : la mémoire
INFO memory et MEMORY STATS révèlent la mémoire réellement utilisée et le taux de fragmentation, tandis que redis-cli --bigkeys et --memkeys identifient les clés les plus volumineuses. Quand maxmemory est atteint, la politique d'éviction choisie détermine quelles clés Redis sacrifie en premier : allkeys-lru évince la moins récemment utilisée, allkeys-lfu la moins fréquemment utilisée (souvent un meilleur choix pour un cache généraliste), et noeviction refuse simplement toute nouvelle écriture une fois la limite atteinte.
Bonne pratique
Préfère UNLINK à DEL pour supprimer une clé volumineuse. DEL libère la mémoire de façon synchrone et peut bloquer le serveur le temps de l'opération, alors qu'UNLINK délègue cette libération à un thread d'arrière-plan (lazy freeing), sans jamais geler les autres clients.
Ce parcours Redis touche ici à sa fin : des structures de données de base jusqu'au clustering et au monitoring de production, tu disposes maintenant d'une vision complète pour concevoir, sécuriser et exploiter Redis à l'échelle d'une véritable architecture professionnelle.
Commandes & code
Performance et monitoring niveau expert
# --- Diagnostiquer la latence ---
redis-cli --latency -h localhost -p 6379 # mesure la latence moyenne en continu
redis-cli --latency-history # historique par tranches de temps
redis-cli --intrinsic-latency 5 # latence "physique" de la machine (5s de test)
LATENCY HISTORY command # historique des événements de latence par catégorie
LATENCY LATEST # derniers pics de latence enregistrés
LATENCY RESET
# --- Trouver les commandes lentes ---
CONFIG SET slowlog-log-slower-than 10000 # log les commandes > 10ms (en microsecondes)
CONFIG SET slowlog-max-len 256
SLOWLOG GET 10 # 10 dernières entrées lentes
SLOWLOG LEN
SLOWLOG RESET
# --- Analyser l'usage mémoire ---
INFO memory # used_memory, fragmentation ratio, etc.
MEMORY USAGE ma_cle # octets utilisés par une clé précise
MEMORY DOCTOR # diagnostic automatique et conseils
MEMORY STATS # statistiques mémoire détaillées
# Trouver les plus grosses clés (attention : peut être lourd sur une grosse base)
redis-cli --bigkeys # scan et rapporte les plus grosses clés par type
redis-cli --memkeys # scan et rapporte les clés qui consomment le + de mémoire
# --- Politique d'éviction quand maxmemory est atteint ---
CONFIG SET maxmemory 2gb
CONFIG SET maxmemory-policy allkeys-lru
# allkeys-lru -> évince la clé la moins récemment utilisée, parmi TOUTES les clés
# volatile-lru -> pareil, mais uniquement parmi les clés AVEC un TTL
# allkeys-lfu -> évince la moins FRÉQUEMMENT utilisée (souvent meilleur que LRU en pratique)
# noeviction -> refuse les nouvelles écritures une fois la limite atteinte (erreurs applicatives)
# --- Monitoring temps réel (impact perf : usage ponctuel/debug uniquement) ---
MONITOR # affiche CHAQUE commande exécutée, en direct
# --- Statistiques générales du serveur ---
INFO stats
# instantaneous_ops_per_sec, keyspace_hits, keyspace_misses, evicted_keys, expired_keys
INFO clients
# connected_clients, blocked_clients
# Calculer le hit ratio du cache
redis-cli INFO stats | grep -E "keyspace_hits|keyspace_misses"
# hit_ratio = keyspace_hits / (keyspace_hits + keyspace_misses)# --- Bonnes pratiques niveau expert ---
# 1. Éviter les commandes O(n) sur de grosses structures en hot path : KEYS, SMEMBERS sur set géant, SORT sans LIMIT
# 2. Pipeline systématiquement les opérations en batch (réduit drastiquement le round-trip time)
# 3. Redis est mono-thread pour l'exécution : une commande lente bloque TOUT le serveur -> profiler avec SLOWLOG
# 4. Activer le lazy freeing (UNLINK au lieu de DEL) pour les grosses clés, libération mémoire en arrière-plan
# 5. Dimensionner maxmemory avec de la marge : la fragmentation mémoire peut ajouter 10-40% de overhead
# 6. io-threads (Redis 6+) peut paralléliser la lecture/écriture réseau (pas l'exécution des commandes elle-même)# UNLINK : suppression asynchrone, ne bloque pas le serveur (contrairement à DEL sur une clé énorme)
UNLINK grosse_cle_avec_millions_elements
# io-threads (redis.conf) : parallélise le traitement réseau sur plusieurs cœurs
io-threads 4
io-threads-do-reads yesRésumé
SLOWLOGet--latencysont les premiers réflexes pour diagnostiquer un Redis lent en production.- La politique d'éviction (
maxmemory-policy) doit être choisie selon l'usage : LFU souvent meilleur qu'LRU pour un cache général. - Redis étant mono-thread côté exécution de commandes, éviter absolument les opérations O(n) en hot path.
UNLINKet le lazy freeing évitent qu'une suppression de grosse clé ne bloque tout le serveur.
Exercices pratiques
Mission : identifier pourquoi l'API a doublé de temps de réponse en une heure
Objectif : Utiliser le SLOWLOG pour identifier une commande coupable, comprendre l'impact d'une commande bloquante sur un serveur mono-thread, et diagnostiquer un problème combinant éviction mémoire et fragmentation.
Contexte
Une équipe SRE reçoit une alerte : les temps de réponse de l'API ont doublé depuis une heure, et Redis est suspecté. Tu dois utiliser les outils de diagnostic vus dans cette leçon pour identifier la commande responsable, corriger une suppression risquée, puis interpréter des métriques mémoire contradictoires en apparence.