Interpréter correctement et optimiser le taux de fragmentation de la mémoire Redis

Fragmentation de Redis détermine la quantité de mémoire vive perdue entre le RSS alloué par le système d'exploitation et les données Redis réellement utilisées, et comment éviter la latence, l'utilisation de la mémoire d'échange et les pannes. Je vais expliquer le Taux de fragmentation de la mémoire Redis orienté vers la pratique, indique des valeurs limites pertinentes et propose des mesures claires en matière d'optimisation, de surveillance et de modélisation des données.

Points centraux

• Définition: Lire correctement le rapport entre used_memory_rss et used_memory.
• Valeurs limites: Intervenir à partir de 1,5 ; vérifier immédiatement en dessous de 1,0.
• Causes: Tailles d'objets variables, vagues d'effacement, durées d'exécution longues.
• Mesures: Défragmentation active, établissement d'un budget, rationalisation du modèle de données.
• Suivi: Définir des alertes sur les valeurs de Ratio et d'Allocator.

Que signifie exactement « mem_fragmentation_ratio » ?

J'utilise la valeur caractéristique mem_fragmentation_ratio, pour voir le rapport entre le RSS et la consommation de données. Le quotient de used_memory_rss divisé par used_memory montre à quel point Redis exploite pleinement la mémoire vive. Les valeurs proches de 1,0 indiquent une efficace Taux d'utilisation avec peu d'espaces vides. Des valeurs élevées indiquent qu'il existe de nombreux espaces libres dans le processus que l'allocateur ne peut pas réutiliser. Je n'évalue jamais cette valeur isolément, mais en tenant compte de la taille, de la charge de travail et Allocateur-indicateurs.

Bien replacer les valeurs indicatives dans leur contexte

Je classe le Ratio en zones fixes, afin que les décisions restent reproductibles. Des légers excès autour de 1,1 me semblent normaux Overhead. À partir d'environ 1,5, je prévois des mesures, car sinon la mémoire vive (RAM) se dégrade ou le système se rapproche des limites OOM. En dessous de 1,0, je réagis immédiatement, car cela indique que Swap . Le tableau suivant récapitule les domaines et les actions types.

Ratio	Signification	mesure immédiate
Inférieur à 1,0	Swap- Risque, forte latence	Vérifier la RAM/la mémoire maximale, réduire le volume de données
1,0–1,1	En bonne santé avec un léger surcoût	Surveiller la situation, rien d'urgent
1,1–1,5	Normal, fragmentation modérée	Observer les tendances, noter les causes
Plus de 1,5	Augmenté, gaspillage de mémoire	Active Defrag, vérifier le modèle, tester la purge
Plus de 2,0	Haute, contraintes de capacité	Défragmentation intensive, envisager un redémarrage

Comment la fragmentation se produit-elle ?

Je constate une forte Fragmentation surtout en cas de nombreuses séries d'écritures et de suppressions. L'allocateur, généralement jemalloc, crée des zones de mémoire dans les arènes qui ne sont pas toujours recyclées de manière optimale. Lorsque les clés rétrécissent, grossissent ou disparaissent complètement, elles laissent des espaces vides. Les nouveaux objets ne s’adaptent souvent pas à ces espaces, ce qui fait que le RSS reste plus élevé que les données réelles. Avec des durées d’exécution longues, ces Lacunes, jusqu'à ce que le ratio augmente sensiblement.

Symptômes et risques liés à l'utilisation

En hausse Latence, ce sont les erreurs OOM soudaines et l'augmentation de la valeur RSS qui me sautent en premier à l'œil. Même si la valeur used_memory reste modérée, l'instance peut RAM-atteint ses limites. Lorsque le système commence alors à déporter des pages, les temps de réponse montent en flèche. Les services réagissent lentement et les délais d'expiration se multiplient, ce qui perturbe le bon fonctionnement des applications. C'est pourquoi je veille toujours à ce que Swap- Les indicateurs en un coup d'œil.

Lire INFO MEMORY en toute sécurité

Sur INFO En ce qui concerne la mémoire, je vérifie les valeurs de `used_memory`, `used_memory_rss` et le `mem_fragmentation_ratio`. Je prête également attention à ratio_allocateur_fragmentation et allocator_rss_ratio, pour détecter les écarts entre le tas et le système d'exploitation. Un mem_fragmentation_ratio élevé associé à une valeur d'allocator normale m'indique que le système d'exploitation ne récupère pas correctement les pages. En revanche, des valeurs d'allocator élevées indiquent des problèmes internes Heap- vers la fragmentation. Je recense ces combinaisons afin de mettre en évidence les tendances et de garantir que les mesures prises soient ciblées.

La défragmentation active en pratique

J'active la Active Défragmentation lorsque le ratio augmente ou que les charges de travail varient fortement. Redis réorganise alors les objets et les regroupe de manière plus compacte afin que le système d’exploitation puisse libérer des pages. Je teste le contrôle par étapes afin de maintenir la charge CPU à un niveau raisonnable. Pour commencer, j’utilise des paramètres éprouvés, puis je procède à des ajustements fins. Cet article m’offre une bonne introduction à ce sujet Défragmentation active-Article.

CONFIG SET activedefrag yes
CONFIG SET active-defrag-ignore-bytes 100mb
CONFIG SET active-defrag-threshold-lower 10
CONFIG SET active-defrag-threshold-upper 100
CONFIG SET active-defrag-cycle-min 5
CONFIG SET active-defrag-cycle-max 75

Je mets Valeurs limites de manière à ce que Defrag se lance uniquement en cas de réelle nécessité. Les valeurs « Cycle » limitent la charge du processeur afin que les pics de charge ne soient pas affectés. Après avoir effectué les ajustements, j'observe les indicateurs pendant plusieurs heures. Ce n'est que lorsque le ratio, la latence et l'utilisation du processeur semblent cohérents que j'applique les Valeurs permanent.

Régler les paramètres avec précision, sans effets indésirables

Je relance la Valeurs seuils uniquement par petites étapes, afin d'éviter les effets secondaires. Un cycle trop agressif réduit certes la fragmentation, mais met à rude épreuve la CPU perceptible. En cas de charge quotidienne, je reporte les tests à des moments plus calmes afin que les effets restent facilement mesurables. Il est utile de procéder à une comparaison avant et après l'ajustement avec une configuration identique Charge de travail. C'est ainsi que je peux déterminer si la défragmentation réduit réellement le ratio ou si elle ne fait que déplacer la charge.

Utiliser « Lazy Free » de manière réfléchie

J'utilise Lazy Free, lorsque de nombreuses clés volumineuses disparaissent ou sont renommées simultanément. Au lieu de bloquer la synchronisation, UNLINK, FLUSHDB ASYNC et FLUSHALL ASYNC Libération de mémoire en arrière-plan. Cela réduit les pics de latence, mais peut accroître la fragmentation à court terme, car les pages sont d'abord recyclées de manière asynchrone. Je contrôle ce comportement via les paramètres lazyfree (par exemple lazyfree-lazy-eviction, lazyfree-lazy-server-del), je teste les impacts sur le CPU et je surveille lazyfree_pending_objects dans la mémoire INFO. S'il reste beaucoup d'objets en attente, j'augmente légèrement les budgets de défragmentation ou j'étale les vagues de suppression afin que le tas ne se fragmente pas en de nombreux petits espaces vides.

Planifier un nettoyage manuel et un redémarrage

Si le Ratio explose, je vais prendre des mesures sévères Levier. Avec MEMORY PURGE, je demande à l'allocateur de restituer les pages inutilisées au système d'exploitation. Grâce à DEBUG MALLOC-STATS, j'obtiens des informations plus détaillées sur la Arènes et les tendances d'allocation. Si le ratio reste supérieur à 2,0, je prévois un redémarrage coordonné après un snapshot ou une synchronisation AOF. Cette étape nécessite la structure de stockage Retournez-y et abonnez-vous immédiatement au flux RSS.

Gérer judicieusement le budget « Maxmemory »

Je prévois maxmemory jamais jusqu’à la limite physique de la mémoire vive. En règle générale, je réserve environ 60 à 65 % pour les données, 5 à 10 % comme tampon de fragmentation et 10 à 20 % pour Copie à l'écriture. Le reste est réservé au système d'exploitation, aux agents et au fonctionnement. Cette répartition empêche OOM- des surprises et permet à Defrag de respirer. Je trouve ici un guide pratique : Configurer la mémoire de manière optimale.

Persistance, RDB/AOF et « copy-on-write »

Je tiens toujours compte des effets de Persistance sur la fragmentation. Lors des opérations BGSAVE et des réécritures AOF, la technique « copy-on-write » duplique les pages modifiées. Au cours de cette phase, la valeur RSS augmente, bien que la mémoire utilisée (used_memory) n'augmente pratiquement pas. Je prévois donc d'effectuer les réécritures complètes pendant des plages horaires calmes, je vérifie auto-aof-rewrite-percentage et -min-size et je réserve de la marge pour le CoW. Les pics d'écriture importants lors d'une réécriture peuvent rapidement fragmenter les arènes ; une défragmentation ultérieure rétablit le RSS. Sur les répliques, je surveille de très près la première resynchronisation complète : les importations massives associées au CoW sont un facteur classique à l'origine de pics à court terme mem_fragmentation_ratio. Si la valeur reste élevée une fois l'opération terminée, je lance une brève défragmentation ou je teste VIDAGE DE LA MÉMOIRE.

Inférieur à 1,0 : le swap freine la croissance

Si le ratio passe en dessous de 1,0, le système freine Swap le système. Chaque cycle de « page fault » prend un temps non négligeable et fait capoter les objectifs de latence. Je vérifie alors l'état de la RAM, puis je réduis maxmemory ou réduire le volume de données dans l'instance. Je vérifie également les paramètres système tels que vm.swappiness, afin que le noyau ait moins souvent à externalise. L'objectif reste de maintenir strictement l'instance en mémoire vive et d'éviter les opérations de réactivation de pages.

Prendre en compte les paramètres des conteneurs et du noyau

Dans les conteneurs, je mesure toujours la fragmentation dans le contexte de cgroups-Limites. Je compare RSS aux limites de mémoire et je définis vm.overcommit_memory=1, afin que Redis ne tombe pas en panne à cause d'un surengagement. Pages transparentes volumineuses Je les désactive, car elles alourdissent les flux RSS et compliquent la défragmentation. Je constate également oom_kill- Je surveille les compteurs du cgroup et réagis rapidement lorsque le noyau commence à être sollicité. Dans Kubernetes, je veille à définir des demandes et des limites réalistes et je réserve une marge de manœuvre par pod afin que BGSAVE et les réécritures n'atteignent pas involontairement leurs limites. Important : l’isolation des conteneurs ne modifie en rien la logique interne du tas – la défragmentation, le « Lazy Free » et la mise à jour des modèles restent les outils essentiels pour lutter contre Fragmentation.

Optimiser le modèle de données et les indicateurs clés

Je tiens objets petites et uniformes, afin que l'allocateur soit moins dispersé. Je divise les très grandes listes, les ensembles ou les tables de hachage en plusieurs clés plus petites. Au lieu d'énormes chaînes JSON, j'utilise des formats compacts Types de données comme les hachages comportant des champs qui changent moins souvent. Pour les sessions, les compteurs et les caches, je standardise les tailles afin que les allocations restent plus prévisibles. Cela me permet de réduire la Fragmentation, avant de modifier les paramètres.

Politique d'expulsion et déroulement de la procédure

Je choisis la Politique d'expulsion en fonction de la charge de travail. Lorsque les quantités de clés varient fortement, les variantes LRU/LFU répartissent les suppressions de manière plus homogène et évitent les pics. J'évite les expirations massives à l'heure pile et j'étale les TTL afin que l'Active-Expire ne supprime pas des milliers d'objets en même temps. Des paramètres tels que hz et active-expire-effort Je ne procède qu'à des ajustements prudents afin de ne pas surcharger le processeur. Un schéma d'exécution régulier génère des allocations prévisibles – et c'est précisément ce qui permet de maintenir la mem_fragmentation_ratio plat.

Redis Cluster et le sharding

En matière de croissance, je mise sur Sharding ou en clusters, car des tas plus petits par shard génèrent moins de « trous » à long terme. Lors du rééquilibrage, je planifie les fenêtres de migration de manière à ce que les pics d'écriture et les réécritures ne se chevauchent pas. Les vagues importantes de MIGRATE peuvent temporairement augmenter le RSS sur les nœuds cibles ; je surveille les valeurs de l'allocateur pendant ce temps et j'active la défragmentation après le déplacement. Sur les répliques, je tiens compte de l'espace mémoire supplémentaire nécessaire pour les backlogs et les tampons de réplique – cela est également pris en compte dans le Maxmemory- la budgétisation.

Approfondir l'observabilité : MEMORY STATS et latence

• J'utilise STATISTIQUES DE MÉMOIRE, afin de visualiser la surcharge, la part des ensembles de données et les détails relatifs à la fragmentation. Cela permet de distinguer la fragmentation du tas de celle liée au système d'exploitation.
• Avec MEMORY DOCTOR je reçois des indications me permettant de savoir si le modèle de données, la défragmentation ou la purge sont les solutions les plus efficaces à court terme.
• Je corrèle latence- des indicateurs (par exemple, « latency doctor ») avec des phases de défragmentation et de réécriture, afin d'identifier les effets secondaires.
• Le SLOWLOG me montre si les commandes sont désynchronisées en raison d'opérations de mémoire – en particulier les commandes DEL, UNLINK et les longues séries HSET/HGET.

Guide pratique d'exploitation

• Référence : sauvegarder la mémoire INFO, le ratio, les valeurs de l'allocateur, documenter le jeu de données et la surcharge.
• Budget : définir « maxmemory » sur une valeur réaliste de 60 à 65 % de données, 5 à 10 % de fragmentation et 10 à 20 % de CoW.
• Défragmentation : activer « activedefrag », augmenter progressivement la valeur, mesurer les effets sur plusieurs heures.
• Modèle de données : diviser les objets volumineux, éviter les blocs JSON, normaliser les tailles.
• Expiration : répartir les TTL, choisir une politique d'éviction adaptée, éviter les vagues de suppression.
• Persistance : planifier les réécritures, prévoir une marge de manœuvre, vérifier la défragmentation une fois l'opération terminée.
• Purge/Redémarrage : si le rapport est supérieur à 2,0, tenter une purge ; sinon, redémarrer de manière ordonnée.
• Conteneurs : THP désactivé, Overcommit activé, limites/requêtes avec marge ; limiter strictement l'espace d'échange.
• Surveillance : alertes à 1,5/2,0/moins de 1,0 ; analyser les tendances par déploiement et par lot.

Exemple : de 1,8 à 1,2 en 24 heures

Sur une instance de 64 Go (maxmemory 40 Go), la mem_fragmentation_ratio à 1,8, alors que « used_memory » se situait entre 28 et 30 Go. J'ai d'abord activedefrag activé (cycle-min 5, cycle-max 50) et déplacé la réécriture nocturne des fichiers AOF vers une plage horaire moins chargée. J’ai ensuite rééquilibré les TTL qui expiraient jusqu’alors toutes les heures, et remplacé plusieurs valeurs JSON volumineuses par des hachages aux tailles de champs stables. Une opération ciblée VIDAGE DE LA MÉMOIRE Après le pic de charge, RSS a également libéré de la mémoire. Résultat : au bout de 24 heures, le ratio s'est stabilisé à environ 1,2, les pics de latence ont disparu et la mémoire vive de l'hôte a gagné environ 8 Go d'espace libre. Le Allocateur- Valeurs confirmées : fragmentation du tas réduite, RSS du système d'exploitation dans les normes.

Comparer judicieusement les environnements d'hébergement

Je veille à ce qu'il y ait suffisamment de RAM, une charge CPU prévisible et des valeurs d'E/S stables lorsque j'héberge Redis chez un hébergeur. Des ressources dédiées et des mises à niveau flexibles permettent d'éviter les goulots d'étranglement en cas de croissance. Il est judicieux de disposer d'indicateurs clairs concernant le RSS, Swap et des limites, afin de détecter rapidement les goulots d'étranglement. Pour les configurations allemandes, je recommande webhoster.de, car les ressources y sont disponibles de manière fiable. Une plateforme bien conçue permet de maintenir le FragmentationValeur dans les limites normales.

Résumé

Je lis le Redis Le taux de fragmentation de la mémoire comme signal d'alerte précoce pour les pertes de RAM et la latence. Les valeurs proches de 1,0 sont normales ; à partir de 1,5, je lance une défragmentation et des ajustements de modèle ; en dessous de 1,0, j'arrête Swap immédiatement. Grâce à la défragmentation active, à une gestion intelligente de la mémoire (Maxmemory) et à des structures de données compactes, je maintiens la Mémoire- Efficacité élevée. Une surveillance continue permet de détecter des tendances et d'éviter les interventions ponctuelles précipitées. L'instance conserve ainsi sa réactivité, et le Ratio évolue là où est sa place.