Les données de Redis sont stockées en RAM. Si ce système permet de fournir des temps de réponse imbattables, le volume de données que vous pouvez stocker est limité et cela peut avoir des conséquences sur vos applications.
Infogérance Redis
Chez Bearstech nous infogérerons fréquemment des systèmes avec un service Redis, et de temps en temps, il arrive qu'un développeur nous alerte parce que son application ne fonctionne plus, et en y regardant de plus près, on constate qu'un client Redis échoue à insérer ou modifier une valeur avec le message :
OOM command not allowed when used memory > 'maxmemory'
Est-ce que le service Redis est en rade ? Ce qui est sûr c'est que l'application ne fonctionne plus correctement.
Du point de vue de l'infogéreur, Redis fonctionne bien : il répond à toutes les requêtes, mais l'application lui a fait dépasser un quota et elle ne peut plus ajouter de données. C'est un problème applicatif / métier.
Si nous intervenons pour effacer les données avec FLUSHALL, cela va faire disparaître l'erreur, mais comment savoir si ces données peuvent être effacées sans conséquences ?
L'application doit prendre le relais
Redis est une base de données "clé-valeur" qui fonctionne en RAM, et pour qu'à chaque instant les données soient bien en RAM physique (et non swap), elle limite l'usage à un quota prédéfini (normalement au plus la moitié de la RAM physique disponible).
Dans la vaste majorité des cas Redis est utilisé pour stocker des données qui peuvent être "perdues" (cache, sessions). Pour ce cas d'usage, le programmeur insère des données en précisant qu'elles peuvent "expirer"; mais il est possible de les déclarer "non-expirables".
Pour les données marquées "expirables", Redis peut être autorisé à les effacer avant même leur date d'expiration si jamais il vient à manquer d'espace. C'est documenté, et un gestionnaire de cache ou de sessions ne voit aucun problème à ce qu'un élément disparaisse (même si dans le cas des sessions ceci a pour effet de déloguer un utilisateur).
Donc tout va pour le mieux si ces 2 conditions sont respectées :
- toutes les valeurs stockées dans Redis sont expirables
- Redis est configuré pour être autorisé à évincer des éléments même s'ils n'ont pas encore expiré
Expiration des données
Pour le premier point, consultez votre framework/app favorite. C'est votre code et seulement lui qui décide de l'expirabilité intrinsèque de vos données, le serveur n'y est pour rien. Ce sera donc bien la première chose à vérifier et corriger avant d'aller voir côté serveur.
Pour vérifier votre situation, sollicitez votre serveur Redis directement et demandez-lui le statut de vos DBs :
# redis-cli info keyspace
# Keyspace
db0:keys=259,expires=0,avg_ttl=0
Là on a une situation potentiellement problématique, il n'y a aucun élément expirable (expires=0).
Dans le cas très courant cache/session, la bonne situation s'afficherait ainsi :
# redis-cli info keyspace
# Keyspace
db0:keys=259,expires=259,avg_ttl=30306971994
(note: avg_ttl est en millisecondes)
A noter que la non-expiration des données peut être voulue : typiquement quand Redis est utilisé comme pubsub et/ou stockage de workqueue (cf. Sidekick, RQ, etc.). Dans ce cas il est alors fortement recommandé de ne pas utiliser le même serveur Redis pour les deux usages opposés - cache/session et pubsub - car ils reposent sur une politique incompatible de gestion de la limite mémoire.
Politique d'évincement automatique
Enfin vérifiez que Redis a une politique d'évincement des clés, dans 99% des cas c'est ce que vous voulez :
# grep ^maxmemory-policy /etc/redis/redis.conf
maxmemory-policy volatile-lru
Les politiques qui font l'affaire sont toutes valables, sauf noeviction qui se trouve être la valeur d'usine de Redis. Ainsi ce dernier choisit sagement de vous laissez décider si des données peuvent être automatiquement effacées.
Nous pouvons vous accompagner si vous souhaitez obtenir des conseils d'optimisation avec Redis, ou bénéficier de nos audits de performance pour vos applications.
