# Crash de Gladys lors de la sauvegarde GladysPlus **URL:** \ **Category:** Configuration\ **Created:** [Septembre 9, 2026, 8:13 UTC](https://community.gladysassistant.com/t/crash-de-gladys-lors-de-la-sauvegarde-gladysplus/10845 "2026-09-09T08:13:18Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![StephaneB](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/stephaneb/32/15443_2.png) [@StephaneB](https://community.gladysassistant.com/u/StephaneB)\ **Post date:** [Septembre 9, 2026, 8:13 UTC](https://community.gladysassistant.com/t/crash-de-gladys-lors-de-la-sauvegarde-gladysplus/10845/1 "2026-09-09T08:13:19Z")
Je suis embêté depuis plusieurs semaines avec ma sauvegarde Gladys, mais je n’avais pas pris le temps de faire les vérifications nécessaires. En fait, chaque nuit quand la sauvegarde se déclenche, Gladys se bloque (plus d’affichage du dashboard, plus de déclenchement de scènes, …), cela dure environ 2h, puis je reçois dans Telegram le message « Gladys vient de redémarrer » (c’est le résultat d’une scène ayant pour déclencheur « Gladys démarre »), et tout fonctionne à nouveau. Avec l’aide de Claude ce matin, j’ai exploré le souci. Lors d’une étape de son analyse, j’ai répondu que j’avais « une base moyenne (quelques gigas) », mais je ne suis pas sûr d’avoir bien répondu. Dans l’historique de mes sauvegardes, je vois ça : ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/b/b/bb01af3ba3fd00abeccf9165aa654daefc4eca8b.png) En première action, Claude m’a suggéré de modifier la RAM allouée à Gladys (avec la commande `sudo docker update --memory="6g" --memory-swap="8g" gladys`), pour que mon souci ne provoque plus un blocage pendant plusieurs heures. Et effectivement quand j’ai relancé manuellement une sauvegarde, le crash et la remise en route se sont faits en 3-4 minutes. C’est mieux pour ne pas bloquer ma domotique, mais ça ne résoud pas encore le souci de sauvegarde en échec 😉 Je tourne sur un mini-PC Intel NUC5PPYB, processeur N3700 4 cœurs 1.6GHz, 8Go de RAM, sous Ubuntu 22.04, et Gladys a été installé avec la commande « docker run » standard. Je n’ai pas d’autre chose que Gladys sur ce serveur. Voilà le rapport final de Claude : # Pic mémoire / OOM-kill pendant la sauvegarde GladysPlus ## Résumé Chaque sauvegarde GladysPlus (automatique 2h-4h ou manuelle) fait grimper la RAM du conteneur Gladys au point de déclencher un OOM-kill du process Node, suivi d’un redémarrage automatique du conteneur. ## Environnement - Gladys en Docker sur Mini PC/NUC - RAM totale de l’hôte : 7,7 Go (8 Go non extensible) - Base de données : taille moyenne (quelques Go) - Conteneur `gladys` limité manuellement à 6 Go de RAM (`docker update --memory`) pour éviter que l’OOM ne déstabilise tout l’hôte (swap-thrashing observé avant la mise en place de cette limite) ## Reproduction Sauvegarde manuelle déclenchée à 09h36. - 09:36:01 - RSS avant backup : **4388,77 MB** , Heap 233,97/392,50 MB - 09:36:01 - DuckDB avant backup : **Total 2248,75 MB** (BASE\_TABLE: 2246,00 MB, IN\_MEMORY\_TABLE: 2,75 MB) - 09:36:04 - Ouverture d’une seconde instance DuckDB dédiée au backup (`duckDbCreateBackupInstance`, `memory_limit=1024MB`, `threads=2`, `READ_ONLY`) pour exporter vers un dossier Parquet - 09:38 - RAM du conteneur : ~6 Go (limite atteinte) - 09:40 - `Out of memory: Killed process ... (MainThread)` - 09:41 - Conteneur redémarré, Gladys de nouveau fonctionnel Sans la limite de 6 Go posée manuellement au niveau Docker, le même phénomène en conditions réelles (sauvegarde nocturne automatique) a provoqué un épisode de swap-thrashing sur l’hôte entier de **02h23 à 04h44** (dashboard et scènes inutilisables), le RSS du process ayant atteint 6774,54 MB avant kill (`dmesg` : `Out of memory: Killed process 1542 (MainThread) total-vm:30424440kB, anon-rss:6774536kB`). ## Hypothèse La nouvelle instance DuckDB créée pour le backup (limitée à 1024 MB) semble s’additionner à la mémoire déjà occupée par l’instance DuckDB principale (~2,25 Go), plutôt que de partager/respecter un budget mémoire global du process. Sur une machine où le process tourne déjà à ~4,4 Go au repos, l’ajout de ~1 Go supplémentaire suffit à dépasser la RAM disponible. ## Question pour les mainteneurs - Est-il normal que `BASE_TABLE` reste quasi intégralement en mémoire (2,25 Go) au repos, hors sauvegarde, pour une base de taille moyenne ? - Le `memory_limit=1024MB` de l’instance de backup peut-il être abaissé, ou le process de backup peut-il streamer/traiter par lots au lieu de charger autant en mémoire, pour rester dans une enveloppe totale raisonnable même sur du matériel à 8 Go de RAM ? ---
**Author:** ![StephaneB](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/stephaneb/32/15443_2.png) [@StephaneB](https://community.gladysassistant.com/u/StephaneB)\ **Post date:** [Septembre 9, 2026, 8:30 UTC](https://community.gladysassistant.com/t/crash-de-gladys-lors-de-la-sauvegarde-gladysplus/10845/2 "2026-09-09T08:30:12Z")
@pierre-gilles je ne suis pas sûr que tu auras le temps de regarder ça avant tes vacances… Ça attendra ton retour si ce n’est pas possible 😉 ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [Septembre 9, 2026, 8:32 UTC](https://community.gladysassistant.com/t/crash-de-gladys-lors-de-la-sauvegarde-gladysplus/10845/3 "2026-09-09T08:32:18Z")
Je laisse @mutmut t’aider 🙂 (ou quelqu’un d’autres!) ---
**Author:** ![mutmut](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/mutmut/32/14064_2.png) [@mutmut](https://community.gladysassistant.com/u/mutmut)\ **Post date:** [Septembre 9, 2026, 6:54 UTC](https://community.gladysassistant.com/t/crash-de-gladys-lors-de-la-sauvegarde-gladysplus/10845/4 "2026-09-09T18:54:11Z")
@StephaneB j’ai un bout de mes déboires ici : [Migration intégration Netatmo : plantage de Gladys - #4 par mutmut](https://community.gladysassistant.com/t/migration-integration-netatmo-plantage-de-gladys/10444/4) et ensuite là : [Surconsommation de mémoire par le backup de gateway? - #18 par mutmut](https://community.gladysassistant.com/t/surconsommation-de-memoire-par-le-backup-de-gateway/10387/18) Pour l’instant, la seule solution que j’ai trouvé pour ne plus être embêté c’est d’augmenter la ram 😕 Mais comme c’est un cluster proxmox, si le host plante, le lxc avec gladys va basculer sur un autre hôte et là je risque d’avoir des soucis de ram partagée… En tout cas quand ça freezait, j’arrivais à débloquer la situation en augmentant en live la ram (merci les LXC !), et toutes les tâches en attente se sont bien terminées. ---
**Author:** ![StephaneB](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/stephaneb/32/15443_2.png) [@StephaneB](https://community.gladysassistant.com/u/StephaneB)\ **Post date:** [Septembre 10, 2026, 7:02 UTC](https://community.gladysassistant.com/t/crash-de-gladys-lors-de-la-sauvegarde-gladysplus/10845/5 "2026-09-10T07:02:51Z")
Merci pour ce retour @mutmut. Je viens de vérifier, ma base de donnée duckdb fait 8Go. Et comme je ne peux malheureusement pas ajouter de RAM (8 Go max sur ce mini pc), je suis coincé… Est-ce qu’il y a des services dont on sait qu’ils consomment de la RAM et que je pourrais arrêter dans la page ‹ services › de Gladys, le temps de lancer manuellement une sauvegarde ? ---
**Author:** ![StephaneB](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/stephaneb/32/15443_2.png) [@StephaneB](https://community.gladysassistant.com/u/StephaneB)\ **Post date:** [Septembre 10, 2026, 6:37 UTC](https://community.gladysassistant.com/t/crash-de-gladys-lors-de-la-sauvegarde-gladysplus/10845/6 "2026-09-10T18:37:54Z")
Bon, j’ai réussi à faire une sauvegarde en coupant tous les services sauf node-red et mqtt, car je voulais continuer à tracer l’usage RAM et CPU que je fais tourner dans Node-Red (oui, il faudra que je bascule sur l’intégration externe…). Ça a fait baisser l’usage RAM d’environ -10%, passant d’environ 80% à 70%. J’ai alors lancé manuellement une sauvegarde. Gladys ne s’en est pas sorti, crash OOM. Mais au redémarrage, la RAM n’était utilisée que à 10% environ ! J’ai donc déclenché aussitôt une sauvegarde qui s’est bien passé. Dans la foulée, j’ai relancé tous les services et provoqué un redémarrage du mini-PC. L’usage RAM s’est stabilisé à 20% environ, top. Il était 19h20. Sauf qu’à 19h30, j’ai eu un pic de CPU mais surtout une montée de l’usage RAM à 60%, qui n’est pas redescendu depuis ! ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/9/0/90a808bfc344d9618847f7024f82e38fbd0c90aa.png) Est-ce le calcul du suivi d’énergie qui consomme beaucoup de RAM (pourquoi pas) mais ‹ ne la rend pas › ? ---
**Author:** ![cicoub13](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/cicoub13/32/4482_2.png) [@cicoub13](https://community.gladysassistant.com/u/cicoub13)\ **Post date:** [Septembre 10, 2026, 8:10 UTC](https://community.gladysassistant.com/t/crash-de-gladys-lors-de-la-sauvegarde-gladysplus/10845/7 "2026-09-10T20:10:32Z")
Ce n’est pas une fuite, c’est le buffer pool de DuckDB qui se remplit une fois et n’est jamais rendu à l’OS. DuckDB est ouvert avec **memory\_limit = 30 % de la RAM** (`models/index.js:214`). Son buffer manager prend la mémoire jusqu’à cette limite au premier gros scan et ne l’évince que sous sa propre pression, jamais pour rendre la RAM à l’OS. 20 % de base + ~30 % de buffer pool + le heap Node qui a grossi ≈ les 60 % observés. Le job de 19h30 est simplement le premier à faire des scans lourds (`getDeviceFeatureStates` sur une plage large après reboot, plus le `DELETE` + réinsertion de `calculateCostFrom`). Tu peux voir combien DuckDB s’alloue au démarrage avec cette commande : `docker logs gladys 2>&1 | grep "DuckDB initialized with memory_limit"` Tu peux tester une limite plus basse avec la variable `DUCKDB_MEMORY_LIMIT=512MB` dans ton docker-compose. Mais je ne sais pas si ça peut avoir des impacts négatifs sur le reste. Mais la deuxième instance (celle qui fait le backup) peut souffrir de cette non éviction. Je pense qu’il faudrait **réduire le pool principal pendant la sauvegarde** (pour forcer l’éviction et laisser la place pour la sauvegarde). C’est du développement à faire ---
**Author:** ![StephaneB](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/stephaneb/32/15443_2.png) [@StephaneB](https://community.gladysassistant.com/u/StephaneB)\ **Post date:** [Octobre 12, 2026, 6:59 UTC](https://community.gladysassistant.com/t/crash-de-gladys-lors-de-la-sauvegarde-gladysplus/10845/8 "2026-10-12T06:59:12Z")
@pierre-gilles je ne sais pas si tu aurais la possibilité de regarder comment m’aider sur ce souci avant ton « changement de vie », parce que je suis quand même bien embêté par le fait que les sauvegardes Gladys Plus ne fonctionnent plus chez moi (sauf quand je les provoque manuellement juste après un redémarrage de Gladys). Je ne sais pas dire si la solution suggérée par @cicoub13 serait efficace, ni si il s’agit d’un gros développement du core ou un petit détail que Claude va traiter en un tour de main… ---
**Author:** ![cursor-bot](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/cursor-bot/32/22252_2.png) [@cursor-bot](https://community.gladysassistant.com/u/cursor-bot)\ **Post date:** [Octobre 12, 2026, 7:52 UTC](https://community.gladysassistant.com/t/crash-de-gladys-lors-de-la-sauvegarde-gladysplus/10845/9 "2026-10-12T07:52:18Z")
Salut tout le monde ! Ce sujet est désormais **en cours de développement**. Une PR a été ouverte pour réduire le cache DuckDB pendant la sauvegarde Gladys Plus, afin d’éviter le crash OOM : > > > \### Description > > The nightly Gladys Plus backup still gets Gladys OOM-killed on …machines with a large DuckDB history and limited RAM (reported on an 8GB mini-PC with an 8GB \`.duckdb\` file: the host thrashes for ~2h, then Gladys restarts). > > \#2722 bounded the backup instance to 1GB and 2 threads, but that memory still comes \*\*on top\*\* of the main instance buffer pool. That pool fills up to its \`memory\_limit\` (30% of the RAM by default, so ~2.3GB on an 8GB host) and DuckDB keeps it as a cache: it never gives it back on its own. The reporter's logs show it: \`BASE\_TABLE: 2246 MB\` at rest, RSS 4.4GB before the backup, then +~1.2GB during the export, which hits the 6GB container limit and triggers the OOM kill. A backup started right after a restart (empty pool) succeeds. > > \*\*Fix\*\* (suggested by @cicoub13 on the forum): while the export runs, the main instance \`memory\_limit\` is lowered to 512MB, then restored to its configured value. > \- Lowering the limit makes DuckDB evict the cached blocks down to the new limit and hand the memory back to the OS (jemalloc is loaded in the Node bindings), which makes room for the backup instance. > \- It is only done when the main limit is parseable and above 512MB, so the limit is never raised. > \- If the limit cannot be lowered (blocks pinned by a running query), the backup runs exactly as before, with a warning. > \- The original limit is restored in a \`finally\` block. A restore failure is logged and does not hide the export's own result or error. > > \*\*Trade-off:\*\* for the few minutes of the export, production DuckDB queries run with a 512MB cache. They are slower, and DuckDB spills to its temp directory if needed. The cache refills lazily afterwards. > > \*\*Measured\*\* on a synthetic 3.4GB DuckDB file (120M states, same \`@duckdb/node-api\` 1.4.4-r.4), main limit 2GB, pool warmed up by a full scan: > > | Strategy | Peak RSS during export | RSS after | > |---|---|---| > | Before this PR (backup instance at 1GB on top of the full main pool) | 3240 MB (+1.2GB over rest) | 2055 MB | > | Main limit lowered to 256MB during the export | 1527 MB (RSS drops to 352 MB as soon as the limit is lowered) | 355 MB | > > With 512MB, the peak is roughly the reduced pool plus the backup instance, which stays below the resting RSS of any installation whose main limit is ≥ ~1.7GB, the case reported here. > > Files: > \- \`server/models/index.js\`: new \`duckDbRunWithReducedMemoryLimit(task)\`. > \- \`server/lib/gateway/gateway.backup.js\`: the backup instance creation and the export run inside it. > \- Tests: unit tests for every branch (lowered/restored, task failure, lowering failure, restore failure, limit already ≤ 512MB, unparseable limit), plus an integration test on the real DuckDB checking the order (reduce → create backup instance → restore) and that \`memory\_limit\` is back to its original value after the backup. > > Workaround until this ships, for affected users: set \`DUCKDB\_MEMORY\_LIMIT=1GB\` on the container. > > \### Related request > > Forum: https://community.gladysassistant.com/t/crash-de-gladys-lors-de-la-sauvegarde-gladysplus/10845 > > \### Checklist > > \- \[x\] If a forum topic or GitHub issue exists, the description links it (\`Forum: https://community.gladysassistant.com/t/...\` or \`Closes #...\`) > \- \[x\] Tests pass: \`cd server && npm run coverage\`. 8100 passing; every changed line is covered (checked against the lcov report). 11 tests fail locally in this sandbox (Gladys Plus gateway controller and integration host container tests). They fail identically on \`master\` here because of network/Docker restrictions, and they are untouched by this PR. No UI change, so no Cypress run. > \- \[x\] Linter and prettier pass on both front and server (\`npm run eslint\`, \`npm run prettier\`). Server only, no front change. > \- \[x\] No undocumented breaking change > > 🤖 Generated with \[Claude Code\](https://claude.com/claude-code) > > https://claude.ai/code/session\_01TJbXQoexCvoNoJJzZEpxNu > > \--- > \_Generated by \[Claude Code\](https://claude.ai/code/session\_01TJbXQoexCvoNoJJzZEpxNu)\_ N’hésitez pas à suivre la PR, à tester (optionnel, surtout pour les petites demandes) et à faire vos retours ici si besoin. ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [Octobre 12, 2026, 8:03 UTC](https://community.gladysassistant.com/t/crash-de-gladys-lors-de-la-sauvegarde-gladysplus/10845/10 "2026-10-12T08:03:36Z")
Salut @StephaneB, Je pensais que ton souci était réglé : @cicoub13 t’avait proposé une piste de correctif (baisser `DUCKDB_MEMORY_LIMIT`) et tu ne lui avais pas répondu ensuite, donc j’en avais conclu que c’était bon de ton côté 🙂 J’ai regardé ça de près, et l’analyse de @cicoub13 était la bonne : - DuckDB garde en cache une partie de ta base, jusqu’à sa limite mémoire. Par défaut c’est 30 % de la RAM, soit environ 2,3 Go chez toi : c’est ton `BASE_TABLE` à 2,25 Go au repos. Ce cache n’est jamais rendu. - Pendant la sauvegarde, une seconde instance DuckDB s’ouvre pour l’export (limitée à 1 Go), et sa mémoire vient s’ajouter à ce cache plein. Sur une machine de 8 Go qui tourne déjà à 4,4 Go, ça suffit à déclencher l’OOM. - C’est pour ça qu’une sauvegarde lancée juste après un redémarrage passe : le cache est encore vide. J’ai fait une PR qui applique la proposition de @cicoub13. Pendant l’export, le cache de l’instance principale est réduit à 512 Mo, puis remis à sa valeur normale à la fin. Comme ça, la mémoire de la sauvegarde ne s’ajoute plus à un cache plein : [#3190](https://github.com/GladysAssistant/Gladys/pull/3190) **En attendant la prochaine version** , tu peux contourner le problème en limitant le cache DuckDB à 1 Go. Il faut recréer le conteneur : `docker stop gladys && docker rm gladys`, puis ta commande `docker run` habituelle avec `-e DUCKDB_MEMORY_LIMIT=1GB` en plus. Pour vérifier que c’est pris en compte : ```auto docker logs gladys 2>&1 | grep "DuckDB initialized with memory_limit" ``` Tu peux garder ta limite Docker de 6 Go en filet de sécurité. ---
**Author:** ![StephaneB](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/stephaneb/32/15443_2.png) [@StephaneB](https://community.gladysassistant.com/u/StephaneB)\ **Post date:** [Octobre 12, 2026, 11:34 UTC](https://community.gladysassistant.com/t/crash-de-gladys-lors-de-la-sauvegarde-gladysplus/10845/11 "2026-10-12T11:34:57Z")
Merci pour les explications, et surtout merci d’avance pour la correction ! ---
**Author:** ![cicoub13](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/cicoub13/32/4482_2.png) [@cicoub13](https://community.gladysassistant.com/u/cicoub13)\ **Post date:** [Octobre 26, 2026, 8:57 UTC](https://community.gladysassistant.com/t/crash-de-gladys-lors-de-la-sauvegarde-gladysplus/10845/12 "2026-10-26T20:57:12Z")
C’est merge et disponible en v5.3 Tu nous diras si ça té débloque ?