Dimensionner correctement le paramètre `maxmemory` de Redis : réserves de mémoire pour les données et le fonctionnement

Ce qui limite réellement la valeur de `maxmemory`

maxmemory crée dans Redis Open Source une Seuil d'expulsion Il n'y a pas de limite maximale stricte pour le processus Redis ou son conteneur. Lorsque la consommation prise en compte par le système de gestion de la mémoire atteint le seuil défini, Redis tente de supprimer des clés en fonction de la politique choisie. Dans le cas d'une politique sans éviction, les commandes d'écriture qui augmentent l'espace mémoire peuvent alors échouer.

L'indicateur used_memory comprend la mémoire allouée par Redis via son allocateur. Cela inclut non seulement les valeurs proprement dites de votre application, mais aussi les structures de gestion et d'autres zones de mémoire Redis. Si l'on détermine la limite en se basant uniquement sur la taille estimée des données utiles, on ne tient pas compte de cette surcharge.

Une partie de used_memory est exclu lors du test d'éviction : mem_not_counted_for_evict comporte notamment des tampons de réplication et AOF temporaires. Ces tampons occupent néanmoins de la mémoire physique. La valeur est déjà définie dans used_memory est déjà inclus et ne doit donc pas être ajouté une deuxième fois à cet indicateur sans vérification préalable.

Cela ne signifie pas pour autant que toutes les données des clients ou des répliques soient exclues du calcul d'éviction. Une seule commande volumineuse peut d'ailleurs dépasser temporairement et de manière significative le seuil. Si tu définis maxmemory Si l'on atteint la limite maximale du conteneur, il ne reste aucune marge de manœuvre fiable pour faire face à de tels pics et à la consommation supplémentaire des processus.

Pour la planification, il convient donc de répondre séparément à deux questions : de combien d'espace ont besoin les enregistrements et la surcharge Redis au sein du gestionnaire de mémoire ? Et de quelle réserve l'environnement d'exécution dans son ensemble a-t-il besoin en plus de cela ? Ce n'est qu'en combinant ces deux perspectives que l'on peut déterminer si une valeur choisie inférieure à la limite de mémoire réelle est plausible.

RSS, Allocator et pics de persistance

Après un pic de charge, il peut used_memory diminuent, tandis que used_memory_rss reste élevé : Redis a certes libéré de la mémoire via l'allocateur, mais celle-ci n'a pas nécessairement été restituée immédiatement au système d'exploitation. Le RSS décrit la mémoire résidente du processus du point de vue du système d'exploitation et constitue donc un autre niveau d'observation.

Supposons qu'un cache augmente considérablement de taille au cours d'une opération et que de nombreuses clés expirent par la suite. La réduction de l'espace mémoire Redis ne signifie pas automatiquement que le conteneur récupère immédiatement une quantité équivalente d'espace libre. Pour le prochain pic d'activité, il est donc plus important de tenir compte de l'évolution de la consommation réelle que de partir du principe que l'espace mémoire libéré disparaît immédiatement.

Voir aussi mem_fragmentation_ratio Il ne s'agit pas d'un simple pourcentage de fragmentation. Ce rapport englobe d'autres éléments du processus ; pour l'analyse des causes, tu devrais l'examiner conjointement avec les données disponibles allocator_*- les indicateurs et l'historique de charge. Il n'est pas possible de déduire une réserve universelle à partir d'un seul rapport.

Lors de la création d'instantanés RDB et de réécritures AOF, Redis génère un processus fils. Grâce à Copie à l'écriture Des pages de mémoire physique supplémentaires peuvent être nécessaires si des pages sont modifiées pendant le cycle de persistance. Plus la charge d'écriture est intense et étendue pendant cette phase, plus il est important d'en tenir compte lors de la planification des capacités.

L'équipe d'administration de Redis indique que, dans les cas extrêmes, les applications à forte intensité d'écriture peuvent nécessiter jusqu'à deux fois la mémoire habituellement utilisée. Il s'agit là d'un avertissement concernant des conditions de charge défavorables, et non d'un coefficient multiplicateur universel. De plus, il ne faut pas se contenter d’additionner les valeurs RSS des processus parents et enfants : les pages partagées seraient comptées plusieurs fois ; ce qui importe, c’est la surveillance appropriée de l’hôte ou du conteneur.

Les répliques nécessitent des budgets spécifiques

Une réplique conserve systématiquement une copie de l'ensemble des données et nécessite pour cela sa propre mémoire vive (RAM). Le serveur principal et la réplique sont donc des consommateurs de mémoire distincts : une réserve allouée au serveur principal ne libère pas d'espace dans le conteneur de la réplique. Planifiez chaque nœud en fonction de ses propres limites et de sa consommation observée.

Par défaut, une réplique ignore son maxmemory pour ses propres suppressions. Le maître décide de la suppression des clés et réplique ces suppressions. Néanmoins, les états de mémoire peuvent différer, notamment en raison de tampons ou de structures de données divergents ; une même valeur limite ne garantit donc pas une charge identique.

Dans le cas d'une Promotion l'ancienne réplique endosse alors le rôle de serveur principal. Vérifiez donc non seulement si elle dispose de suffisamment d'espace en tant que copie en lecture, mais aussi si sa limite de stockage et sa configuration permettent de fonctionner en tant que serveur principal. Cela concerne notamment la charge d'écriture, les connexions de réplication et la politique d'éviction alors en vigueur.

Depuis Redis 7.0, le tampon de réplication et la file d'attente de réplication partagent la même mémoire. mem_clients_slaves peut donc afficher zéro, même si la réplication occupe de la mémoire. Ne considérez pas ce champ isolément et ne considérez pas le backlog et le réplica-buffer comme des zones totalement distinctes sans vérification préalable.

Outre la consommation de mémoire, les progrès réalisés en matière de transfert de données ont une incidence sur le fonctionnement : un retard présente des caractéristiques différentes de celles de la taille d'un tampon. L'article consacré à ce sujet explique comment classer l'état de réplication et le retard. Décalage de réplication Redis. Pour la réserve de stockage, ce sont toutefois les courbes de consommation réelles de chaque instance qui restent déterminantes.

Recenser les espaces de stockage sur trois niveaux

Pour le dimensionnement, tu as besoin de données provenant de Redis et de l'environnement dans lequel l'instance s'exécute. Les niveau d'observation détermine ce que signifie un chiffre : l'occupation de l'allocateur, le RSS du processus et la consommation de conteneurs sont des grandeurs différentes qui ne peuvent pas être simplement additionnées.

Avec INFO memory tu peux notamment consulter les valeurs stockées dans Redis et la politique configurée. MEMORY STATS ajoute des détails sur la répartition de la mémoire. Ces deux commandes sont en lecture seule ; les champs disponibles dépendent de la version de Redis, des autorisations et de l'offre d'hébergement.

Pour vérifier la cohérence temporelle, tu dois également vérifier INFO persistence sur l'activité de persistance et les valeurs « copy-on-write » disponibles. INFO replication Affiche le rôle et l'état de réplication. Saisissez ces informations séparément pour le serveur principal et le serveur réplica, afin qu'un changement de rôle ou une synchronisation reste identifiable lors de l'analyse.

Une valeur isolée ne reflète ni la charge typique ni la réserve de pointe nécessaire. Collectez donc des séries chronologiques sur le fonctionnement normal, les pics d'écriture et les cycles de persistance, et associez-les à la consommation de l'hôte ou du conteneur observée simultanément. Vous pourrez ainsi déterminer si une valeur RSS élevée accompagne une charge actuelle ou si elle persiste après un pic antérieur.

Calculer un budget de stockage robuste

Le point de départ est la mesure effectivement applicable limite de stockage: Dans le cas d'un conteneur, elle peut être inférieure à la mémoire vive (RAM) de l'hôte. Identifiez les autres processus et composants du système qui utilisent cette même limite. L'espace qui leur est réservé n'est pas disponible pour Redis, que ce soit pour stocker des données ou pour gérer les pics de charge.

Déduisez ensuite les réserves destinées aux effets RSS et Allocator supplémentaires, aux tampons non pris en compte dans l'éviction, aux pics de persistance et à une marge de sécurité. Le résultat est une valeur provisoire maxmemory- Budget, pas d'équation interne à Redis. Les réserves doivent correspondre à la même limite et à des états de charge réalistes survenant simultanément.

Exemple de calcul à titre indicatif, pas de mesure : sur une limite de conteneur de 8 GiB, on déduit 0,5 GiB pour d'autres consommateurs, 0,5 GiB pour les effets RSS supplémentaires, 0,5 GiB pour les tampons exclus du calcul d'éviction, 1 GiB pour un pic de persistance et 0,5 GiB de marge de sécurité. Il reste donc, à titre provisoire, 5 GiB pour maxmemory.

Ces chiffres ne constituent pas une recommandation pour une instance spécifique. L'exemple part du principe que les réserves allouées correspondent à des contributions supplémentaires et sans chevauchement à la limite du conteneur. Dans le cadre d'une exécution persistante notamment, les pages mémoire partagées et le « copy-on-write » peuvent compliquer l'affectation ; une simple addition des valeurs RSS des processus parent et enfant ne serait pas adaptée dans ce cas.

Évite Comptages en double: mem_not_counted_for_evict se trouve déjà dans used_memory. Si tu te bases sur la consommation totale observée de RSS ou de conteneurs, tu ne dois pas rajouter cette part de mémoire tampon sans la vérifier au préalable. Le budget d'éviction restant doit pouvoir couvrir à la fois l'ensemble de données et la surcharge Redis prise en compte ; vérifie ensuite cette approche sous une charge comparable.

Comparaison pratique des politiques d'expulsion

Le Politique d'expulsion détermine la manière dont Redis réagit aux commandes d'écriture en cas de pénurie de mémoire. Elle ne remplace pas la planification des capacités : même une politique adaptée nécessite des réserves en dehors du calcul d'éviction. La décision dépend avant tout des clés qui peuvent être perdues et de la manière dont l'application réagit aux erreurs.

Dans le cas d'un cache pur, il est possible de allkeys-lru conviennent lorsque les entrées supprimées peuvent être recréées à partir d'une autre source. Dans Redis, l'algorithme LRU est une approximation et non un tri global exact. Des évictions fréquentes peuvent entraîner une augmentation du nombre d'accès au backend ; c'est pourquoi il faut tenir compte non seulement des octets libres, mais aussi du taux de réussite du cache et de la capacité du backend.

Pour les données qui ne peuvent pas être supprimées à volonté, noeviction Une autre décision : l'application doit être capable de gérer les opérations d'écriture ayant échoué, au lieu de supposer tacitement que l'enregistrement a réussi. Cette politique ne concerne ni la persistance, ni la protection contre un OOM au niveau du système d'exploitation ou du conteneur.

Dans le cas de stocks mixtes, la Discipline TTL déterminant : Une volatile-*- La politique ne peut sélectionner que des clés avec une durée de validité. S'il y a trop peu de candidats appropriés, la durée de vie (TTL) ne suffit pas à elle seule à protéger contre les erreurs d'écriture. Vérifiez donc si le cache et les données importantes doivent réellement partager la même instance et la même stratégie de gestion des erreurs.

Les données de session mettent en évidence ce conflit d'objectifs : la suppression d'une entrée peut entraîner la perte de l'état de session pour les utilisateurs, même si l'application continue techniquement de fonctionner. Évaluez les conséquences et la possibilité de restauration avant de choisir une politique ; vous trouverez des informations complémentaires dans l'article consacré à Gestion des sessions avec Redis et d'autres systèmes de stockage.

Vérifier la réserve sous charge

Une valeur calculée pour maxmemory C'est avant tout un point de départ. Testez-le dans un environnement isolé avec une version de Redis, une structure de données et une limite de mémoire comparables. La charge ne doit pas seulement refléter le fonctionnement habituel, mais aussi les pics d'écriture et les phases où la persistance et la réplication sont actives simultanément.

Observez alors le Consommation de conteneurs ou encore la métrique hôte correspondante ainsi que les valeurs de mémoire Redis. Notez quand un snapshot ou une réécriture AOF est en cours d'exécution et si une réplique est en cours de synchronisation. Ce qui est déterminant, c'est l'écart par rapport à la limite réelle pendant les événements qui se chevauchent, et pas seulement pendant la période d'inactivité qui suit.

Avec la commande de lecture INFO stats Tu enregistres notamment les compteurs d'éviction. Analyse l'évolution de ces valeurs par intervalle de temps : un niveau historique élevé ne suffit pas à lui seul à indiquer si des clés sont en train d'être évincées. Mets en relation l'augmentation des évictions avec les succès de cache et la charge du backend, dans la mesure où ton application fournit ces données.

Enregistrez également les réponses OOM de Redis dans l'application et les événements liés à la mémoire des conteneurs sur la plateforme. Ces deux types d'erreurs peuvent survenir sous une charge similaire, mais concernent des limites différentes. Une alerte doit donc tenir compte à la fois de la réserve disponible, des erreurs observées et de leur évolution dans le temps.

Répétez l'évaluation après toute modification apportée à l'ensemble de données, à la charge d'écriture ou à la persistance et à la réplication. Une promotion modifie également le rôle d'une réplique et, par conséquent, le profil de charge à analyser. Les résultats obtenus dans l'environnement isolé ne remplacent pas la surveillance continue des instances en production.

Identifier de manière ciblée les problèmes de mémoire

Si le RSS du processus augmente alors que used_memory Si cela se produit, examinez d'abord l'historique et la charge précédente. La mémoire libérée ne doit pas nécessairement être restituée immédiatement au système d'exploitation. La Indicateurs de l'allocateur de INFO memory aident à mettre les choses en perspective ; le taux de fragmentation ne prouve à lui seul ni l'existence d'une fuite de mémoire, ni sa cause.

Vérifie ensuite si cette augmentation coïncide avec une course de persistance ou une synchronisation. Pour cela, utilise INFO persistence et INFO replication. Une valeur isolée pour un tampon non pris en compte dans l'éviction ne décrit que l'état actuel. Pour évaluer une réserve, il faut disposer d'observations couvrant les phases de charge et de perturbation pertinentes.

Dans le cas d'une Réponse OOM de Redis Vérifiez la politique configurée et assurez-vous que des clés appropriées sont disponibles pour une éviction. En particulier, une commande d'écriture peut échouer si Redis ne parvient pas à libérer suffisamment d'espace dans le cadre de la politique en vigueur. L'application doit gérer cette erreur, au lieu de supposer que l'opération d'écriture a abouti.

En cas d'arrêt d'un conteneur lié à la mémoire, examinez en revanche les événements de la plateforme et la consommation par rapport à la limite du conteneur. Tenez compte des pics de persistance et des autres consommateurs enregistrés dans le conteneur. Un OOM Redis et un OOM de conteneur ne sont pas équivalents : la limite de mémoire externe peut être atteinte même sans réponse OOM Redis préalable.

maxmemory-clients peut également limiter la mémoire occupée par les clients. Si la mémoire utilisée par un client dépasse le seuil configuré, Redis peut déconnecter les clients qui consomment trop de mémoire ; les applications doivent alors gérer les interruptions de connexion. Ce paramètre ne limite pas toutes les connexions de réplication et ne remplace ni le budget global ni la surveillance des pics de mémoire tampon.

Évaluer les options d'hébergement et l'architecture de Redis

Si la réserve observée s'avère insuffisante avec une charge représentative, il peut être judicieux d'augmenter la mémoire vive (RAM) lorsque l'ensemble de données et la charge doivent en principe rester sur une seule instance. La capacité supplémentaire doit toutefois faire partie de la limite effective de l'hôte ou du conteneur. Une limite Redis plus élevée ne crée pas à elle seule de mémoire physique supplémentaire.

Sinon, on peut utiliser une Répartition de la charge répartir les besoins en mémoire et les opérations d'écriture entre plusieurs instances. Cela nécessite une répartition adéquate des données et une gestion budgétaire spécifique pour chaque instance concernée. Les répliques ne doivent pas être assimilées à une répartition de la base de données : elles conservent en principe une copie et nécessitent pour cela leur propre mémoire vive.

Une modification de l'architecture peut également s'avérer utile, par exemple la séparation d'un cache tolérant les pertes des données soumises à des exigences plus strictes. Cela permet de choisir les politiques et les capacités de manière indépendante. Toutefois, ni cette séparation, ni une augmentation de la mémoire vive, ni la répartition de la charge ne garantissent l'absence future de pics de persistance, de réplication et d'écriture.

En comparant Limites des fournisseurs Vérifiez si la valeur indiquée correspond à une limite de conteneur, à une limite d'instance ou à une autre limite de base de données. Demandez également quelles métriques et quelles commandes de diagnostic sont accessibles, si les répliques sont incluses dans l'espace de stockage réservé et quel est l'impact d'une promotion sur les ressources disponibles.

Il convient de distinguer Redis Open Source, Redis Software et Redis Cloud. Dans le cas de Redis Software, la limite de base de données documentée s'applique à l'ensemble des shards primaires et répliques ; il n'en découle donc aucune règle correspondante pour une instance Redis OSS isolée. Pour Redis Cloud et les autres offres d'hébergement, vérifie les conditions spécifiques à chaque produit au lieu d'appliquer cette définition sans vérification préalable.