From f199888f86a3793214db77faca9a89e8b3d24986 Mon Sep 17 00:00:00 2001 From: Daniel Allaire Date: Mon, 14 Sep 2026 09:16:33 -0400 Subject: [PATCH] redis : la correction d un fait faux, et la methode qui l a produit MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit L entree du 2026-09-13 affirmait aucun maxmemory configure. Faux : le grep visait /etc/redis/redis.conf alors que le role ecrit setops.conf. Interroge la ou la verite vit, redis repond maxmemory 268435456 et allkeys-lru. La conclusion ne change pas — redis reste hors de la table des planchers — mais sa raison change : il est borne a 256 Mo, il ne peut pas prendre la machine. Un fichier de configuration n est pas la configuration ; c est une de ses sources. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q --- CHANGELOG.md | 22 +++++++++++++++++++++- docs/audit/preuve-2026-09-14.md | 2 +- docs/carte-set-ops.md | 2 +- scripts/inventory_rules.py | 23 +++++++++++++++-------- 4 files changed, 38 insertions(+), 11 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index cd9a4d7..a5b4d58 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,25 @@ # CHANGELOG — Set-OPS +## 2026-09-14 (2) — Redis EST borne : le releve d'hier lisait le mauvais fichier + +L'entree du 2026-09-13 (6) affirmait « aucun `maxmemory` configure ». C'etait faux, et la +faute est de METHODE : le `grep` visait `/etc/redis/redis.conf`, alors que le role ecrit +dans `/etc/redis/setops.conf`. Interroge la ou la verite vit — `redis-cli config get` — +Redis repond : + + maxmemory 268435456 (256 Mo) + maxmemory-policy allkeys-lru + +**La conclusion ne change pas, sa raison si.** Redis reste hors de la table des planchers, +non plus parce qu'il serait sans limite, mais parce qu'il est BORNE a 256 Mo : il ne peut +pas prendre la machine, et lui epingler plusieurs gigaoctets serait absurde. + +Le commentaire porte desormais le bon seuil de vigilance : le jour ou ce plafond montera, +le plancher devra le suivre — et c'est le `maxmemory` EFFECTIF qu'il faudra lire. + +**La lecon est celle de la veille, appliquee a moi-meme :** verifier d'ou l'instrument +mesure. Un fichier de configuration n'est pas la configuration ; c'est une de ses sources. + ## 2026-09-13 (10) — Un runner TIRE ce qu'on pousse ; il ne le recoit pas Trois fois dans une meme soiree, un genome perime a menace de rebatir un etat depasse : @@ -135,7 +155,7 @@ Keycloak « parce qu'ils se dimensionnent au demarrage ». Releve sur les machin |--------------------------------------|-------------------------------| | `shared_buffers` derive de la RAM | **128 Mo**, le defaut Debian | | une JVM qui reserve son tas | **605 Mo** sur 3 Go | -| Redis « tout en memoire » | **16 Mo** residents, sans `maxmemory` | +| Redis « tout en memoire » | **16 Mo** residents, borne a 256 Mo | Ces machines tiennent du **cache de pages**, pas un jeu de donnees. Le reprendre ralentit des lectures — sur du NVMe — ; il ne fait pas swapper. Leurs planchers sont redescendus au diff --git a/docs/audit/preuve-2026-09-14.md b/docs/audit/preuve-2026-09-14.md index 5646414..e459c48 100644 --- a/docs/audit/preuve-2026-09-14.md +++ b/docs/audit/preuve-2026-09-14.md @@ -46,7 +46,7 @@ | P31 | Documentation : tout ce que le depot FAIT est nomme | — | ✅ OK | 65 scripts expliques et atteignables, 121 cibles make documentees, 68 roles avec README. | | P32 | Intrants exiges par les roles : tous fournis | — | ✅ OK | CONFORME : 38 exigence(s) de role, toutes satisfaites (149 cle(s) declaree(s) par l'instance). | | P33 | Aucune collision de port entre roles co-localises | — | ✅ OK | CONFORME : 34 revendication(s) de port, aucune collision entre roles co-localises (36 groupes). | -| P34 | Chaque document declare son lecteur | — | ✅ OK | 45 document(s) declarent leur lecteur (39 genere(s) exempte(s)). | +| P34 | Chaque document declare son lecteur | — | ✅ OK | 45 document(s) declarent leur lecteur (40 genere(s) exempte(s)). | | P35 | Toute application exigeant une base en a une au plan | — | ✅ OK | 5 application(s) exigeant une base l'ont toutes (4 entree(s) au registre). | | P36 | Tout detenteur d'etat porte une sauvegarde | — | ✅ OK | 9 hote(s) de l'ecosysteme et 3 du site detiennent de l'etat, tous porteurs de `client_backup` (9 groupe(s) au catalogue). | | P37 | Le placement du tenant existe chez son hebergeur | — | ✅ OK | placement confronte a l'hebergeur monte (SITE-Chezlepro) : noeud, stockage, pont — tous offerts. | diff --git a/docs/carte-set-ops.md b/docs/carte-set-ops.md index 76c7e07..f01675b 100644 --- a/docs/carte-set-ops.md +++ b/docs/carte-set-ops.md @@ -26,7 +26,7 @@ README de rôles). Cette page comble ces deux trous. | rôles | 68 | `roles/*/` | | README de rôles | 68 | `roles/*/README.md` — l'écart avec la ligne au-dessus est la dette | | documents | 41 | `docs/*.md` | -| pièces d'audit | 44 | `docs/audit/*` | +| pièces d'audit | 45 | `docs/audit/*` | | unités de wiki | 27 | `wiki/*.md` | | décisions en vigueur | 85 | lignes `\| **D-nn** \|` de `decisions-architecture.md` | | décisions renversées | 3 | lignes `\| **D-nn** —` du même document | diff --git a/scripts/inventory_rules.py b/scripts/inventory_rules.py index 70cb02e..1043eb1 100644 --- a/scripts/inventory_rules.py +++ b/scripts/inventory_rules.py @@ -976,16 +976,23 @@ PLANCHER_MEMOIRE = { "serveur_collabora": 0.75, # un document ouvert est un processus } -# REDIS N'EST PAS DANS CETTE TABLE, ET C'EST UNE MESURE (2026-09-13). « Tout en memoire -# par construction » justifiait un plancher de 1,00 — donc aucune reprise possible sur la -# machine qui le porte. Releve : 16 Mo residents, et aucun `maxmemory` configure. +# REDIS N'EST PAS DANS CETTE TABLE, ET C'EST UNE MESURE (2026-09-13, corrigee le 09-14). +# « Tout en memoire par construction » justifiait un plancher de 1,00 — donc aucune +# reprise possible sur la machine qui le porte. # -# Ce qu'il tient ici, ce sont des sessions et du cache applicatif, pas un jeu de donnees. -# L'epingler ferait garder plusieurs gigaoctets pour seize megaoctets. +# PREMIER RELEVE, ET IL ETAIT INCOMPLET : 16 Mo residents, « aucun `maxmemory` configure ». +# La seconde affirmation etait FAUSSE — elle venait d'un `grep` sur `/etc/redis/redis.conf`, +# alors que le role ecrit dans `/etc/redis/setops.conf`. Interroge la ou la verite vit, +# Redis repond `maxmemory 268435456` et `maxmemory-policy allkeys-lru`. # -# LE JOUR OU `maxmemory` SERA POSE, le plancher devra le suivre — un Redis borne a 2 Go -# doit garder 2 Go. Un Redis NON borne est d'ailleurs un sujet en soi : rien ne l'empeche -# aujourd'hui de consommer la machine entiere. +# LA CONCLUSION NE CHANGE PAS, SA RAISON SI. Redis est BORNE a 256 Mo : il ne peut pas +# prendre la machine, et epingler plusieurs gigaoctets pour un plafond de 256 Mo serait +# absurde. Ce qu'il tient, ce sont des sessions et du cache applicatif, pas un jeu de +# donnees. +# +# LE JOUR OU CE PLAFOND MONTERA, le plancher devra le suivre : un Redis borne a 2 Go doit +# garder 2 Go. Le seuil est le `maxmemory` EFFECTIF (`config get maxmemory`), pas ce qu'un +# fichier de configuration donne a lire. PLANCHER_DEFAUT = 0.50