{"id":20116,"date":"2026-07-29T08:34:12","date_gmt":"2026-07-29T06:34:12","guid":{"rendered":"https:\/\/webhosting.de\/redis-memory-management-speicher-optimal-konfigurieren-performance-cache\/"},"modified":"2026-07-29T08:34:12","modified_gmt":"2026-07-29T06:34:12","slug":"gestion-de-la-memoire-redis-configuration-optimale-de-la-memoire-performances-cache","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/redis-memory-management-speicher-optimal-konfigurieren-performance-cache\/","title":{"rendered":"Gestion de la m\u00e9moire dans Redis \u2013 Configurer la m\u00e9moire de mani\u00e8re optimale pour des performances maximales"},"content":{"rendered":"<p>Je configure la m\u00e9moire Redis de mani\u00e8re \u00e0 ce qu'elle reste pr\u00e9visible : des limites claires, des politiques d'\u00e9viction adapt\u00e9es, des TTL bien d\u00e9finis et une surveillance continue permettent d'\u00e9viter les pics de latence et les pertes de donn\u00e9es. Ce guide pr\u00e9sente des param\u00e8tres concrets pour <strong>maxmemory<\/strong>, l'\u00e9viction, la d\u00e9fragmentation et les structures de donn\u00e9es, afin que Redis fonctionne de mani\u00e8re fiable et rapide en cas de charge \u00e9lev\u00e9e.<\/p>\n\n<h2>Points centraux<\/h2>\n<ul>\n  <li><strong>maxmemory<\/strong> effectuer un calcul r\u00e9aliste et le retenir comme limite de s\u00e9curit\u00e9<\/li>\n  <li><strong>Politique d'expulsion<\/strong> choisir en fonction du motif du cache<\/li>\n  <li><strong>Conception TTL<\/strong> Combiner le \u00ab jitter \u00bb avec les \u00ab stampedes \u00bb<\/li>\n  <li><strong>D\u00e9fragmentation<\/strong> Activer et v\u00e9rifier les indicateurs cl\u00e9s<\/li>\n  <li><strong>Suivi<\/strong> avec des alertes \u00e0 partir d'environ 75 % de charge (%)<\/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\/07\/redis-speicher-management-6823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comprendre le stockage Redis : privil\u00e9gier la planification plut\u00f4t que l'intuition<\/h2>\n<p>Je pr\u00e9vois toujours un budget de stockage qui tient compte des donn\u00e9es, <strong>Overhead<\/strong> et la r\u00e9serve. Outre les cl\u00e9s et les valeurs, la r\u00e9plication, la m\u00e9moire tampon client, la persistance AOF\/RDB et les structures internes occupent de la m\u00e9moire RAM suppl\u00e9mentaire. Ceux qui ne tiennent compte que du volume des donn\u00e9es utiles sous-estiment l'occupation r\u00e9elle et risquent de se heurter \u00e0 des goulots d'\u00e9tranglement. Je calcule d\u2019abord le volume de donn\u00e9es actives, j\u2019y ajoute une marge de 20 \u00e0 40 % en fonction des fonctionnalit\u00e9s, et je r\u00e9serve de l\u2019espace suppl\u00e9mentaire pour le syst\u00e8me d\u2019exploitation et les outils. Ainsi, l\u2019instance reste r\u00e9active m\u00eame en cas de pics de charge et offre des latences constantes.<\/p>\n\n<h2>D\u00e9finir correctement la valeur de `maxmemory` : d\u00e9finir la marge de man\u0153uvre<\/h2>\n<p>Je mets <strong>maxmemory<\/strong> g\u00e9n\u00e9ralement entre 50 et 75 % de la m\u00e9moire vive du serveur, afin de laisser de la marge aux caches du noyau, aux agents et \u00e0 la journalisation. Sur les h\u00f4tes d\u00e9di\u00e9s au cache, je commence souvent par 70 \u00e0 75 %, tandis que je suis plus prudent sur les machines partag\u00e9es. Le r\u00e9glage s\u2019effectue dans le fichier redis.conf (par exemple \u201c maxmemory 2gb \u201d) ou \u00e0 l\u2019ex\u00e9cution via \u201c CONFIG SET maxmemory 2gb \u201d. Une fois cette limite atteinte, la politique d\u2019\u00e9viction s\u2019applique, sinon les op\u00e9rations d\u2019\u00e9criture \u00e9chouent, ce que j\u2019utilise d\u00e9lib\u00e9r\u00e9ment comme m\u00e9canisme de protection. Ignorer cette limite expose \u00e0 des situations impr\u00e9visibles de m\u00e9moire insuffisante.<\/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\/07\/redis_memory_mgmt_setup_4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Choisir de mani\u00e8re cibl\u00e9e les politiques d'expulsion<\/h2>\n<p>Je passe le <strong>Eviction<\/strong>-Adaptez la politique au profil d'acc\u00e8s, car elle d\u00e9termine le taux de r\u00e9ussite et la stabilit\u00e9. Pour les caches classiques, la politique \u201c allkeys-lru \u201d est g\u00e9n\u00e9ralement la plus efficace, car les cl\u00e9s rarement utilis\u00e9es sont supprim\u00e9es en premier. Dans les configurations avec des TTL coh\u00e9rents, \u201c volatile-lru \u201d peut s\u2019av\u00e9rer judicieux, car seules les cl\u00e9s arrivant \u00e0 expiration sont modifi\u00e9es. Je n\u2019utilise des politiques al\u00e9atoires telles que \u201c allkeys-random \u201d que lorsqu\u2019aucune donn\u00e9e d\u2019utilisation n\u2019est exploitable. La pratique le montre : une politique claire, des TTL bien d\u00e9finis et une valeur \u00ab maxmemory \u00bb r\u00e9aliste garantissent un comportement pr\u00e9visible en situation de charge.<\/p>\n\n<h3>LRU vs LFU et r\u00e9glage pr\u00e9cis de l'\u00e9chantillonnage<\/h3>\n<p>Lorsque les acc\u00e8s sont tr\u00e8s asym\u00e9triques, j'ai tendance \u00e0 privil\u00e9gier <strong>LFU<\/strong>-Politiques (\u201c allkeys-lfu \u201d ou \u201c volatile-lfu \u201d), car elles permettent de conserver plus longtemps les \u00e9l\u00e9ments fr\u00e9quemment utilis\u00e9s dans le cache. Via <em>lfu-log-factor<\/em> je r\u00e8gle la sensibilit\u00e9 en fonction de la fr\u00e9quence d'acc\u00e8s, avec <em>lfu-temps-de-d\u00e9cay<\/em> \u00e0 quelle vitesse la \u201c popularit\u00e9 \u201d s'estompe. Cela a une incidence sur les indicateurs LRU\/LFU <em>maxmemory-samples<\/em> la qualit\u00e9 de la s\u00e9lection : 5 est la valeur par d\u00e9faut, 10 \u00e0 15 am\u00e9liore la d\u00e9cision tout en conservant une charge CPU mod\u00e9r\u00e9e. Je mesure l'impact, car un nombre d'\u00e9chantillons plus \u00e9lev\u00e9 peut augmenter l\u00e9g\u00e8rement la latence, mais rend les \u00e9victions plus efficaces.<\/p>\n\n<h2>Strat\u00e9gies TTL pour lutter contre la pression sur la m\u00e9moire<\/h2>\n<p>J'attribue \u00e0 toutes les cl\u00e9s de cache un <strong>TTL<\/strong>, afin que les entr\u00e9es obsol\u00e8tes disparaissent automatiquement. Des dur\u00e9es de vie diff\u00e9rentes pour les pages, les objets et les sessions permettent d'optimiser l'utilisation de la m\u00e9moire et d'augmenter le taux de r\u00e9ussite. Une petite part al\u00e9atoire par TTL permet d\u2019\u00e9viter les \u201c stampedes \u201d lorsque de nombreuses cl\u00e9s expirent simultan\u00e9ment. Si vous utilisez \u00ab volatile-* \u00bb, veillez \u00e0 ce que les cl\u00e9s pertinentes disposent bien d\u2019un TTL. Je v\u00e9rifie r\u00e9guli\u00e8rement les sch\u00e9mas d\u2019expiration et j\u2019adapte les dur\u00e9es en fonction des donn\u00e9es d\u2019acc\u00e8s r\u00e9elles.<\/p>\n\n<h3>R\u00e9glage pr\u00e9cis de l'effort \u00ab Active-Expire \u00bb et des d\u00e9clencheurs<\/h3>\n<p>J'augmente souvent la valeur de nombreuses cl\u00e9s TTL <em>active-expire-effort<\/em>, afin que les analyses en arri\u00e8re-plan suppriment rapidement les entr\u00e9es expir\u00e9es sans bloquer le serveur. Je combine cela avec des TTL l\u00e9g\u00e8rement d\u00e9cal\u00e9s (jitter de 5 \u00e0 10 %), afin d'\u00e9viter toute expiration simultan\u00e9e et, par cons\u00e9quent, tout afflux soudain de reconstructions. Dans les charges de travail comportant des objets volumineux et rarement consult\u00e9s, j\u2019active <em>lazyfree-lazy-expire<\/em>, afin d'effectuer la lib\u00e9ration de m\u00e9moire en arri\u00e8re-plan et d'\u00e9viter les pics de latence li\u00e9s aux op\u00e9rations de lib\u00e9ration de m\u00e9moire.<\/p>\n\n<h2>R\u00e9duire la fragmentation : activedefrag et surveillance<\/h2>\n<p>J'active la fonction active <strong>D\u00e9fragmentation<\/strong> pour les ensembles de donn\u00e9es dynamiques, afin de combler les trous de m\u00e9moire. Un taux de fragmentation nettement sup\u00e9rieur \u00e0 1,0 indique que la quantit\u00e9 de RAM physique allou\u00e9e est sup\u00e9rieure au n\u00e9cessaire. \u00c0 partir d'environ 1,4, j'\u00e9value la situation plus en d\u00e9tail et je d\u00e9cide s'il faut proc\u00e9der \u00e0 un r\u00e9glage fin de la d\u00e9fragmentation ou \u00e0 une redistribution des donn\u00e9es. Les instances fonctionnant depuis longtemps et pr\u00e9sentant des tailles de cl\u00e9s tr\u00e8s variables en tirent un b\u00e9n\u00e9fice mesurable. Je parviens ainsi \u00e0 \u00e9viter toute occupation inutile de la m\u00e9moire et \u00e0 maintenir des latences stables.<\/p>\n\n<h3>Configurer correctement Jemalloc et le syst\u00e8me d'exploitation<\/h3>\n<p>Je m'assure que la fonctionnalit\u00e9 THP (Transparent Huge Pages) est d\u00e9sactiv\u00e9e et que le serveur n'utilise pas la m\u00e9moire swap, car ces deux \u00e9l\u00e9ments nuisent \u00e0 la latence. <em>vm.overcommit_memory=1<\/em> Cela \u00e9vite les \u00e9checs de fork lors des r\u00e9\u00e9critures RDB\/AOF ; je pr\u00e9vois n\u00e9anmoins une marge suppl\u00e9mentaire (10\u201330 %) pour amortir les pics li\u00e9s au \u00ab copy-on-write \u00bb. Sous Linux, la commande <em>VIDAGE DE LA M\u00c9MOIRE<\/em> de temps en temps, d'adapter le flux RSS au niveau d'utilisation r\u00e9el. Pour la d\u00e9fragmentation, je pr\u00e9f\u00e8re <em>activedefrag-cycle-min\/max<\/em> et <em>activedefrag-ignore-bytes<\/em> afin que le travail se d\u00e9roule de mani\u00e8re r\u00e9guli\u00e8re, mais sans \u00eatre trop intense.<\/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\/07\/redis-memory-optimization-6382.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Utiliser efficacement les structures de donn\u00e9es et les encodages<\/h2>\n<p>Je choisis les types de donn\u00e9es en fonction du profil de stockage, et pas seulement par commodit\u00e9, car chaque octet <strong>compte<\/strong>. Les petits hachages, listes, ensembles et ensembles tri\u00e9s b\u00e9n\u00e9ficient souvent d'encodages compacts tels que listpack. Je divise les tr\u00e8s grandes valeurs en blocs g\u00e9rables afin que les mises \u00e0 jour restent granulaires et que les \u00e9victions soient plus pr\u00e9cises. Pour les champs volumineux rarement consult\u00e9s, j'utilise la compression au niveau de l'application avant l'\u00e9criture. Des noms de cl\u00e9s courts r\u00e9duisent la surcharge par entr\u00e9e et leur effet est perceptible lorsque l\u2019on compte des millions de cl\u00e9s.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Type de donn\u00e9es<\/th>\n      <th>Utilisation<\/th>\n      <th>Astuce d'encodage<\/th>\n      <th>Remarque concernant la m\u00e9moire<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Cha\u00eene<\/td>\n      <td>Valeurs individuelles, compteurs<\/td>\n      <td>Directement, avec compression dans l'application si n\u00e9cessaire<\/td>\n      <td><strong>Grandes touches<\/strong> \u00e9viter de fractionner les valeurs<\/td>\n    <\/tr>\n    <tr>\n      <td>Hash<\/td>\n      <td>Objets comportant des champs<\/td>\n      <td>listpack lorsque le nombre de champs est faible<\/td>\n      <td>Regrouper les petits objets, utiliser les champs avec parcimonie<\/td>\n    <\/tr>\n    <tr>\n      <td>List<\/td>\n      <td>Files d'attente, flux<\/td>\n      <td>listpack pour les listes courtes<\/td>\n      <td>Limiter la longueur, utiliser le rognage<\/td>\n    <\/tr>\n    <tr>\n      <td>Set\/ZSet<\/td>\n      <td>Quantit\u00e9s, classements<\/td>\n      <td>listpack\/skiplist par taille<\/td>\n      <td>Segmenter les grandes collections<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n<p>Je v\u00e9rifie r\u00e9guli\u00e8rement \u201c redis-cli \u2013bigkeys \u201d afin de rep\u00e9rer les valeurs aberrantes et d'analyser le profil de m\u00e9moire <strong>cibl\u00e9<\/strong> pour l'optimiser. Ainsi, l'instance conserve davantage de donn\u00e9es pertinentes en m\u00e9moire vive et traite les requ\u00eates plus rapidement.<\/p>\n\n<h3>Ajuster avec pr\u00e9cision les valeurs limites d'encodage<\/h3>\n<p>Je v\u00e9rifie <em>hash-max-listpack-entries\/valeur<\/em>, <em>set-max-intset-entries<\/em> et <em>zset-max-listpack-entries\/value<\/em>, afin de tirer parti des encodages Listpack le plus longtemps possible sans surcharger le processeur. Pour les listes, j'utilise <em>list-max-listpack-size<\/em> et <em>list-compress-depth<\/em> la compression. Je limite les flux avec <em>stream-node-max-bytes\/entries<\/em>. Au total, ces mesures permettent souvent de r\u00e9aliser des \u00e9conomies de m\u00e9moire vive de l'ordre de plusieurs dizaines de pour cent.<\/p>\n\n<h2>Surveillance et alertes : d\u00e9tection pr\u00e9coce<\/h2>\n<p>Je surveille le pourcentage de m\u00e9moire utilis\u00e9e, les \u00e9victions, le taux de r\u00e9ussite du cache et le taux de fragmentation, car <strong>Tendances<\/strong> sont plus importantes que les instantan\u00e9s. Si le taux d'utilisation d\u00e9passe durablement environ 75 %, je pr\u00e9vois des extensions de capacit\u00e9. Un taux d'\u00e9viction croissant associ\u00e9 \u00e0 un taux de r\u00e9ussite en baisse indique des politiques inadapt\u00e9es, des TTL trop courts ou un budget insuffisant. Je mets en place des alertes et je recoupe les pics avec les d\u00e9ploiements, les pics de trafic ou les t\u00e2ches par lots. Cela me permet de m\u2019attaquer aux causes plut\u00f4t que de simplement att\u00e9nuer les sympt\u00f4mes.<\/p>\n\n<h3>Diagnostic du stockage : indicateurs et commandes<\/h3>\n<p>J'utilise \u201c INFO memory \u201d, \u201c MEMORY STATS \u201d et \u201c MEMORY DOCTOR \u201d pour identifier des tendances. Avec \u201c MEMORY USAGE key SAMPLES N \u201d, je d\u00e9termine l'empreinte exacte des objets. Outre \u201c \u2013bigkeys \u201d, j\u2019utilise \u201c redis-cli \u2013memkeys \u201d et \u201c \u2013hotkeys \u201d, lorsqu\u2019elles sont disponibles, pour optimiser de mani\u00e8re cibl\u00e9e les cl\u00e9s gourmandes en m\u00e9moire ou particuli\u00e8rement sollicit\u00e9es. \u201c LATENCY DOCTOR \u201d permet de d\u00e9terminer si les \u00e9victions, les d\u00e9fragmentations ou les bifurcations g\u00e9n\u00e8rent des pics de latence.<\/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\/07\/redis_speicherverwaltung_5683.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Planifier la mise \u00e0 l'\u00e9chelle : verticalit\u00e9 ou clustering<\/h2>\n<p>Je proc\u00e8de \u00e0 une \u00e9volutivit\u00e9 verticale lorsque certains n\u0153uds ont besoin de plus de m\u00e9moire vive ou de puissance de calcul, et \u00e0 une \u00e9volutivit\u00e9 horizontale lorsque le sharding r\u00e9duit la latence et <strong>Capacit\u00e9<\/strong> mieux r\u00e9partis. Avant les mises \u00e0 niveau, j'ajuste les limites, les instantan\u00e9s et les param\u00e8tres de r\u00e9plication afin que la transition se d\u00e9roule sans pic d'\u00e9viction. En cas de trafic tr\u00e8s variable, un cluster permet de r\u00e9partir la charge des cl\u00e9s actives sur plusieurs n\u0153uds. Pour les sc\u00e9narios d'h\u00e9bergement, je v\u00e9rifie soigneusement l'isolation, par exemple avec <a href=\"https:\/\/webhosting.de\/fr\/redis-partage-vs-dedie-performances-securite-cacheboost\/\">Partag\u00e9 vs. D\u00e9di\u00e9<\/a>. Une strat\u00e9gie claire permet d'\u00e9viter un surdimensionnement co\u00fbteux et de r\u00e9duire les risques li\u00e9s aux variations de charge.<\/p>\n\n<h3>R\u00e9\u00e9quilibrage et cl\u00e9s volumineuses dans le cluster<\/h3>\n<p>Je planifie les fen\u00eatres de r\u00e9\u00e9quilibrage de mani\u00e8re \u00e0 ce que les cl\u00e9s volumineuses ne soient pas migr\u00e9es et \u00e9vacu\u00e9es simultan\u00e9ment. Les cl\u00e9s volumineuses sollicitent fortement la commande MIGRATE et peuvent faire grimper les tampons des clients. Je segmente donc les valeurs volumineuses au niveau de l'application afin que les d\u00e9placements de clusters restent granulaires et pr\u00e9sentent peu de risques.<\/p>\n\n<h2>Redis dans un environnement d'h\u00e9bergement : WordPress en pratique<\/h2>\n<p>Dans la pile WordPress, je d\u00e9finis des dur\u00e9es de vie (TTL) pr\u00e9cises pour le cache des pages, le cache des objets et les sessions, afin que la m\u00e9moire <strong>pratique<\/strong> reste. Les configurations types utilisent \u201c maxmemory-policy allkeys-lru \u201d et une limite de 60 \u00e0 75 % de RAM. Pour le cache d'objets, je v\u00e9rifie les noms de cl\u00e9s, car les pr\u00e9fixes extr\u00eamement longs g\u00e9n\u00e8rent une surcharge notable. Je traite syst\u00e9matiquement les erreurs courantes li\u00e9es au pr\u00e9fixage, aux TTL ou aux \u00ab misses \u00bb ; voir <a href=\"https:\/\/webhosting.de\/fr\/erreur-de-configuration-du-cache-dobjets-redis-optimisation-des-performances-de-wordpress\/\">\u00c9viter les erreurs li\u00e9es au cache d'objets<\/a>. La d\u00e9fragmentation active stabilise les sites \u00e0 forte fr\u00e9quentation pr\u00e9sentant des pics de trafic irr\u00e9guliers.<\/p>\n\n<h3>Classes TTL et pr\u00e9vention des taches<\/h3>\n<p>Je d\u00e9finis des classes de TTL (par exemple : pages HTML \u00e0 court terme, r\u00e9sultats de requ\u00eates \u00e0 moyen terme, profils utilisateur \u00e0 long terme) et j'attribue \u00e0 chaque classe un jitter de 5 \u00e0 15 %. Je surveille les pics de rat\u00e9s apr\u00e8s les d\u00e9ploiements : lorsque de nombreux caches sont actualis\u00e9s simultan\u00e9ment, j'augmente temporairement les TTL ou j'utilise des t\u00e2ches de pr\u00e9chauffage pour lisser la charge.<\/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\/07\/redis_memory_5381.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Persistance et r\u00e9plication : calculer le budget de stockage<\/h2>\n<p>Pour l'AOF\/RDB et la r\u00e9plication, je tiens toujours compte d'un <strong>M\u00e9moire<\/strong>, car les instantan\u00e9s et les tampons de r\u00e9plication occupent de la m\u00e9moire vive. Les instantan\u00e9s volumineux peuvent g\u00e9n\u00e9rer une pression sur la m\u00e9moire \u00e0 court terme en cas d'\u00e9critures simultan\u00e9es. Si vous utilisez des r\u00e9pliques, pr\u00e9voyez les pics de charge lors de la resynchronisation et v\u00e9rifiez la taille des tampons. Je r\u00e9sume les d\u00e9tails concernant les strat\u00e9gies et les compromis dans l'article consacr\u00e9 \u00e0 <a href=\"https:\/\/webhosting.de\/fr\/redis-persistance-rdb-aof-hebergement-serveur-guide\/\">RDB et AOF<\/a> ensemble. Ainsi, l'instance reste op\u00e9rationnelle m\u00eame en cas de sauvegarde ou de basculement.<\/p>\n\n<h3>Co\u00fbts li\u00e9s aux bifurcations, carnet de commandes et validation asynchrone<\/h3>\n<p>Je pr\u00e9vois 10 \u00e0 30 % de RAM suppl\u00e9mentaire pour les r\u00e9\u00e9critures RDB\/AOF en raison du \u00ab copy-on-write \u00bb. <em>aof-use-rdb-pr\u00e9ambule<\/em> acc\u00e9l\u00e8re les red\u00e9marrages, <em>auto-aof-rewrite-percentage\/size<\/em> contr\u00f4ler les r\u00e9\u00e9critures planifiables. Pour la r\u00e9plication, je dimensionne <em>taille-du-backlog-de-r\u00e9plication<\/em> de mani\u00e8re \u00e0 ce que les probl\u00e8mes r\u00e9seau ponctuels n'entra\u00eenent pas une resynchronisation compl\u00e8te. Je configure <em>replica-ignore-maxmemory<\/em> en fonction du r\u00f4le, afin que les r\u00e9pliques ne soient pas \u00e9vinc\u00e9es lorsqu\u2019elles rattrapent leur retard. En cas de suppressions massives, j\u2019active <em>lazyfree-lazy-eviction<\/em> et <em>lazyfree-lazy-server-del<\/em>, afin de dissocier la lib\u00e9ration de la m\u00e9moire de la p\u00e9riode critique de requ\u00eates.<\/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\/07\/redis-speicheroptimum-1834.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>M\u00e9moire tampon du client et Pub\/Sub : d\u00e9finir des limites strictes<\/h2>\n<p>Je mets <em>limite-de-tampon-de-sortie-client<\/em> pour <em>normal<\/em>, <em>r\u00e9plique<\/em> et <em>pubsub<\/em> de mani\u00e8re stricte, afin qu'aucun client ne provoque un OOM de l'instance. En cas de trafic Pub\/Sub important, je r\u00e8gle les tampons Pub\/Sub de mani\u00e8re prudente. De m\u00eame, je conserve <em>client-query-buffer-limit<\/em> \u00e0 l'\u0153il, afin d'\u00e9viter que certaines commandes volumineuses ne monopolisent de mani\u00e8re inattendue la m\u00e9moire vive. Dans les environnements multi-locataires, je s\u00e9pare les charges de travail dans des instances distinctes lorsque le profil de m\u00e9moire tampon varie consid\u00e9rablement.<\/p>\n\n<h2>Configuration concr\u00e8te : un profil de d\u00e9marrage r\u00e9silient<\/h2>\n<p>Je commence souvent par le profil suivant, que j'ajuste ensuite en fonction d'indicateurs r\u00e9els :<\/p>\n<pre><code>maxmemory 70%\nmaxmemory-policy allkeys-lfu\nmaxmemory-samples 10\n\n# TTL\/Expiration\nactive-expire-effort 7\nlazyfree-lazy-expire yes\n\n# Lazyfree pour les suppressions importantes\nlazyfree-lazy-eviction oui\nlazyfree-lazy-server-del oui\n\n# D\u00e9fragmentation\nactivedefrag oui\nactivedefrag-ignore-bytes 100mb\nactivedefrag-cycle-min 10\nactivedefrag-cycle-max 50\n\n# Structures de donn\u00e9es\nhash-max-listpack-entries 512\nhash-max-listpack-value 256\nzset-max-listpack-entries 512\nzset-max-listpack-value 128\nset-max-intset-entries 512\nlist-max-listpack-size -2\nlist-compress-depth 1\n\n# R\u00e9plication\/M\u00e9moire tampon\nrepl-backlog-size 256 Mo\nclient-output-buffer-limit normal 0 0 0\nclient-output-buffer-limit replica 256 Mo 64 Mo 60\nclient-output-buffer-limit pubsub 64 Mo 16 Mo 60\n<\/code><\/pre>\n<p>Je consid\u00e8re cela comme une valeur de r\u00e9f\u00e9rence, et non comme un dogme. Chaque environnement pr\u00e9sente ses propres formats de donn\u00e9es, ses propres mod\u00e8les de trafic et ses propres budgets de latence.<\/p>\n\n<h2>Tests sous charge : v\u00e9rifier plut\u00f4t que supposer<\/h2>\n<p>Je teste les configurations \u00e0 l'aide de tests de charge r\u00e9alistes (par exemple, des profils mixtes GET\/SET\/EXPIRE), en surveillant les \u00e9victions, le taux de r\u00e9ussite, la latence P99 et le taux de fragmentation. Je simule \u00e9galement des \u00e9v\u00e9nements tels que la r\u00e9\u00e9criture AOF, les instantan\u00e9s RDB, la resynchronisation des r\u00e9pliques et les suppressions massives, afin de mesurer la marge de man\u0153uvre et les effets de \u00ab lazyfree \u00bb. Ce n\u2019est que lorsque le chemin reste stable en cas de pics que je d\u00e9ploie les modifications en production.<\/p>\n\n<h2>Containers et architecture multi-locataires : d\u00e9finir clairement des limites strictes<\/h2>\n<p>Je mets <strong>maxmemory<\/strong> en dessous de la limite du conteneur, afin que le \u00ab Cgroup OOM Killer \u00bb n\u2019intervienne pas en premier. J\u2019isole les charges de travail pr\u00e9sentant des profils de tampon et de TTL diff\u00e9rents dans des instances distinctes, plut\u00f4t que de m\u00e9langer les bases de donn\u00e9es \u2013 car Redis partage <em>maxmemory<\/em> pas par base de donn\u00e9es. Dans Kubernetes, je planifie le PodDisruptionBudget et les mises \u00e0 jour progressives de mani\u00e8re \u00e0 ce qu\u2019aucun \u00ab warm-up \u00bb simultan\u00e9 ne provoque de vagues d\u2019\u00e9viction.<\/p>\n\n<h2>Liste de contr\u00f4le pratique et mise en \u0153uvre<\/h2>\n<p>Je commence avec un objectif clair <strong>Plan par \u00e9tapes<\/strong>: L'\u00e9tape 1 d\u00e9termine le budget m\u00e9moire, y compris la surcharge et la r\u00e9serve ; l'\u00e9tape 2 d\u00e9finit maxmemory entre 50 et 75 % et s\u00e9lectionne la politique appropri\u00e9e ; l'\u00e9tape 3 d\u00e9finit des TTL avec une faible gigue pour toutes les cl\u00e9s de cache ; l\u2019\u00e9tape 4 optimise les structures de donn\u00e9es, segmente les cl\u00e9s volumineuses et raccourcit les noms ; l\u2019\u00e9tape 5 active \u00ab activedefrag \u00bb et surveille le taux de fragmentation ; l\u2019\u00e9tape 6 configure les m\u00e9triques et les alertes ; l\u2019\u00e9tape 7 teste les pics de charge de mani\u00e8re r\u00e9aliste et planifie la mise \u00e0 l\u2019\u00e9chelle en temps utile. Je mesure chaque changement au lieu de me contenter de le supposer. C\u2019est la seule fa\u00e7on de constater de r\u00e9els progr\u00e8s. Ce rythme permet d\u2019\u00e9tablir un mod\u00e8le d\u2019exploitation fiable.<\/p>\n\n<h2>Conclusion : la m\u00e9moire comme outil actif d'optimisation des performances<\/h2>\n<p>Je consid\u00e8re les bases de donn\u00e9es Redis comme des \u00e9l\u00e9ments contr\u00f4lables <strong>Levier<\/strong> en mati\u00e8re de latence, de d\u00e9bit et de fiabilit\u00e9. En fixant clairement des limites, en choisissant judicieusement les politiques et en utilisant syst\u00e9matiquement les TTL, on obtient un comportement pr\u00e9visible m\u00eame sous pression. La surveillance, le contr\u00f4le de la fragmentation et les types de donn\u00e9es structur\u00e9s permettent de tirer davantage de capacit\u00e9 de la m\u00eame m\u00e9moire RAM. La mise \u00e0 l'\u00e9chelle devient alors une \u00e9tape planifi\u00e9e, et non un frein de secours. Ainsi, la m\u00e9moire Redis reste ma\u00eetrisable, le taux de r\u00e9ussite du cache \u00e9lev\u00e9 et l'application rapide \u2013 du petit projet \u00e0 la plateforme tr\u00e8s fr\u00e9quent\u00e9e.<\/p>","protected":false},"excerpt":{"rendered":"<p>Guide pratique sur la gestion de la m\u00e9moire Redis : comment configurer la m\u00e9moire de mani\u00e8re optimale, notamment les param\u00e8tres maxmemory, les politiques d'\u00e9viction et la surveillance \u2013 en mettant l'accent sur la m\u00e9moire Redis pour des performances maximales.<\/p>","protected":false},"author":1,"featured_media":20109,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-20116","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":"130","_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 memory","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":"20109","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20116","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=20116"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20116\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/20109"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=20116"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=20116"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=20116"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}