{"id":20946,"date":"2026-08-24T08:35:34","date_gmt":"2026-08-24T06:35:34","guid":{"rendered":"https:\/\/webhosting.de\/redis-lazy-free-speicher-hintergrund-freigeben-optimierung\/"},"modified":"2026-08-24T08:35:34","modified_gmt":"2026-08-24T06:35:34","slug":"redis-lazy-free-memoire-liberation-en-arriere-plan-optimisation","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/redis-lazy-free-speicher-hintergrund-freigeben-optimierung\/","title":{"rendered":"Redis Lazy Free : lib\u00e9rer de la m\u00e9moire efficacement en arri\u00e8re-plan"},"content":{"rendered":"<p><strong>Redis Lazy Free<\/strong> lib\u00e8re de la m\u00e9moire de mani\u00e8re asynchrone via des threads d'arri\u00e8re-plan, afin que les cl\u00e9s volumineuses, lors de leur suppression, expiration ou \u00e9viction, ne <strong>Fil de discussion principal<\/strong> ne pas bloquer. Pour cela, j'utilise de mani\u00e8re cibl\u00e9e UNLINK et les options lazyfree appropri\u00e9es, afin que Redis r\u00e9ponde rapidement aux requ\u00eates et qu'il n'y ait pas de pics de latence avec des structures de donn\u00e9es volumineuses.<\/p>\n\n<h2>Points centraux<\/h2>\n\n<p>La liste suivante r\u00e9sume de mani\u00e8re concise les principaux aspects.<\/p>\n<ul>\n  <li><strong>Asynchrone<\/strong> Valider : suppression imm\u00e9diate de l'espace de cl\u00e9s, lib\u00e9ration de la m\u00e9moire dans le <strong>Contexte<\/strong>.<\/li>\n  <li><strong>UNLINK<\/strong> au lieu de DEL : gestion directement finalis\u00e9e, la validation co\u00fbteuse aura lieu plus tard <strong>d\u00e9l\u00e9gu\u00e9<\/strong>.<\/li>\n  <li><strong>Commande de pr\u00e9cision<\/strong> par configuration : expire, eviction, server et user-<strong>Chemin d'acc\u00e8s<\/strong> pouvant \u00eatre activ\u00e9s s\u00e9par\u00e9ment.<\/li>\n  <li><strong>Suivi<\/strong> \u00c0 noter : identifier les validations asynchrones en attente et celles qui ont \u00e9t\u00e9 effectu\u00e9es, et <strong>\u00e9valuer<\/strong>.<\/li>\n  <li><strong>Fronti\u00e8res<\/strong> \u00e0 savoir : cela ne remplace pas un bon mod\u00e8le de donn\u00e9es, les strat\u00e9gies TTL restent d'actualit\u00e9 <strong>important<\/strong>.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/serverraum-effizienz-8734.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comment fonctionne Lazy Free en interne<\/h2>\n\n<p>Lors de la suppression, je supprime imm\u00e9diatement la cl\u00e9 du <strong>espace de cl\u00e9s<\/strong>, de sorte que les commandes suivantes ne le voient plus et que le thread principal poursuive directement son ex\u00e9cution. La lib\u00e9ration effective des blocs de m\u00e9moire correspondants est assur\u00e9e par un ou plusieurs <strong>Processus d'arri\u00e8re-plan<\/strong>, qui d\u00e9composent progressivement la structure des donn\u00e9es. Cela r\u00e9duit les ralentissements perceptibles pouvant survenir avec des listes, des ensembles, des tables de hachage ou des ZSET de grande taille lorsque la lib\u00e9ration s'effectue de mani\u00e8re synchrone. En particulier lorsque de nombreux clients sont en parall\u00e8le, le temps de r\u00e9ponse reste plus constant, car le thread principal ne passe plus par de longues boucles de lib\u00e9ration. Cette approche s\u00e9pare ainsi la gestion (imm\u00e9diate) de la lib\u00e9ration (ult\u00e9rieure) et maintient ainsi la <strong>Latence<\/strong> plut\u00f4t faible en moyenne. C'est lorsque les applications remplacent ou suppriment fr\u00e9quemment des objets volumineux, ou utilisent des TTL qui provoquent l'expiration simultan\u00e9e de nombreux \u00e9l\u00e9ments, que j'observe l'effet le plus marqu\u00e9, car Lazy Free g\u00e8re cette t\u00e2che avec \u00e9l\u00e9gance <strong>d\u00e9coupl\u00e9<\/strong>.<\/p>\n\n<h2>UNLINK vs DEL dans la pratique<\/h2>\n\n<p>DEL supprime la cl\u00e9 et lib\u00e8re de l'espace dans le <strong>Au premier plan<\/strong> libre, ce qui peut constituer un chemin bloquant de complexit\u00e9 O(N) dans les structures de grande taille. UNLINK supprime imm\u00e9diatement la r\u00e9f\u00e9rence et d\u00e9l\u00e8gue la lib\u00e9ration \u00e0 <strong>lazyfree<\/strong> et met fin \u00e0 la phase administrative sans d\u00e9lai d'attente. Dans les charges de travail productives, j'utilise UNLINK de mani\u00e8re cibl\u00e9e pour les cl\u00e9s volumineuses, tandis que DEL reste suffisant pour les petites valeurs triviales. En combinaison avec les commutateurs `lazyfree`, je peux sp\u00e9cifier que les chemins de suppression c\u00f4t\u00e9 serveur, les expirations ou les \u00e9victions s\u2019ex\u00e9cutent \u00e9galement de mani\u00e8re asynchrone. Cela me permet de r\u00e9duire les pics, de maintenir un d\u00e9bit plus stable et d\u2019obtenir de meilleures <strong>Temps de r\u00e9ponse<\/strong>. Le tableau suivant pr\u00e9sente ces diff\u00e9rences sous une forme synth\u00e9tique afin de faciliter le choix de la commande et de mettre en \u00e9vidence les compromis habituels.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Aspect<\/th>\n      <th>DEL<\/th>\n      <th>UNLINK<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Impact sur le thread<\/td>\n      <td>Lib\u00e9ration dans le thread principal, potentiellement bloquante<\/td>\n      <td>Lib\u00e9ration dans des threads d'arri\u00e8re-plan, non bloquante<\/td>\n    <\/tr>\n    <tr>\n      <td>complexit\u00e9 temporelle<\/td>\n      <td>O(N) pour les grandes structures<\/td>\n      <td>O(1) pour la gestion, validation ult\u00e9rieure<\/td>\n    <\/tr>\n    <tr>\n      <td>Utilisation typique<\/td>\n      <td>Petites cha\u00eenes de caract\u00e8res, op\u00e9rations de suppression peu fr\u00e9quentes<\/td>\n      <td>Grandes listes\/ensembles\/hashes\/ZSET, suppressions fr\u00e9quentes<\/td>\n    <\/tr>\n    <tr>\n      <td>Influence sur la latence<\/td>\n      <td>Des pics sont possibles avec des cl\u00e9s de grande taille<\/td>\n      <td>Des pics moins marqu\u00e9s, une r\u00e9partition plus homog\u00e8ne<\/td>\n    <\/tr>\n    <tr>\n      <td>Interaction avec les options<\/td>\n      <td>Ind\u00e9pendamment des commutateurs \u00ab lazyfree \u00bb<\/td>\n      <td>Compatible avec les options \u00ab lazyfree \u00bb<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/EffizienteSpeicherfreigabe1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Configuration : d\u00e9finir correctement les options de lazyfree<\/h2>\n\n<p>Je contr\u00f4le le fonctionnement \u00e0 l'aide de cinq interrupteurs : <strong>lazyfree-lazy-eviction<\/strong>, lazyfree-lazy-expire, lazyfree-lazy-server-del, lazyfree-lazy-user-del et lazyfree-lazy-user-flush. Dans les charges de travail comportant de nombreux TTL, j\u2019active lazyfree-lazy-expire afin que les cl\u00e9s arrivant \u00e0 expiration n\u2019encombrent pas le <strong>Fil de discussion principal<\/strong> solliciter. Pour le d\u00e9gagement automatique lorsque Maxmemory est atteint, j'utilise lazyfree-lazy-eviction, qui lisse les \u00e9victions et rend les temps de r\u00e9ponse plus pr\u00e9visibles. Pour les scripts ou les op\u00e9rations internes au serveur, lazyfree-lazy-server-del est utile, tandis que lazyfree-lazy-user-del d\u00e9couple mes suppressions manuelles. Avant un d\u00e9ploiement, je v\u00e9rifie toujours la strat\u00e9gie de m\u00e9moire et je me r\u00e9f\u00e8re \u00e0 des ressources d\u2019aide telles que <a href=\"https:\/\/webhosting.de\/fr\/gestion-de-la-memoire-redis-configuration-optimale-de-la-memoire-performances-cache\/\">Gestion de la m\u00e9moire dans Redis<\/a>, afin que les effets sur la fragmentation et l'utilisation des ressources soient clairs. Je configure ainsi les param\u00e8tres de mani\u00e8re cibl\u00e9e et \u00e9vite les effets ind\u00e9sirables dus \u00e0 des r\u00e9glages inappropri\u00e9s <strong>Param\u00e8tres<\/strong>.<\/p>\n\n<h2>Quand j'active Lazy Free<\/h2>\n\n<p>J'active Lazy Free d\u00e8s que certaines cl\u00e9s volumineuses atteignent la <strong>Latence<\/strong> augmenter sensiblement la charge ou provoquer des goulots d'\u00e9tranglement au niveau des pics de suppression. Cette approche fonctionne \u00e0 merveille dans les caches o\u00f9 les remplacements sont fr\u00e9quents ou dans les magasins de session \u00e0 taille dynamique. Les mod\u00e8les de type file d'attente, dans lesquels de longues listes disparaissent par sections, en tirent \u00e9galement un grand b\u00e9n\u00e9fice. M\u00eame pour les charges de travail comportant de nombreuses expirations tout au long de la journ\u00e9e, je privil\u00e9gie la lib\u00e9ration asynchrone afin que l'application <strong>r\u00e9actif<\/strong> reste. Dans des sc\u00e9narios plus statiques avec de petits objets, l'int\u00e9r\u00eat est moindre, mais l'activation ne cause g\u00e9n\u00e9ralement pas de probl\u00e8me tant que les ressources du serveur sont correctement dimensionn\u00e9es. Au final, c'est la mesure sous charge qui est d\u00e9terminante, et non l'intuition, et c'est pr\u00e9cis\u00e9ment l\u00e0 que la surveillance apporte une valeur ajout\u00e9e <strong>Remarques<\/strong>.<\/p>\n\n<h2>Comprendre le monitoring et les m\u00e9triques<\/h2>\n\n<p>Je surveille les indicateurs qui indiquent le nombre d'objets trait\u00e9s de mani\u00e8re asynchrone <strong>Validation<\/strong> en attente et combien ont d\u00e9j\u00e0 \u00e9t\u00e9 trait\u00e9es. Si la file d\u2019attente s\u2019allonge sur une longue p\u00e9riode, cela indique souvent la pr\u00e9sence de cl\u00e9s tr\u00e8s volumineuses ou d\u2019un nombre trop important de chemins de suppression simultan\u00e9s. Je v\u00e9rifie alors s\u2019il est possible d\u2019utiliser UNLINK de mani\u00e8re plus cibl\u00e9e, d\u2019adapter les structures de donn\u00e9es ou de lisser les pics de TTL. En compl\u00e9ment, je corr\u00e8le les percentiles de latence avec les compteurs pour voir si le traitement en arri\u00e8re-plan permet de lisser les temps de r\u00e9ponse. Si la charge sur les threads d\u2019arri\u00e8re-plan reste durablement \u00e9lev\u00e9e, j\u2019\u00e9value les r\u00e9serves de CPU, le comportement de la m\u00e9moire et les cycles de lib\u00e9ration. Cela me permet de d\u00e9tecter rapidement si la lib\u00e9ration paresseuse (Lazy Free) est efficace ou si un <strong>Conception<\/strong>- Ce probl\u00e8me doit \u00eatre r\u00e9solu.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/redis-lazy-free-efficient-bg-6421.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Impact sur les performances et obstacles courants<\/h2>\n\n<p>Lazy Free d\u00e9charge le travail de <strong>Au premier plan<\/strong> en arri\u00e8re-plan, ce qui r\u00e9duit les blocages, mais ne fait pas dispara\u00eetre le temps CPU. Lorsque je supprime de nombreux objets volumineux en succession rapide, le nombre total de lib\u00e9rations peut temporairement augmenter et affecter d\u2019autres t\u00e2ches en arri\u00e8re-plan. C\u2019est pourquoi j\u2019\u00e9chelonne les suppressions en masse, je v\u00e9rifie la fr\u00e9quence des \u00e9v\u00e9nements TTL et j\u2019\u00e9vite les pics de charge gr\u00e2ce \u00e0 une meilleure <strong>Planification<\/strong>. Je pr\u00eate \u00e9galement attention \u00e0 la fragmentation de la m\u00e9moire, qui peut survenir lors de la cr\u00e9ation et de la lib\u00e9ration rapides de grands blocs. Dans de telles situations, il est utile d'examiner attentivement les statistiques de l'allocateur, les options de d\u00e9fragmentation et la taille des structures de donn\u00e9es. Quiconque conna\u00eet ces interactions peut utiliser Lazy Free comme un outil puissant sans effets n\u00e9gatifs <strong>Effets secondaires<\/strong>.<\/p>\n\n<h2>Interaction avec les \u00e9victions et le TTL<\/h2>\n\n<p>Dans Maxmemory, la <strong>Eviction<\/strong> quelles cl\u00e9s sont supprim\u00e9es, et \u00ab lazyfree-lazy-eviction \u00bb d\u00e9termine si la lib\u00e9ration s'effectue de mani\u00e8re asynchrone. Dans les configurations avec une limite de RAM stricte, cela garantit des temps de r\u00e9ponse plus r\u00e9guliers, car la suppression des anciennes donn\u00e9es ne ralentit pas le thread principal. J\u2019harmonise la politique d\u2019\u00e9viction avec la strat\u00e9gie TTL afin que les donn\u00e9es \u00ab chaudes \u00bb soient conserv\u00e9es et que les contenus \u00ab froids \u00bb soient supprim\u00e9s de mani\u00e8re cibl\u00e9e. Quiconque pr\u00e9voit des \u00e9victions a tout int\u00e9r\u00eat \u00e0 disposer d\u2019une vue d\u2019ensemble d\u00e9taill\u00e9e, telle que <a href=\"https:\/\/webhosting.de\/fr\/strategie-deviction-du-cache-dhebergement-redis\/\">Strat\u00e9gies d'expulsion<\/a>, afin d'analyser correctement les comportements et les pics de charge. Associ\u00e9 \u00e0 UNLINK, cela favorise une s\u00e9paration claire : gestion imm\u00e9diate, mise en service ult\u00e9rieure, plus constante <strong>R\u00e9ponses<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/modern_tech_office_night_4721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Lazy Free et persistance (RDB\/AOF)<\/h2>\n\n<p>Les instantan\u00e9s RDB et les r\u00e9\u00e9critures AOF s'ex\u00e9cutent via <strong>Fourche<\/strong> dans des processus distincts, tandis que le thread principal traite les requ\u00eates. Lazy Free n'interf\u00e8re pas avec ce fonctionnement, mais peut modifier la charge de travail si de nombreuses lib\u00e9rations ont lieu en parall\u00e8le. Je surveille donc les temps d\u2019ex\u00e9cution des op\u00e9rations RDB\/AOF et le d\u00e9bit d\u2019E\/S afin d\u2019\u00e9viter tout effet secondaire inattendu. Ceux qui configurent la persistance trouveront dans un fichier compact <a href=\"https:\/\/webhosting.de\/fr\/redis-persistance-rdb-aof-hebergement-serveur-guide\/\">Guide RDB\/AOF<\/a> des indications utiles pour faire le bon choix. Il reste important que je prenne en compte la s\u00e9curit\u00e9 des donn\u00e9es, le d\u00e9bit d'\u00e9criture et la taille des ensembles de donn\u00e9es avant de valider la mise en production de mani\u00e8re agressive <strong>d\u00e9synchronise<\/strong>.<\/p>\n\n<h2>Guide pratique : liste de contr\u00f4le pour la migration et le d\u00e9ploiement<\/h2>\n\n<p>Je lance une ex\u00e9cution dans un environnement de test avec des donn\u00e9es repr\u00e9sentatives <strong>Donn\u00e9es<\/strong> et j'active d'abord \u00ab lazyfree-lazy-user-del \u00bb afin de d\u00e9coupler les chemins de suppression manuels. Ensuite, je mesure les centiles de latence, le d\u00e9bit et l'utilisation du processeur avant d'activer les commutateurs \u00ab expire \u00bb et \u00ab eviction \u00bb. \u00c0 chaque \u00e9tape, je v\u00e9rifie les compteurs de validations en attente et je les compare \u00e0 la charge des requ\u00eates et \u00e0 l\u2019\u00e9volution de la m\u00e9moire. Si les indicateurs restent stables, j\u2019\u00e9tends progressivement le d\u00e9ploiement \u00e0 d\u2019autres n\u0153uds. En cas de probl\u00e8mes, je d\u00e9sactive \u00e0 nouveau les commutateurs, j\u2019adapte les structures de donn\u00e9es et j\u2019att\u00e9nue les vagues de suppressions en utilisant des lots plus petits. Cela me permet de rester op\u00e9rationnel, de minimiser les risques et d\u2019obtenir des r\u00e9sultats fiables <strong>Gains<\/strong> en termes de temps de r\u00e9action.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/redis_lazyfree_schreibtisch_3851.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comportement de la m\u00e9moire et fragmentation<\/h2>\n\n<p>La validation asynchrone all\u00e8ge la charge du <strong>Fil de discussion principal<\/strong>, mais l'allocateur doit effectivement lib\u00e9rer ou r\u00e9utiliser ces blocs. Je surveille donc le rapport entre la m\u00e9moire occup\u00e9e et la m\u00e9moire r\u00e9serv\u00e9e par l\u2019allocateur afin de d\u00e9tecter la fragmentation \u00e0 temps. Si de nombreuses structures volumineuses et \u00e9ph\u00e9m\u00e8res apparaissent, j\u2019\u00e9tale les lib\u00e9rations dans le temps afin que l\u2019allocateur puisse fonctionner de mani\u00e8re plus r\u00e9guli\u00e8re. De plus, je v\u00e9rifie si les tailles des conteneurs correspondent aux mod\u00e8les d\u2019utilisation, par exemple en r\u00e9duisant la taille des hachages ou des ZSET. Dans certains cas, la d\u00e9fragmentation s\u2019av\u00e8re utile, mais je la consid\u00e8re comme un compl\u00e9ment et non comme la premi\u00e8re <strong>Mesure<\/strong>.<\/p>\n\n<h2>Exemples et r\u00e9f\u00e9rences tir\u00e9s de la pratique<\/h2>\n\n<p>Dans les applications utilisant des flux d'\u00e9v\u00e9nements et des caches bas\u00e9s sur la dur\u00e9e de vie (TTL), les pics de latence diminuent souvent consid\u00e9rablement d\u00e8s que les commandes UNLINK et les <strong>lazyfree<\/strong>-Les commutateurs sont actifs. Le r\u00e9sultat est particuli\u00e8rement clair lorsque les cl\u00e9s volumineuses sont remplac\u00e9es r\u00e9guli\u00e8rement, car la charge administrative est imm\u00e9diatement \u00e9limin\u00e9e. Les mesures r\u00e9alis\u00e9es sous une charge synth\u00e9tique montrent que le d\u00e9bit reste plus constant, tandis que les valeurs extr\u00eames au niveau des temps de r\u00e9ponse apparaissent moins fr\u00e9quemment. En cas de forte fluctuation des volumes de donn\u00e9es, on observe un profil plus stable, ce qui r\u00e9duit les valeurs aberrantes et am\u00e9liore sensiblement l'exp\u00e9rience utilisateur. J'\u00e9value toujours ces effets conjointement avec les s\u00e9ries chronologiques du CPU et de la m\u00e9moire, afin d'\u00e9viter toute <strong>optimisation apparente<\/strong> se pose.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/speicherfreigabe-serverraum-8347.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Compatibilit\u00e9, param\u00e8tres par d\u00e9faut et activation s\u00e9curis\u00e9e<\/h2>\n<p>Dans la pratique, je pars du principe que les commutateurs \u00ab lazyfree \u00bb <em>d\u00e9sactiv\u00e9 par d\u00e9faut<\/em> et je les active de mani\u00e8re cibl\u00e9e pour chaque chemin. Cela \u00e9vite les mauvaises surprises lors de la mise \u00e0 niveau et permet de mesurer les effets. Je v\u00e9rifie \u00e9galement la version de Redis, car certains d\u00e9tails tels que les variantes FLUSH* (<code>FLUSHDB ASYNC<\/code>, <code>FLUSHALL ASYNC<\/code>) et que les chemins de suppression c\u00f4t\u00e9 serveur ne sont devenus facilement contr\u00f4lables qu\u2019\u00e0 partir de versions ult\u00e9rieures. Pour les \u00e9quipes soumises \u00e0 des contr\u00f4les de changement stricts, je documente les valeurs par d\u00e9faut, l\u2019\u00e9tat cible (quels chemins doivent \u00eatre asynchrones ?) et les crit\u00e8res d\u2019acceptation (par exemple, latence P99 inf\u00e9rieure \u00e0 la valeur cible, pas d\u2019augmentation persistante <em>objets en attente<\/em>), avant de passer en direct.<\/p>\n\n<h2>R\u00e9plication, cluster et basculement<\/h2>\n<p>Dans les configurations r\u00e9pliqu\u00e9es et les topologies CLUSTER, je veille \u00e0 ce que Lazy Free utilise la <strong>S\u00e9mantique<\/strong> inchang\u00e9 : les cl\u00e9s disparaissent imm\u00e9diatement de l'espace de cl\u00e9s, quel que soit le moment o\u00f9 la m\u00e9moire est effectivement lib\u00e9r\u00e9e. Ceci est important pour les applications qui s'attendent \u00e0 ce qu'une cl\u00e9 soit \u201e supprim\u00e9e \u201c peu apr\u00e8s une op\u00e9ration de suppression. Sur les r\u00e9pliques, j\u2019observe une charge importante lorsque de nombreuses lib\u00e9rations ont lieu en parall\u00e8le (par exemple apr\u00e8s des suppressions en masse sur le serveur principal). J\u2019\u00e9vite les vagues de suppressions importantes juste avant un basculement planifi\u00e9, afin que <strong>travail de fond<\/strong> ne s'\u00e9tende pas inutilement dans la phase de basculement. En cas de resynchronisation compl\u00e8te et de reconstruction des donn\u00e9es, il est avantageux que le n\u0153ud puisse lib\u00e9rer l'ancien ensemble de donn\u00e9es de mani\u00e8re asynchrone lors de son vidage : cela permet de soulager le thread pendant que la r\u00e9plication prend le relais.<\/p>\n\n<h2>Scripts, transactions et pipelines<\/h2>\n<p>Dans les scripts Lua et les transactions MULTI\/EXEC, j'utilise syst\u00e9matiquement <code>UNLINK<\/code>, lorsque des cl\u00e9s volumineuses sont supprim\u00e9es. Cela s\u2019av\u00e8re particuli\u00e8rement utile lorsque des scripts ex\u00e9cutent p\u00e9riodiquement des op\u00e9rations de nettoyage. Pour les suppressions en masse, je combine <code>SCAN<\/code>it\u00e9ration bas\u00e9e sur avec <code>UNLINK<\/code> dans <strong>lots<\/strong> et le pipeline, afin de limiter \u00e0 la fois la surcharge du r\u00e9seau et les pics de latence :<\/p>\n<pre><code>Exemple # : suppression progressive et asynchrone via un pipeline\nSCAN 0 MATCH session:* COUNT 1000\n# ... Collecte des cl\u00e9s et envoi par pipeline via UNLINK par lots de 200\nUNLINK session:... session:... ...<\/code><\/pre>\n<p>J'\u00e9vite <code>KEYS<\/code> pour les suppressions types en production ; <code>SCAN<\/code> Des valeurs COUNT mod\u00e9r\u00e9es et un espacement temporel permettent au thread principal de rester r\u00e9actif. De plus, je limite le parall\u00e9lisme c\u00f4t\u00e9 client afin d'\u00e9viter que la file d'attente des validations asynchrones ne s'allonge de mani\u00e8re incontr\u00f4l\u00e9e.<\/p>\n\n<h2>Indicateurs concrets et diagnostic<\/h2>\n<p>Pour une analyse rigoureuse, je combine les perspectives de la latence et de la m\u00e9moire :<\/p>\n<ul>\n  <li><strong>lazyfree_pending_objects<\/strong>: Indicateur cl\u00e9 de la file d'attente des lib\u00e9rations asynchrones. Une augmentation persistante indique que les objets sont trop volumineux ou que les vagues de suppression sont trop agressives.<\/li>\n  <li><strong>expired_keys<\/strong> et <strong>evicted_keys<\/strong>: Des taux \u00e9lev\u00e9s indiquent une pression sur TTL ou Maxmemory ; les commutateurs \u00ab lazyfree \u00bb permettent de d\u00e9coupler les chemins.<\/li>\n  <li><strong>used_memory_rss<\/strong> et <strong>mem_fragmentation_ratio<\/strong>: Montrer si l'allocateur arrive \u00e0 suivre et quel est le degr\u00e9 de fragmentation.<\/li>\n  <li><strong>op\u00e9rations instantan\u00e9es par seconde<\/strong> et les percentiles de latence : v\u00e9rifier si le d\u00e9bit reste stable et si les pics s'att\u00e9nuent.<\/li>\n<\/ul>\n<p>Pour analyser les causes, je me base sur des s\u00e9ries chronologiques : corr\u00e9ler <em>objets en attente<\/em> En cas de pics TTL, d'\u00e9victions ou de suppressions par lots, j'interviens au niveau de l'\u00e9galisation ou de la taille des lots. Si la latence reste stable mais que l'utilisation du RSS augmente, je v\u00e9rifie le comportement de l'allocateur et la d\u00e9fragmentation.<\/p>\n\n<h2>Allocateur, d\u00e9fragmentation et gestion de la m\u00e9moire<\/h2>\n<p>Lazy Free permet de lever les blocages, mais ne remplace pas une approche rigoureuse <strong>Mod\u00e8le de m\u00e9moire<\/strong>. Je veille \u00e0 la coh\u00e9rence des structures de donn\u00e9es (par exemple, des hachages plats plut\u00f4t que des champs imbriqu\u00e9s rarement utilis\u00e9s), j'\u00e9vite les tailles d'objets explosives et je fractionne les charges utiles volumineuses lorsque le mod\u00e8le d'acc\u00e8s le permet. Dans les environnements o\u00f9 les volumes de donn\u00e9es fluctuent fortement, la d\u00e9fragmentation est utile \u2013 \u00e0 condition d\u2019\u00eatre correctement dos\u00e9e. Je ne l\u2019active que lorsque la fragmentation ralentit de mani\u00e8re r\u00e9ellement mesurable, et je v\u00e9rifie si elle entre en concurrence avec les t\u00e2ches \u00ab lazy free \u00bb. La cl\u00e9 r\u00e9side dans l\u2019\u00e9quilibre : il ne faut pas tout faire fonctionner de mani\u00e8re asynchrone et fragment\u00e9e \u00e0 la fois, mais plut\u00f4t avec <strong>Points de mesure<\/strong> contr\u00f4ler.<\/p>\n\n<h2>Cas limites et s\u00e9mantique<\/h2>\n<p>Il est important de bien distinguer la visibilit\u00e9 du partage de stockage : selon <code>UNLINK<\/code> la cl\u00e9 devient imm\u00e9diatement invisible, et l\u2019espace m\u00e9moire est lib\u00e9r\u00e9 ult\u00e9rieurement. Dans les configurations o\u00f9 la m\u00e9moire maximale (MaxMemory) est tr\u00e8s limit\u00e9e, cela peut signifier que l\u2019insertion de nouvelles donn\u00e9es subit temporairement davantage d\u2019\u00e9victions, jusqu\u2019\u00e0 ce que la lib\u00e9ration de m\u00e9moire ait rattrap\u00e9 son retard. Je rem\u00e9die \u00e0 cela en synchronisant des vagues de suppression, en limitant la taille des nouvelles insertions ou en asynchronisant les \u00e9victions afin de ne pas encombrer le thread principal. Je veille \u00e9galement \u00e0 ce que certaines cl\u00e9s individuelles extr\u00eamement volumineuses (<em>Cl\u00e9s \u00ab \u00e9l\u00e9phant \u00bb<\/em>) peuvent \u00e0 eux seuls dominer la file d\u2019attente d\u2019arri\u00e8re-plan \u2013 on y trouve souvent la <strong>D\u00e9composition d'objets<\/strong> la meilleure solution.<\/p>\n\n<h2>Directives d'exploitation et strat\u00e9gie de restauration<\/h2>\n<p>Pour les environnements de travail, je formule quelques lignes directrices simples :<\/p>\n<ul>\n  <li><strong>Fonctionnalit\u00e9s<\/strong>: activer les commutateurs lazyfree un par un, les documenter et valider leur bon fonctionnement \u00e0 l'aide de m\u00e9triques.<\/li>\n  <li><strong>Limites de taux<\/strong>: D\u00e9finir la taille et la fr\u00e9quence des lots afin d'\u00e9viter qu'une vague de validations ne submerge le syst\u00e8me.<\/li>\n  <li><strong>Retour en arri\u00e8re<\/strong>: Si la tendance \u00e0 la hausse se poursuit <em>objets en attente<\/em> ou, en cas de pics de latence, d\u00e9sactiver de mani\u00e8re cibl\u00e9e les commutateurs activ\u00e9s en dernier.<\/li>\n  <li><strong>Phases de chargement<\/strong>: Planifier les activations en dehors des plages horaires sensibles en termes de trafic et les suivre \u00e0 l'aide de tableaux de bord pr\u00e9configur\u00e9s.<\/li>\n<\/ul>\n<p>Gr\u00e2ce \u00e0 des r\u00e8gles de fonctionnement claires, Lazy Free reste un outil pr\u00e9visible, et non une \u00ab bo\u00eete noire \u00bb qui r\u00e9serve parfois des surprises.<\/p>\n\n<h2>Exemples concrets : un rangement s\u00e9lectif et planifiable<\/h2>\n<p>Je choisis d\u00e9lib\u00e9r\u00e9ment entre trois modes de suppression, en fonction de l'urgence et de la taille :<\/p>\n<ul>\n  <li><strong>Tout de suite, petit<\/strong>: <code>DEL<\/code> pour les valeurs infimes, rarement effac\u00e9es \u2013 r\u00e9duire la surcharge.<\/li>\n  <li><strong>Tout de suite, en grand<\/strong>: <code>UNLINK<\/code> pour les cl\u00e9s volumineuses : mettre fin imm\u00e9diatement \u00e0 leur visibilit\u00e9, externaliser leur partage.<\/li>\n  <li><strong>Pr\u00e9vu, en grande quantit\u00e9<\/strong>: <code>SCAN<\/code> + <code>UNLINK<\/code> par lots \u2013 de mani\u00e8re d\u00e9terministe, compatible avec les pipelines, avec m\u00e9canisme de recul en cas de surcharge.<\/li>\n<\/ul>\n<p>Dans le cas des caches \u00e0 forte charge TTL, j'utilise en outre d\u00e9lib\u00e9r\u00e9ment <em>Jitter<\/em> un (r\u00e9partir l\u00e9g\u00e8rement les d\u00e9lais d'expiration) afin d'\u00e9viter que les expirations ne d\u00e9clenchent des sous-ensembles entiers en une seule seconde. Cela r\u00e9duit le risque de lib\u00e9rations par vagues, m\u00eame si les chemins d'expiration sont asynchrones.<\/p>\n\n<h2>En bref<\/h2>\n\n<p><strong>Redis Lazy Free<\/strong> s\u00e9pare la gestion et la validation, lib\u00e8re le thread principal et att\u00e9nue les pics de latence li\u00e9s aux structures de donn\u00e9es volumineuses. J'utilise UNLINK pour les cl\u00e9s lourdes, j'active les chemins d'expiration et d'\u00e9viction de mani\u00e8re asynchrone et je surveille attentivement les compteurs pertinents. Avec une configuration r\u00e9fl\u00e9chie, un d\u00e9ploiement prudent et des points de mesure clairs, cette technique garantit des temps de r\u00e9ponse constants sous charge. Il subsiste toutefois des limites : elle ne remplace pas un bon mod\u00e8le de donn\u00e9es, des strat\u00e9gies TTL bien con\u00e7ues ni des tailles de conteneurs adapt\u00e9es. Ceux qui tiennent compte de ces points tireront davantage parti de Redis de mani\u00e8re fiable. <strong>Performance<\/strong> sans risquer de surprises dans la gestion quotidienne.<\/p>","protected":false},"excerpt":{"rendered":"<p>Redis Lazy Free r\u00e9duit les blocages et am\u00e9liore les performances gr\u00e2ce \u00e0 une lib\u00e9ration asynchrone de la m\u00e9moire en arri\u00e8re-plan.<\/p>","protected":false},"author":1,"featured_media":20939,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-20946","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"129","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Redis Lazy Free","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20939","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20946","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/comments?post=20946"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20946\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/20939"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=20946"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=20946"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=20946"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}