{"id":15871,"date":"2025-12-07T15:07:21","date_gmt":"2025-12-07T14:07:21","guid":{"rendered":"https:\/\/webhosting.de\/warum-redis-langsamer-ist-als-gedacht-typische-fehlkonfigurationen-cacheopt\/"},"modified":"2025-12-07T15:07:21","modified_gmt":"2025-12-07T14:07:21","slug":"pourquoi-redis-est-plus-lent-que-prevu-erreurs-de-configuration-courantes-cacheopt","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/warum-redis-langsamer-ist-als-gedacht-typische-fehlkonfigurationen-cacheopt\/","title":{"rendered":"Pourquoi Redis peut \u00eatre plus lent que pr\u00e9vu : erreurs de configuration courantes et comment les \u00e9viter"},"content":{"rendered":"<p>Redis semble souvent lent lorsque la configuration, l'infrastructure ou les mod\u00e8les d'acc\u00e8s ne sont pas adapt\u00e9s. C'est pr\u00e9cis\u00e9ment l\u00e0 qu'intervient <strong>optimisation Redis<\/strong> Je te montre concr\u00e8tement quelles erreurs de configuration provoquent des latences et comment tu peux les \u00e9viter syst\u00e9matiquement.<\/p>\n\n<h2>Points centraux<\/h2>\n\n<ul>\n  <li><strong>\u00e9change<\/strong> \u00c9limine la latence : les goulots d'\u00e9tranglement de la RAM entra\u00eenent imm\u00e9diatement des acc\u00e8s au disque dur.<\/li>\n  <li><strong>Retards de fourche<\/strong> Par RDB\/AOF : les instantan\u00e9s et les r\u00e9\u00e9critures g\u00e9n\u00e8rent de courtes pauses marqu\u00e9es.<\/li>\n  <li><strong>AOF\/Stockage<\/strong> ralentit : des disques lents et un fsync agressif augmentent les temps de r\u00e9ponse.<\/li>\n  <li><strong>Commandes lentes<\/strong>: Les structures volumineuses et les commandes co\u00fbteuses sollicitent le CPU.<\/li>\n  <li><strong>chemin r\u00e9seau<\/strong> compte : la distance, les surcharges des conteneurs et les proxys augmentent la latence.<\/li>\n<\/ul>\n\n<h2>Pourquoi Redis semble lent sous charge<\/h2>\n\n<p>Redis fournit des temps de r\u00e9ponse tr\u00e8s courts, mais <strong>r\u00e9alit\u00e9<\/strong> et les conditions de laboratoire diff\u00e8rent consid\u00e9rablement. Les niveaux virtuels, les h\u00f4tes partag\u00e9s et la surcharge r\u00e9seau suppl\u00e9mentaire augmentent chaque milliseconde, en particulier lors des pics de charge. Je rencontre souvent des configurations dans lesquelles les superpositions de conteneurs, les proxys sidecar et les zones distantes masquent la vitesse r\u00e9elle en m\u00e9moire. \u00c0 cela s'ajoutent les particularit\u00e9s du syst\u00e8me d'exploitation, telles que les pages g\u00e9antes transparentes ou le swapping agressif, qui accentuent encore les retards. Sans bases solides, Redis semble soudainement lent, m\u00eame si le moteur fonctionne rapidement et que le goulot d'\u00e9tranglement se situe en dehors de la base de donn\u00e9es.<\/p>\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\/2025\/12\/redis-server-debug-4831.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>\u00c9viter le swapping : RAM, maxmemory et strat\u00e9gie d'\u00e9viction<\/h2>\n\n<p>Lorsque le syst\u00e8me d'exploitation transf\u00e8re la m\u00e9moire Redis vers le disque, la <strong>Latence<\/strong>. C'est pourquoi je pr\u00e9vois toujours suffisamment de RAM et surveille en permanence la consommation. D\u00e9finissez maxmemory et une politique d'\u00e9viction appropri\u00e9e afin que l'instance supprime les donn\u00e9es \u00e0 temps au lieu de les transf\u00e9rer vers le swap. S\u00e9parez les processus gourmands en m\u00e9moire de l'h\u00f4te Redis, car les charges de travail concurrentes aggravent le risque. Sans ces r\u00e8gles de base, aucune autre mesure ne r\u00e9soudra le probl\u00e8me r\u00e9el et chaque requ\u00eate peut soudainement prendre des centaines de millisecondes.<\/p>\n\n<h2>R\u00e9duire les latences de fourche gr\u00e2ce aux instantan\u00e9s RDB et aux r\u00e9\u00e9critures AOF<\/h2>\n\n<p>Les instantan\u00e9s RDB et les r\u00e9\u00e9critures AOF lancent des processus en arri\u00e8re-plan via fork, ce qui peut entra\u00eener des ralentissements notables sur les instances de grande taille. <strong>pauses<\/strong> Je d\u00e9sactive les pages transparentes sur les syst\u00e8mes Linux, car elles rendent le copiage \u00e0 l'\u00e9criture plus co\u00fbteux et prolongent les d\u00e9lais. J'ajuste \u00e9galement les intervalles de snapshot et les seuils de r\u00e9\u00e9criture AOF afin de limiter la fr\u00e9quence des fourches. Je divise les grandes instances monolithiques en plusieurs fragments plus petits afin que les fourches individuelles aient moins d'impact. Ceux qui ignorent cela subissent souvent une panne pr\u00e9cis\u00e9ment au moment de la sauvegarde, m\u00eame si tout semblait fonctionner rapidement auparavant.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/redis_besprechung_0931.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Choisir correctement l'AOF, le stockage et la strat\u00e9gie fsync<\/h2>\n\n<p>AOF augmente la durabilit\u00e9, mais les disques lents et fsync agressif acc\u00e9l\u00e8rent <strong>Temps de r\u00e9ponse<\/strong> vers le haut. Je stocke les donn\u00e9es Redis sur des SSD rapides et les s\u00e9pare des E\/S de sauvegarde ou de base de donn\u00e9es afin que les r\u00e9\u00e9critures ne soient pas bloqu\u00e9es. Pour de nombreuses charges de travail, everysec, combin\u00e9 \u00e0 no-appendfsync-on-rewrite yes, suffit pour lisser les pics. V\u00e9rifiez r\u00e9guli\u00e8rement si la combinaison RDB et AOF correspond \u00e0 vos besoins, au lieu d'activer instinctivement \u201e fsync always \u201c. En pr\u00eatant attention au mat\u00e9riel et en choisissant consciemment votre strat\u00e9gie, vous garderez la latence sous contr\u00f4le.<\/p>\n\n<h2>Ralentir les commandes et d\u00e9samorcer le mod\u00e8le de donn\u00e9es<\/h2>\n\n<p>Certaines commandes co\u00fbtent cher sur les grandes structures <strong>CPU<\/strong>, comme SORT, ZINTERSTORE ou LRANGE massif. J'utilise activement le slow log et j'analyse les valeurs aberrantes par type de commande, taille des donn\u00e9es et cl\u00e9s. Je divise les grandes structures en segments plus petits ou je choisis d'autres types de donn\u00e9es qui correspondent mieux au mod\u00e8le d'acc\u00e8s. Si n\u00e9cessaire, je transf\u00e8re les \u00e9valuations gourmandes en ressources CPU vers des r\u00e9pliques ou des instances d\u00e9di\u00e9es afin que le chemin d'acc\u00e8s reste rapide. Les requ\u00eates redeviennent ainsi planifiables, au lieu de prendre sporadiquement quelques secondes.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/redis-fehlkonfiguration-vermeiden-7246.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>R\u00e9duire le r\u00e9seau, les conteneurs et la distance<\/h2>\n\n<p>De nombreux probl\u00e8mes de latence sont en r\u00e9alit\u00e9 <strong>temps de transport<\/strong> et non un probl\u00e8me Redis. Je conserve l'application et Redis dans la m\u00eame zone, j'\u00e9vite les proxys inutiles et je v\u00e9rifie le MTU et la surcharge TLS. Dans les configurations Kubernetes, je prends en compte les r\u00e9seaux superpos\u00e9s et les goulots d'\u00e9tranglement potentiels dans les plugins CNI. Moins il y a de sauts, moins la dispersion est importante dans les 95e\/99e centiles. Si vous voulez des millisecondes pr\u00e9visibles, placez Redis aussi pr\u00e8s que possible du code, et non \u00e0 travers les centres de donn\u00e9es.<\/p>\n\n<h2>Aborder le dimensionnement, le single-threading et le sharding de mani\u00e8re pragmatique<\/h2>\n\n<p>Une instance Redis traite les commandes dans le thread principal, donc limiter <strong>Noyaux du CPU<\/strong> et le taux de commande d\u00e9terminent la performance r\u00e9elle. Je choisis suffisamment de vCPU, je d\u00e9charge la machine des services externes et je r\u00e9partis les responsabilit\u00e9s entre plusieurs instances. Pour les cas d'utilisation purement cache, je compare parfois diff\u00e9rentes alternatives ; le <a href=\"https:\/\/webhosting.de\/fr\/redis-memcached-cache-comparaison-wordpress-cache-de-performance\/\">Comparaison entre Redis et Memcached<\/a> aide \u00e0 prendre une d\u00e9cision. Le sharding r\u00e9partit la charge et r\u00e9duit l'impact des retards individuels. Ceux qui concentrent tout dans une seule instance risquent des goulots d'\u00e9tranglement en cas de pointe de charge et des temps de r\u00e9ponse plus longs.<\/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\/2025\/12\/redis_debug_nightoffice_2947.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Surveillance, m\u00e9triques et d\u00e9pannage<\/h2>\n\n<p>Sans valeurs mesur\u00e9es, l'optimisation reste un <strong>Vol \u00e0 l'aveugle<\/strong>. Je surveille les latences par commande, les 95e\/99e centiles, la consommation de m\u00e9moire, la fragmentation, le nombre de clients et les \u00e9v\u00e9nements BGSAVE\/AOF. INFO, Slow Log et Infrastructure Monitoring indiquent rapidement si la RAM, le CPU, les E\/S ou le r\u00e9seau sont limit\u00e9s. Il est important d'avoir une vue coh\u00e9rente sur les p\u00e9riodes afin de pouvoir corr\u00e9ler les retards avec les fourches, les r\u00e9\u00e9critures ou les d\u00e9ploiements. Cr\u00e9ez \u00e9galement des alertes bas\u00e9es sur des seuils adapt\u00e9s aux besoins de l'entreprise, plut\u00f4t que de vous baser sur des valeurs moyennes.<\/p>\n\n<h2>Strat\u00e9gie de cache et conception des cl\u00e9s, augmenter le taux de r\u00e9ussite<\/h2>\n\n<p>Un cache rapide ne sert \u00e0 rien si les cl\u00e9s et les TTL <strong>arbitraire<\/strong> Je mise sur des mod\u00e8les clairs tels que Cache\u2011Aside et des cl\u00e9s coh\u00e9rentes et explicites afin d'augmenter le taux de r\u00e9ussite. Je choisis les TTL de mani\u00e8re \u00e0 ce que les donn\u00e9es restent suffisamment r\u00e9centes sans devoir \u00eatre constamment recalcul\u00e9es. Planifiez explicitement l'invalidation, par exemple via TTL, des approches bas\u00e9es sur des balises ou des signaux Pub\/Sub. Ce guide vous aidera \u00e0 mettre en pratique ces \u00e9tapes : <a href=\"https:\/\/webhosting.de\/fr\/configuration-de-la-mise-en-cache-wordpress-redis-accelerer-les-performances-9324\/\">Configurer la mise en cache<\/a> et contr\u00f4ler les mesures.<\/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\/2025\/12\/redis_slow_config_tipps_7329.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>V\u00e9rification de la configuration : param\u00e8tres par d\u00e9faut pertinents et progr\u00e8s rapides<\/h2>\n\n<p>Si vous voulez voir rapidement des r\u00e9sultats, commencez par mettre en place des mesures solides. <strong>D\u00e9fauts<\/strong> et les teste sous charge. Je m'abstiens strictement de tout swapping, je r\u00e9gule la m\u00e9moire via maxmemory et je r\u00e9gule la persistance via RDB plus AOF mod\u00e9r\u00e9. Je d\u00e9sactive THP et je place les donn\u00e9es sur des SSD, s\u00e9par\u00e9ment des autres t\u00e2ches d'E\/S. Du c\u00f4t\u00e9 du r\u00e9seau, je veille \u00e0 ce que les distances soient courtes et je r\u00e9duis les proxys inutiles. Le tableau suivant regroupe les principaux param\u00e8tres avec les erreurs typiques et les r\u00e9glages pratiques.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Sujet<\/th>\n      <th>marque de mesure<\/th>\n      <th>mauvais r\u00e9glage<\/th>\n      <th>Recommandation<\/th>\n      <th>Remarque<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>RAM\/Swap<\/td>\n      <td>pics de latence \u00e9lev\u00e9s<\/td>\n      <td>pas de maxmemory<\/td>\n      <td>maxmemory + Eviction<\/td>\n      <td>\u00c9viter strictement les swaps<\/td>\n    <\/tr>\n    <tr>\n      <td>Persistance<\/td>\n      <td>Fork-Lags<\/td>\n      <td>fr\u00e9quent BGSAVE<\/td>\n      <td>Allonger les intervalles<\/td>\n      <td>R\u00e9duire l'instance<\/td>\n    <\/tr>\n    <tr>\n      <td>AOF\/fsync<\/td>\n      <td>Pics IO<\/td>\n      <td>fsync toujours<\/td>\n      <td>everysec + options<\/td>\n      <td>SSD et disques s\u00e9par\u00e9s<\/td>\n    <\/tr>\n    <tr>\n      <td>THP<\/td>\n      <td>fourches longues<\/td>\n      <td>THP actif<\/td>\n      <td>THP d\u00e9sactiv\u00e9<\/td>\n      <td>V\u00e9rifier le param\u00e8tre du noyau<\/td>\n    <\/tr>\n    <tr>\n      <td>commandes<\/td>\n      <td>CPU \u00e9lev\u00e9<\/td>\n      <td>SORT\/STORE grand<\/td>\n      <td>Utiliser Slow Log<\/td>\n      <td>Adapter le mod\u00e8le de donn\u00e9es<\/td>\n    <\/tr>\n    <tr>\n      <td>R\u00e9seau<\/td>\n      <td>Le transport domine<\/td>\n      <td>zone \u00e9loign\u00e9e<\/td>\n      <td>proximit\u00e9 locale<\/td>\n      <td>V\u00e9rifier Hops et MTU<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Mod\u00e8les architecturaux et hi\u00e9rarchies de mise en cache<\/h2>\n\n<p>Une bonne architecture dirige les demandes vers le chemin le plus court <strong>Chemin d'acc\u00e8s<\/strong> R\u00e9ponse. Je combine Edge, App et Redis Cache afin de r\u00e9duire les requ\u00eates d'origine co\u00fbteuses et de soulager Redis lui-m\u00eame. Ainsi, les acc\u00e8s en lecture sont r\u00e9partis, tandis que Redis traite les cl\u00e9s rapides et dynamiques. Un aper\u00e7u des niveaux pertinents aide \u00e0 adapter la solution \u00e0 sa propre plateforme : consulte la <a href=\"https:\/\/webhosting.de\/fr\/caching-hierarchies-technique-web-hebergement-boost\/\">Hi\u00e9rarchies de mise en cache<\/a> et donne la priorit\u00e9 aux leviers les plus importants. En combinant architecture et configuration, on r\u00e9sout les probl\u00e8mes de latence de mani\u00e8re plus durable qu'avec des ajustements individuels.<\/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\/2025\/12\/redis-serverfehler-9284.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Connexions client, pipelining et pools<\/h2>\n\n<p>De nombreuses millisecondes disparaissent dans le <strong>Handshake<\/strong> et non dans Redis. Je mise sur des connexions TCP\/TLS durables via le pooling de connexions, plut\u00f4t que de me reconnecter \u00e0 chaque requ\u00eate. Cela r\u00e9duit non seulement les RTT, mais aussi les handshakes TLS et les v\u00e9rifications de certificats. Le pipelining regroupe de nombreuses petites commandes dans un RTT, ce qui augmente consid\u00e9rablement le d\u00e9bit, tant que les r\u00e9ponses ne sont pas utilis\u00e9es de mani\u00e8re strictement s\u00e9quentielle. Pour les s\u00e9quences atomiques, j'utilise MULTI\/EXEC de mani\u00e8re cibl\u00e9e, mais je ne m\u00e9lange pas aveugl\u00e9ment les transactions dans les chemins chauds. Je choisis des d\u00e9lais d'attente courts mais r\u00e9alistes et je respecte <strong>tcp-keepalive<\/strong> active afin que les connexions mortes soient d\u00e9tect\u00e9es de mani\u00e8re fiable. Il est \u00e9galement important que la <strong>maxclients<\/strong>Param\u00e9trage incluant ulimit (<em>nofile<\/em>) afin que les pics ne soient pas compromis par des descripteurs manquants. De plus, l'algorithme de Nagle n'est d'aucune aide pour Redis : les serveurs et les clients doivent <strong>TCP_NODELAY<\/strong> pour que les r\u00e9ponses s'\u00e9coulent imm\u00e9diatement.<\/p>\n\n<h2>Utilisation cibl\u00e9e des threads E\/S et de la surcharge TLS<\/h2>\n\n<p>Redis reste pour l'ex\u00e9cution des commandes <strong>\u00e0 thread unique<\/strong>, mais peut g\u00e9rer les E\/S r\u00e9seau via <strong>io-threads<\/strong> all\u00e9ger la charge. En cas de charge TLS importante ou de charges utiles volumineuses, j'active mod\u00e9r\u00e9ment (par exemple 2 \u00e0 4 threads) et je teste avec <em>io-threads-do-reads oui<\/em>. Cela acc\u00e9l\u00e8re les lectures\/\u00e9critures, mais pas le travail du processeur li\u00e9 aux commandes. Je surveille la charge du syst\u00e8me et les percentiles de latence : un nombre trop \u00e9lev\u00e9 de threads peut augmenter les changements de contexte et neutraliser les gains. Ceux qui travaillent sans TLS et avec de petites r\u00e9ponses n'en tirent souvent que peu d'avantages ; avec TLS, cependant, cela me permet de r\u00e9duire de mani\u00e8re fiable le <strong>Latence du r\u00e9seau<\/strong>.<\/p>\n\n<h2>Expiration, temp\u00eates TTL et Lazy-Free<\/h2>\n\n<p>Synchronisation de la fin <strong>TTLs<\/strong> g\u00e9n\u00e8rent des pics d'expiration. J'ajoute de la gigue aux TTL, je disperse les op\u00e9rations et je maintiens la charge d'expiration active \u00e0 un niveau faible. Les suppressions importantes bloquent le thread principal ; c'est pourquoi j'utilise <strong>UNLINK<\/strong> au lieu de DEL pour les grandes touches et active <strong>lazyfree<\/strong>Options (par exemple. <em>lazyfree-lazy-eviction<\/em>, <em>lazyfree-lazy-expire<\/em>, <em>lazyfree-lazy-server-del<\/em>). Ainsi, les op\u00e9rations Free co\u00fbteuses sont transf\u00e9r\u00e9es dans des threads d'arri\u00e8re-plan. De plus, j'observe les statistiques Expire dans INFO : Croissance <em>expired_keys<\/em> et <em>evicted_keys<\/em> Si les deux sont \u00e9lev\u00e9s, cela signifie soit que le mod\u00e8le de donn\u00e9es est trop volumineux, soit que la strat\u00e9gie TTL est d\u00e9s\u00e9quilibr\u00e9e.<\/p>\n\n<h2>Fragmentation de la m\u00e9moire et d\u00e9fragmentation active<\/h2>\n\n<p>Haute <strong>mem_fragmentation_ratio<\/strong> dans INFO indique une fragmentation ou une pression d'\u00e9change. J'active <strong>activedefrag<\/strong> et ajuste les cycles (<em>cycle-de-d\u00e9fragmentation-actif-min\/max<\/em>) afin de r\u00e9cup\u00e9rer progressivement de la m\u00e9moire sans surcharger le thread principal. Cela est particuli\u00e8rement utile pour les charges de travail comportant de nombreuses mises \u00e0 jour et suppressions d'objets de taille moyenne. En parall\u00e8le, je v\u00e9rifie le <strong>Encodage<\/strong> petites structures, car des limites de compactage mal configur\u00e9es (listes, hachages, ensembles) augmentent la charge et l'utilisation du processeur. L'objectif est de trouver un \u00e9quilibre : un compactage suffisant pour garantir l'efficacit\u00e9, mais sans structures de compactage trop volumineuses qui rendent les mises \u00e0 jour co\u00fbteuses. Je r\u00e9sous \u00e9galement la fragmentation en \u00e9vitant les charges de travail \u201e tout ou rien \u201c volumineuses et en r\u00e9partissant les suppressions tout au long de la journ\u00e9e.<\/p>\n\n<h2>Ma\u00eetriser les clusters, le sharding et les hotspots<\/h2>\n\n<p>Le sharding ne r\u00e9duit la latence que si les hotkeys ne se retrouvent pas tous sur le m\u00eame shard. J'utilise <strong>Hash tags<\/strong>, pour regrouper les cl\u00e9s associ\u00e9es et r\u00e9partir d\u00e9lib\u00e9r\u00e9ment les cl\u00e9s tr\u00e8s fr\u00e9quent\u00e9es. Les commandes multi-cl\u00e9s ne fonctionnent dans le cluster qu'au sein d'un seul slot. Je planifie le mod\u00e8le de donn\u00e9es de mani\u00e8re \u00e0 ce que ces op\u00e9rations ne doivent pas traverser les slots. Lors du resharding, je veille \u00e0 effectuer un d\u00e9placement en douceur afin de ne pas cr\u00e9er de creux de trafic et j'observe la <strong>MOVED\/ASK<\/strong>Dans les clients, j'utilise des r\u00e9pliques pour all\u00e9ger la charge de lecture, mais je garde \u00e0 l'esprit les exigences de coh\u00e9rence. Ceux qui fragmentent sans plan \u00e9changeront les retards locaux contre des pics de latence distribu\u00e9s et moins visibles.<\/p>\n\n<h2>R\u00e9plication, backlog et basculement<\/h2>\n\n<p>Une r\u00e9plication stable emp\u00eache les resynchronisations compl\u00e8tes et les pics de latence. Je dimensionne <strong>taille-du-backlog-de-r\u00e9plication<\/strong> g\u00e9n\u00e9reux, afin que les r\u00e9pliques puissent rattraper leur retard apr\u00e8s de br\u00e8ves interruptions du r\u00e9seau via PSYNC. <strong>R\u00e9plication sans disque<\/strong> (<em>repl-diskless-sync oui<\/em>) \u00e9conomise les E\/S pendant la synchronisation, mais ne r\u00e9duit pas les exigences r\u00e9seau \u2013 la bande passante doit \u00eatre adapt\u00e9e. <strong>limite-de-tampon-de-sortie-client<\/strong> pour les r\u00e9pliques et les clients Pub\/Sub, je d\u00e9finis de mani\u00e8re \u00e0 ce que les lecteurs lents ne bloquent pas l'instance. Avec <strong>min-r\u00e9pliques-\u00e0-\u00e9crire<\/strong> Je trouve le juste \u00e9quilibre entre durabilit\u00e9 et disponibilit\u00e9 : cela est judicieux pour certaines charges de travail, mais pas pour les chemins critiques en termes de latence. Important : pratiquez r\u00e9guli\u00e8rement le basculement avec des volumes de donn\u00e9es r\u00e9els et coordonnez les d\u00e9lais d'expiration afin qu'une v\u00e9ritable panne ne se transforme pas en loterie de latence.<\/p>\n\n<h2>Contre-pression client et tampon de sortie<\/h2>\n\n<p>Si les clients consomment les donn\u00e9es plus lentement que Redis ne les produit, elles s'accumulent. <strong>Tampon de sortie<\/strong>. Je fixe des limites claires (<em>limite-de-tampon-de-sortie-client<\/em> pour normal, pubsub, replica) et enregistrez les droppings afin d'identifier les candidats probl\u00e9matiques. Pour Pub\/Sub\u2011Fanout, je pr\u00e9f\u00e8re les messages plus courts et les canaux th\u00e9matiques plut\u00f4t qu'un \u201e canal tout \u201c. Je n'active les notifications Keyspace que de mani\u00e8re cibl\u00e9e, car trop larges <em>notify-keyspace-events<\/em> co\u00fbte sensiblement en CPU. Je traite la contre-pression comme un sujet d'architecture : mieux vaut plusieurs flux\/canaux sp\u00e9cialis\u00e9s qu'un flux unique trop important qui submerge les abonn\u00e9s individuels.<\/p>\n\n<h2>Optimisation du syst\u00e8me d'exploitation : sockets, fichiers et VM<\/h2>\n\n<p>Outre THP, les param\u00e8tres par d\u00e9faut du noyau influencent la <strong>Latence<\/strong> nettement. J'augmente <em>somaxconn<\/em> et les valeurs du carnet de commandes, passe <em>fs.file-max<\/em> ainsi que ulimit (<em>nofile<\/em>) et je garde <em>tcp_keepalive_time<\/em> suffisamment bas pour \u00e9viter les accrochages. <em>vm.swappiness<\/em> Je le r\u00e8gle tr\u00e8s bas, souvent proche de 1, et <em>vm.overcommit_memory<\/em> sur 1 pour que les fourches passent plus rapidement. Le r\u00e9gulateur CPU sur \u201e performance \u201c emp\u00eache la r\u00e9duction de fr\u00e9quence lors des changements de charge. C\u00f4t\u00e9 stockage, je renonce si possible aux \u201e voisins bruyants \u201c et s\u00e9pare les donn\u00e9es des t\u00e2ches de sauvegarde. Ce sont l\u00e0 autant de petits r\u00e9glages qui, ensemble, permettent d'optimiser le <strong>Jitter<\/strong> atteindre le 99e centile.<\/p>\n\n<h2>Des crit\u00e8res de r\u00e9f\u00e9rence r\u00e9alistes plut\u00f4t que des chiffres optimistes<\/h2>\n\n<p><em>redis-benchmark<\/em> fournit des tendances utiles, mais les charges de travail r\u00e9elles diff\u00e8rent : combinaison de commandes, tailles de charge utile, <strong>pipeline<\/strong>, nombre de connexions, TLS, chemin r\u00e9seau. Je simule avec des clients de production, je varie <em>-c<\/em> (Concurrence) et <em>-P<\/em> (pipeline) et je mesure les percentiles de latence sur des p\u00e9riodes prolong\u00e9es. Il est important d'avoir une phase froide et une phase chaude afin que les caches, les JIT et les fen\u00eatres TCP aient un effet r\u00e9aliste. Pour les chemins r\u00e9seau, j'utilise parfois des injections artificielles de RTT\/jitter afin d'\u00e9valuer les changements de zone. Ce n'est pas le meilleur chiffre qui est d\u00e9terminant, mais la stabilit\u00e9 de la <strong>95e\/99e centile<\/strong> rester sous charge.<\/p>\n\n<h2>Utiliser les outils de diagnostic de mani\u00e8re cibl\u00e9e<\/h2>\n\n<p>Outre INFO et Slow Log, j'utilise <strong>LATENCY DOCTOR<\/strong>, pour d\u00e9tecter les pics syst\u00e9matiques, ainsi que <strong>GRAPHIQUE DE LATENCE\/HISTORIQUE<\/strong> pour la classification chronologique. <strong>STATISTIQUES M\u00c9MOIRE\/DOCTEUR<\/strong> montre o\u00f9 la m\u00e9moire est gaspill\u00e9e. Je n'utilise MONITOR que sur le court terme et sur des instances isol\u00e9es \u2013 la surcharge est r\u00e9elle. Sur l'h\u00f4te, cela aide. <em>iostat<\/em>, <em>vmstat<\/em>, <em>pidstat<\/em> et <em>ss<\/em>, pour voir les \u00e9tats d'attente d'E\/S, de file d'attente d'ex\u00e9cution et de socket. L'objectif est un d\u00e9pannage bas\u00e9 sur des hypoth\u00e8ses : m\u00e9trique \u2192 suspicion \u2192 contre-v\u00e9rification. Cela m'\u00e9vite de proc\u00e9der \u00e0 des ajustements \u00e0 l'aveuglette et me permet de prendre des mesures qui r\u00e9duisent de mani\u00e8re mesurable la latence.<\/p>\n\n<h2>En bref : comment Redis reste rapide<\/h2>\n\n<p>J'emp\u00eache Redis de ralentir en utilisant <strong>Swap<\/strong> Je d\u00e9sactive, je r\u00e9gule strictement la m\u00e9moire et je r\u00e8gle la persistance avec discernement. THP d\u00e9sactiv\u00e9, SSD activ\u00e9, fr\u00e9quence de fork r\u00e9duite : ainsi, la plupart des pics disparaissent. Je d\u00e9tecte les commandes co\u00fbteuses dans le slow log, j'adapte le mod\u00e8le de donn\u00e9es et je maintiens les hot paths l\u00e9gers. Je place Redis \u00e0 proximit\u00e9 de l'application, je dimensionne correctement le CPU et je r\u00e9partis la charge sur plusieurs instances. Gr\u00e2ce \u00e0 une surveillance constante, je d\u00e9tecte les tendances \u00e0 un stade pr\u00e9coce et ma\u00eetrise durablement les effets \u201e redis slow hosting \u201c.<\/p>","protected":false},"excerpt":{"rendered":"<p>D\u00e9couvrez pourquoi votre instance Redis est lente malgr\u00e9 la technologie en m\u00e9moire et comment un r\u00e9glage cibl\u00e9 de Redis am\u00e9liore consid\u00e9rablement les performances de mise en cache.<\/p>","protected":false},"author":1,"featured_media":15864,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[733],"tags":[],"class_list":["post-15871","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress"],"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":"3096","_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":null,"_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 tuning","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":"15864","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/15871","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=15871"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/15871\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/15864"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=15871"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=15871"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=15871"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}