# Surconsommation de mémoire par le backup de gateway?

**URL:** <https://community.gladysassistant.com/t/surconsommation-de-memoire-par-le-backup-de-gateway/10387>\
**Category:** Configuration\
**Created:** [Juillet 28, 2026, 9:04 UTC](https://community.gladysassistant.com/t/surconsommation-de-memoire-par-le-backup-de-gateway/10387 "2026-07-28T21:04:08Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![lmilcent](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/lmilcent/32/7023_2.png) [@lmilcent](https://community.gladysassistant.com/u/lmilcent)\
**Post date:** [Juillet 28, 2026, 9:04 UTC](https://community.gladysassistant.com/t/surconsommation-de-memoire-par-le-backup-de-gateway/10387/1 "2026-07-28T21:04:08Z")

</div>

Salut,

Je ne sais pas si je suis le seul, mais j’ai des erreurs de OOM régulièrement, lorsque j’attribue 8Gb a Gladys. Cela provoque un redémarrage de Gladys toute les nuits.

Après des jours de débug, sans comprendre la cause, j’ai utilisé Claude pour avancer et identifier une meilleure hypothèse. Et les jours suivants le problème est identifié : la manière dont la base de données est sauvegardée.

Contexte : je garde tous les états a l’infini, tant que j’ai du disque.

Est ce que je suis le seul a qui ça arrive ?

* * *

Bug : le backup Gateway peut provoquer un OOM-kill du process Node

Composants concernés :  
`server/lib/gateway/gateway.backup.js`  
`server/models/index.js` (fonction duckDbCreateBackupInstance)

Le problème : duckDbCreateBackupInstance() ouvre une nouvelle instance DuckDB séparée sur le même fichier .duckdb que l’instance principale (déjà active en lecture/écriture) :

```javascript
const backupDatabase = await DuckDBInstance.create(duckDbFilePath, {
  memory_limit: duckDbMemoryLimit,
  access_mode: 'READ_ONLY',
});

```

Or la documentation officielle du client Node.js « Neo » de DuckDB dit explicitement :

> «&nbsp;Multiple instances in the same process should not attach the same database.&nbsp;»

Le mécanisme prévu pour éviter ça est DuckDBInstanceCache.getOrCreateInstance(path), qui réutilise la même instance (donc le même buffer pool / memory\_limit) pour un même fichier. Le code actuel appelle DuckDBInstance.create() directement, ce qui crée deux buffer pools indépendants, chacun plafonné au même DUCKDB\_MEMORY\_LIMIT.

Résultat : le pire cas mémoire de DuckDB seul devient 2 × memory\_limit au lieu de 1 × memory\_limit.

Aggravant : la doc DuckDB précise aussi que memory\_limit «&nbsp;only applies to the buffer manager&nbsp;» — les buffers de compression (COMPRESSION GZIP utilisé dans l’EXPORT DATABASE) peuvent consommer en plus de cette limite.

Preuve en prod (2 crashs identiques, logs à l’appui) :

- RSS stable ~2,5 Go avant backup (dont ~1,2 Go de BASE\_TABLE DuckDB)
- Passage à ~4,6 Go en moins d’une minute, juste après le log «&nbsp;Backing up DuckDB into a Parquet folder&nbsp;»
- Process tué (ExitCode=137) avant d’atteindre le log «&nbsp;Closing DuckDB backup instance to release memory&nbsp;» dans le finally — donc le crash survient bien pendant l’appel EXPORT DATABASE … FORMAT PARQUET COMPRESSION GZIP lui-même, pas après.
- Reproduit à l’identique 2 jours de suite, toujours au moment du backup Gateway quotidien.

Ce qui est demandé :

1. Faire en sorte que duckDbCreateBackupInstance() utilise DuckDBInstanceCache.getOrCreateInstance() au lieu de DuckDBInstance.create(), pour que le backup partage le buffer pool de l’instance principale plutôt que d’en ouvrir un second.
2. Envisager de remplacer COMPRESSION GZIP par ZSTD ou SNAPPY dans l’EXPORT DATABASE (moins de buffers de compression, export plus rapide).
3. Éventuellement documenter que DUCKDB\_MEMORY\_LIMIT doit être dimensionné en anticipant que deux instances peuvent coexister pendant un backup (donc recommander une valeur ≤ 25% de la RAM allouée au conteneur, pas 30-50%), tant que le point 1 n’est pas corrigé.

Contexte pour situer l’impact : installation avec ~8 Go alloués au conteneur, BASE\_TABLE d’environ 1,1-1,2 Go d’historique de capteurs — donc pas un cas extrême, ce comportement peut probablement toucher d’autres installations avec un historique conséquent.

---

<div class="post-metadata">

**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:** [Juillet 28, 2026, 10:06 UTC](https://community.gladysassistant.com/t/surconsommation-de-memoire-par-le-backup-de-gateway/10387/2 "2026-07-28T22:06:11Z")

</div>

> [@lmilcent](#):
>
> Est ce que je suis le seul a qui ça arrive ?

Et bien figure toi que j’ai le même soucis depuis 7 jours !  
Par contre je dois redémarrer tous les matins mon LXC docker avec Gladys car plus rien ne répond.

Je suis avec Claude qui doit me pondre un watchdog et un restart auto après plantage, avec une récup des logs juste avant l’OOM car après cela je n’ai plus accès à rien.

Je te tiens au courant.

---

<div class="post-metadata">

**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:** [Juillet 29, 2026, 7:20 UTC](https://community.gladysassistant.com/t/surconsommation-de-memoire-par-le-backup-de-gateway/10387/3 "2026-07-29T07:20:44Z")

</div>

Merci du retour, je vais regarder !

---

<div class="post-metadata">

**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:** [Juillet 29, 2026, 7:30 UTC](https://community.gladysassistant.com/t/surconsommation-de-memoire-par-le-backup-de-gateway/10387/4 "2026-07-29T07:30:08Z")

</div>

Pour la première fois ce matin, ça n’a pas planté, pas de OOM :

 ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/8/7/87b7ee2c4710b9022d6b323c26d3f94ff38ce77d.png)  
 ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/3/d/3dd2c80e338c0d736494b8835b37c9b32811d24c.png)  
 ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/8/c/8cadc3e70490fea6df4e46c1c349c194e7549bf9.png)  
Et je n’ai pas encore mis le script en place ☹

---

<div class="post-metadata">

**Author:** ![lmilcent](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/lmilcent/32/7023_2.png) [@lmilcent](https://community.gladysassistant.com/u/lmilcent)\
**Post date:** [Juillet 29, 2026, 7:43 UTC](https://community.gladysassistant.com/t/surconsommation-de-memoire-par-le-backup-de-gateway/10387/5 "2026-07-29T07:43:03Z")

</div>

Depuis que j’ai modifié mon docker compose pour limiter DuckDB a 2Gb max au lieu de 4Go, plus de plantage (cette nuit en tout cas). Ce qui confirme que c’est la bonne direction.

---

<div class="post-metadata">

**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:** [Juillet 29, 2026, 7:46 UTC](https://community.gladysassistant.com/t/surconsommation-de-memoire-par-le-backup-de-gateway/10387/6 "2026-07-29T07:46:22Z")

</div>

Le mien était déjà limité à 2Go depuis les premiers soucis d’OOM.  
Quand ça a recommencé il y a 1 semaine, j’ai même limité à 1.5Go mais sans succès.

```auto
version: '3'

services:
  gladys:
    image: gladysassistant/gladys:v4
    container_name: gladys
    restart: always
    privileged: true
    network_mode: host
    cgroup: host
    logging:
      driver: "json-file"
      options:
        max-size: 10m
    environment:
      NODE_ENV: production
      SQLITE_FILE_PATH: /var/lib/gladysassistant/gladys-production.db
      SERVER_PORT: 8420
      TZ: Europe/Paris
      DUCKDB_MEMORY_LIMIT: 1500MB # limitation utilisation memoire duckDB

```

---

<div class="post-metadata">

**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:** [Juillet 29, 2026, 7:49 UTC](https://community.gladysassistant.com/t/surconsommation-de-memoire-par-le-backup-de-gateway/10387/7 "2026-07-29T07:49:15Z")

</div>

> [@lmilcent](#):
>
> Depuis que j’ai modifié mon docker compose pour limiter DuckDB a 2Gb max au lieu de 4Go

Normalement @pierre-gilles a déjà mis en place une limitation de xx% pour duckDB en automatique (je ne me rappelle plus le chiffre exact), ce qui fonctionne très bien sauf pour les installations avec proxmox où la valeur de la RAM du LXC n’est pas bien récupérée par docker, et dans ce cas il faut effectivement limiter (sauf si RAM LXC = RAM host).

---

<div class="post-metadata">

**Author:** ![lmilcent](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/lmilcent/32/7023_2.png) [@lmilcent](https://community.gladysassistant.com/u/lmilcent)\
**Post date:** [Juillet 29, 2026, 11:38 UTC](https://community.gladysassistant.com/t/surconsommation-de-memoire-par-le-backup-de-gateway/10387/8 "2026-07-29T11:38:17Z")

</div>

C’est exactement ça oui, LXC avec 8Gio, docker qui voit les 64Gio du serveur, et OOM.

C’est clairement pas un problème «&nbsp;mainstream&nbsp;» mais c’est deja arrivé plusieurs fois a ce que je vois !

---

<div class="post-metadata">

**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:** [Juillet 29, 2026, 5:46 UTC](https://community.gladysassistant.com/t/surconsommation-de-memoire-par-le-backup-de-gateway/10387/9 "2026-07-29T17:46:34Z")

</div>

Salut @lmilcent,

Effectivement, il y a 3 phénomènes distincts ici 😃

**1. L’instance séparée pour le backup, c’est voulu.** On ouvre bien une instance DuckDB 100 % séparée pour générer le backup, et oui, du coup ça permet à DuckDB d’utiliser temporairement 2× la limite autorisée pendant le backup. On fait ça pour isoler le backup de la production et surtout pour pouvoir relâcher la RAM à la fin : fermer l’instance rend toute sa mémoire à l’OS. Si on réutilisait l’instance de production, on resterait certes sous les ×2 pendant le backup, mais l’export remplirait le buffer pool de prod jusqu’à 100 % de la limite **sans jamais la relâcher** , pour DuckDB c’est du cache, il le garde à vie. Or garder toute la base en cache à cause d’un backup de 10 minutes par nuit, c’est pas terrible ^^

**2. Dans ton cas, le vrai problème vient de LXC.** La limite RAM du container n’est pas visible depuis l’intérieur : Node calcule les 30 % sur les 64 Go du serveur, soit ~19 Go de limite DuckDB… beaucoup trop pour un container de 8 Go, et ×2 pendant le backup. En attendant, tu peux forcer une limite adaptée dans la config de ton container, par exemple :

```auto
DUCKDB_MEMORY_LIMIT=2GB

```

(~25 % des 8 Go alloués, ça laisse la place pour le pic du backup.)

**3. Pourquoi seulement maintenant ?** Tu n’avais probablement pas vu le problème les mois précédents car ta base était plus petite. Avec l’accumulation des états, l’export monte de plus en plus haut en RAM, jusqu’à déclencher l’OOM.

Pour améliorer la détection automatique de la limite mémoire, j’ai des pistes (lire la limite cgroup via `process.constrainedMemory()` de Node), mais de mémoire on avait fait pas mal d’essais peu fructueux sur LXC…

Pour re-tester à nouveau, est-ce que tu pourrais exécuter ces 3 commandes et poster le résultat ?

**Ce que Node voit depuis le container Gladys :**

```bash
docker exec gladys node -e "const os=require('os'); \
console.log('os.totalmem =', Math.round(os.totalmem()/1048576), 'MB'); \
console.log('process.constrainedMemory =', Math.round((process.constrainedMemory()||0)/1048576), 'MB'); \
console.log('process.availableMemory =', process.availableMemory ? Math.round(process.availableMemory()/1048576)+' MB' : 'n/a')"

```

**Les limites cgroup vues du container :**

```bash
docker exec gladys sh -c 'echo "cgroup v2 : $(cat /sys/fs/cgroup/memory.max 2>/dev/null || echo absent)"; \
echo "cgroup v1 : $(cat /sys/fs/cgroup/memory/memory.limit_in_bytes 2>/dev/null || echo absent)"; \
echo "meminfo : $(head -1 /proc/meminfo)"'

```

**La limite que Gladys a réellement appliquée :**

```bash
docker logs gladys 2>&1 | grep -i "memory_limit"

```

Si `process.constrainedMemory` renvoie bien tes 8 Go (ou que `memory.max` / cgroup v1 montre la vraie limite), on pourra corriger le calcul automatiquement pour tout le monde. S’il renvoie 0 ou la RAM de l’hôte, on partira plutôt sur de la doc en plus sur `DUCKDB_MEMORY_LIMIT`.

---

<div class="post-metadata">

**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:** [Juillet 29, 2026, 7:44 UTC](https://community.gladysassistant.com/t/surconsommation-de-memoire-par-le-backup-de-gateway/10387/10 "2026-07-29T19:44:42Z")

</div>

Salut @pierre-gilles , je me permets de te donner mes résultats de tests :

> [@pierre-gilles](#):
>
> **Ce que Node voit depuis le container Gladys :**

```bash
root@gladys:~# docker exec gladys node -e "const os=require('os'); \
console.log('os.totalmem =', Math.round(os.totalmem()/1048576), 'MB'); \
console.log('process.constrainedMemory =', Math.round((process.constrainedMemory()||0)/1048576), 'MB'); \
console.log('process.availableMemory =', process.availableMemory ? Math.round(process.availableMemory()/1048576)+' MB' : 'n/a')"
os.totalmem = 15748 MB
process.constrainedMemory = 17592186044416 MB
process.availableMemory = 6574 MB

```

```bash
root@gladys:~# docker exec gladys sh -c 'echo "cgroup v2 : $(cat /sys/fs/cgroup/memory.max 2>/dev/null || echo absent)"; \
echo "cgroup v1 : $(cat /sys/fs/cgroup/memory/memory.limit_in_bytes 2>/dev/null || echo absent)"; \
echo "meminfo : $(head -1 /proc/meminfo)"'
cgroup v2 : max
cgroup v1 : absent
meminfo : MemTotal: 16125760 kB

```

```bash
root@gladys:~# docker logs gladys 2>&1 | grep -i "memory_limit"
root@gladys:~# 

```

Bien entendu, c’est ce qui est vu depuis le LXC, pas depuis le docker de Gladys.  
Mon LXC a 6Go de RAM, mon host a 16Go.

---

<div class="post-metadata">

**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:** [Juillet 29, 2026, 7:57 UTC](https://community.gladysassistant.com/t/surconsommation-de-memoire-par-le-backup-de-gateway/10387/11 "2026-07-29T19:57:09Z")

</div>

> [@pierre-gilles](#):
>
> car ta base était plus petite

alors je n’avais pas pensé à ça pour mes problèmes qui sont réapparus 🙄

Ma base duckdb frôle les 6Go 😳  
Et c’est normal les (1) et (2) ? (J’avoue ne pas me rappeler ce que j’ai fait le 22/06 …)

```bash
root@gladys:/var/lib/gladysassistant# ls -al
total 6612704
drwxr-xr-x 15 root root 4096 Jul 29 16:53 .
drwxr-xr-x 22 root root 4096 Jul 14 23:57 ..
drwxr-xr-x 3 root root 4096 Jul 29 02:55 backups
-rw-r----- 1 root root 12009472 Jun 22 11:36 'gladys-production(1).db'
-rw-r----- 1 root root 706248704 Jun 22 11:36 'gladys-production(1).duckdb'
-rw-r----- 1 root root 12009472 Jun 22 15:25 'gladys-production(2).db'
-rw-r----- 1 root root 12009472 Jul 29 22:08 gladys-production.db
-rw-r----- 1 root root 32768 Jul 29 22:08 gladys-production.db-shm
-rw-r----- 1 root root 4120032 Jul 29 22:08 gladys-production.db-wal
-rw-r----- 1 root root 5994196992 Jul 29 16:53 gladys-production.duckdb
-rw-r--r-- 1 root root 9957883 Jun 22 11:36 'gladys-production.duckdb(1).wal'
-rw-r--r-- 1 root root 5194409 Jun 22 15:25 'gladys-production.duckdb(2).wal'
-rw-r--r-- 1 root root 15536313 Jul 29 22:08 gladys-production.duckdb.wal
drwxr-xr-x 2 root root 4096 May 11 2025 homekit
drwxr-xr-x 2 root root 4096 Jun 22 11:36 'homekit(1)'
drwxr-xr-x 2 root root 4096 Jun 22 15:25 'homekit(2)'
drwxr-xr-x 3 root root 4096 May 11 2025 matter
drwxr-xr-x 3 root root 4096 Jun 22 11:35 'matter(1)'
drwxr-xr-x 3 root root 4096 Jun 22 15:25 'matter(2)'
drwxr-xr-x 2 root root 4096 May 11 2025 mosquitto
drwxr-xr-x 2 root root 4096 Jun 22 11:36 'mosquitto(1)'
drwxr-xr-x 2 root root 4096 Jun 22 15:25 'mosquitto(2)'
drwxr-xr-x 5 1000 1000 4096 Feb 21 20:28 node-red
drwxr-xr-x 5 root root 4096 Jun 22 11:37 'node-red(1)'
drwxr-xr-x 5 root root 4096 Jun 22 15:25 'node-red(2)'

```

Bon j’ai mis en place un watchdog et capture de log de Claude et je vais voir ce que ça donne sur les prochains jours.  
A la limite, je vais repasser de 1.5GB à 2GB comme avant fin de semaine.

@lmilcent , si tu veux les scripts et la conversation que Claude m’a fait pour mettre en place sur ton proxmox, je peux te les fournir sans soucis, il faudra ajuster les chemins.

---

<div class="post-metadata">

**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:** [Juillet 30, 2026, 5:35 UTC](https://community.gladysassistant.com/t/surconsommation-de-memoire-par-le-backup-de-gateway/10387/12 "2026-07-30T17:35:36Z")

</div>

Salut @mutmut,

Merci pour ces retours, c’est exactement ce qu’il nous fallait ! Tes résultats confirment le diagnostic, et malheureusement ils montrent aussi qu’on ne pourra pas détecter la limite automatiquement dans ton setup :

- `process.constrainedMemory = 17592186044416` : c’est exactement 2⁴⁴ octets = 16 To, la valeur «&nbsp;pas de limite&nbsp;». Cohérent avec ton cgroup v2 à `max` : ton conteneur Docker n’a pas de limite mémoire propre, et les 6 Go de ton LXC sont définis dans un cgroup _parent_, invisible depuis l’intérieur du conteneur.
- `MemTotal = 16 Go` : le `/proc/meminfo` vu par Gladys montre ton hôte, pas ton LXC. C’est le piège du Docker-dans-LXC : lxcfs virtualise bien le `/proc` du LXC, mais Docker monte son propre procfs directement depuis le kernel, en contournant lxcfs.
- `process.availableMemory = 6574 MB` : trompeur, ça ressemble à tes 6 Go de LXC, mais c’est en fait la mémoire _disponible_ de ton hôte à cet instant, qui tombe par coïncidence près de 6 Go. Inutilisable pour un calcul fiable.

Concrètement, chez toi Gladys calculait donc sa limite DuckDB sur les 16 Go de l’hôte : 30 % ≈ 4,7 Go, et jusqu’à ×2 pendant le backup ≈ 9,4 Go potentiels… dans un conteneur de 6 Go. L’OOM était garanti dès que ta base a grossi.

**Donc : garde bien ton `DUCKDB_MEMORY_LIMIT` défini explicitement** , c’est la seule solution fiable en Docker-dans-LXC, et on va le documenter clairement pour les utilisateurs Proxmox/LXC.

Deux points quand même :

1. Tu dis crasher encore avec une limite à 1,5 Go : ça, c’est intéressant, car ça suggère qu’une partie de la mémoire de l’export échappe à la limite (le `memory_limit` de DuckDB gouverne son buffer pool, mais les buffers du writer Parquet et de la compression GZIP sont partiellement hors comptage). Les logs de ton watchdog juste avant un crash nous aideraient beaucoup à confirmer ça, je suis preneur !
2. Ton `docker logs | grep memory_limit` vide est bizarre : Gladys logge `DuckDB initialized with memory_limit=...` à chaque démarrage. Tes logs ont probablement tourné, tu peux revérifier juste après un restart du conteneur ?

Côté correctif, voilà ce qu’on prépare :

- **Borner fortement la mémoire du backup lui-même** : l’instance DuckDB temporaire du backup aura sa propre limite, beaucoup plus petite (~1 Go max au lieu de la limite complète). L’export est un scan séquentiel, il n’a pas besoin d’un gros cache. Le pic passera de «&nbsp;2× la limite&nbsp;» à «&nbsp;limite + ~1 Go&nbsp;», et ça protège tout le monde, même quand la détection est impossible.
- **Passer l’export de GZIP à ZSTD** : moins de mémoire, meilleure compression.
- **Mieux calculer la limite par défaut** : prise en compte de la limite cgroup quand elle est visible (Docker avec `--memory`), et plafond absolu pour les gros hôtes. Ça ne peut pas aider ton cas LXC, mais ça évitera le problème à beaucoup d’autres.

Et pour tes fichiers dupliqués `(1)` et `(2)` du 22 juin : ce sont probablement des restes de copies que tu aurais faites à la main ? Vérifie leur taille avec un `ls -lh` dans le dossier. Si ce sont bien des copies datées, tu peux les supprimer pour récupérer de l’espace disque (en gardant bien les DB de prod évidemment, et leur `.wal`, et leur `-shm`).

---

<div class="post-metadata">

**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:** [Juillet 31, 2026, 8:41 UTC](https://community.gladysassistant.com/t/surconsommation-de-memoire-par-le-backup-de-gateway/10387/13 "2026-07-31T08:41:17Z")

</div>

Merci @pierre-gilles pour toutes ces info !

Après 2 jours sans plantage, ce matin j’ai eu un soucis.

 ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/f/f/ff58dd35defdf1eb28a49222e5c5813c04af3e3e.png)

Par contre les scripts mis en place avec Claude ont permis de détecter la fuite, enregistrer les logs (je t’envoie ça en PM) et de redémarrer le docker Gladys donc c’est bien sur cette partie.

---

<div class="post-metadata">

**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:** [Août 1, 2026, 8:07 UTC](https://community.gladysassistant.com/t/surconsommation-de-memoire-par-le-backup-de-gateway/10387/14 "2026-08-01T08:07:24Z")

</div>

Claude m’a fait une proposition de PR avec tous les retours listé dans mon précédent message 🙂

> <https://github.com/GladysAssistant/Gladys/pull/2722>
>
> \### Pull Request check-list
> 
> \- \[x\] If your changes affect the code, did you writ…e the tests?
> \- \[\] Are server tests passing with coverage? (\`cd server && npm run coverage\`) — Codecov requires \*\*100% coverage on lines changed in this PR\*\* (targeted suites pass locally: \`test/models/index.test.js\`, \`test/lib/gateway/gateway.backup.test.js\`, \`test/lib/gateway/gateway.restoreBackup.test.js\`; full coverage run pending CI)
> \- \[\] Did Cypress E2E tests pass? (no UI change)
> \- \[x\] Is the linter passing? (\`npm run eslint\` on both front/server)
> \- \[x\] Did you run prettier? (\`npm run prettier\` on both front/server)
> \- \[\] If you are adding a new feature/service, did you run the integration comparator? (not applicable)
> \- \[\] Did you test this pull request in real life? With real devices? — the AMD64 preview image of this PR should be shared on the \[community topic\](https://community.gladysassistant.com/t/surconsommation-de-memoire-par-le-backup-de-gateway/10387) so affected users can validate
> \- \[\] If your changes modify the API (REST or Node.js), did you modify the API documentation? (no API change)
> \- \[\] If you are adding a new features/services which needs explanation, did you modify the user documentation? — \`DUCKDB\_MEMORY\_LIMIT\` / \`DUCKDB\_BACKUP\_MEMORY\_LIMIT\` should be documented for Proxmox/LXC users (v4-website)
> \- \[\] Did you add fake requests data for the demo mode? (not applicable)
> 
> \### Description of change
> 
> The nightly Gladys Plus backup can get Gladys OOM-killed (exit code 137) while exporting DuckDB to Parquet. Reported and diagnosed on the community forum: \[Surconsommation de mémoire par le backup de Gateway\](https://community.gladysassistant.com/t/surconsommation-de-memoire-par-le-backup-de-gateway/10387).
> 
> Two root causes, three changes:
> 
> \*\*1. The backup export could use up to 2× the DuckDB memory limit.\*\*
> The backup opens a second, short-lived DuckDB instance on the same file (intentional since #2420, so that its memory is fully released when it closes). But each instance gets its own buffer pool capped at \`DUCKDB\_MEMORY\_LIMIT\`, so the peak during the backup was \`2 × limit\`. The export is a streaming scan that doesn't benefit from a full-size cache, so the backup instance now gets:
> \- its own much smaller memory limit: \`min(1GB, main limit)\`, overridable via a new \`DUCKDB\_BACKUP\_MEMORY\_LIMIT\` env var,
> \- \`threads: 2\`, because part of the Parquet writer/compression buffers is allocated outside what \`memory\_limit\` tracks, and that untracked memory grows with the thread count.
> 
> The peak goes from \`2 × limit\` to \`limit + ~1GB\`, and the release-on-close behavior is preserved.
> 
> \*\*2. The "30% of RAM" default was computed on the host's RAM, not the container's.\*\*
> \`os.totalmem()\` is implemented with the \`sysinfo\` syscall, which is not namespaced (and lxcfs only virtualizes \`/proc\` files, not syscalls), so inside Docker/LXC it returns the \*\*host\*\* total memory. Diagnostics from an affected user (16GB host, 6GB LXC) confirmed the default limit was computed as 30% of 16GB ≈ 4.7GB — already close to the whole container allocation, and ×2 during backup. The default now:
> \- also honors the cgroup limit when it is visible (\`process.constrainedMemory()\`, ignoring the "no limit" sentinel), which fixes plain Docker with \`--memory\`,
> \- is capped at 4GB in absolute terms to protect large hosts.
> 
> Note: in Docker-inside-LXC setups, no interface exposes the real container limit from inside the Docker container (the LXC limit lives in an ancestor cgroup, and \`/proc/meminfo\` bypasses lxcfs), so those users still need to set \`DUCKDB\_MEMORY\_LIMIT\` explicitly — to be documented on the website.
> 
> \*\*3. Parquet export compression switched from GZIP to ZSTD.\*\*
> Better compression ratio with fewer memory buffers during the export. Restore is unaffected: \`IMPORT DATABASE\` reads both codecs (the restore test suite imports the existing GZIP fixture and passes unchanged).
> 
> \### Tests
> 
> \- New unit tests on the default memory limit computation (cgroup limit honored when lower than host RAM, 4GB cap, "no limit" sentinel ignored) and on the backup instance options (dedicated limit, \`READ\_ONLY\`, reduced threads).
> \- The existing backup/restore integration tests run the real ZSTD export and re-import the old GZIP fixture, covering both codecs.
> 
> 🤖 Generated with \[Claude Code\](https://claude.com/claude-code)
> 
> https://claude.ai/code/session\_01XKfbKkG6KroB79NZqdHqt1
> 
> 
> \## Summary by CodeRabbit
> 
> \- \*\*New Features\*\*
> - Improved backup efficiency by exporting Parquet using \*\*ZSTD\*\* compression.
> - Made DuckDB memory configuration \*\*container-aware\*\* with safer defaults, clearer reporting, and a \*\*separate backup memory limit\*\*.
> - Set fixed backup threading for more predictable backup performance.
> \- \*\*Bug Fixes\*\*
> - Reduced the risk of excessive memory usage in constrained container environments.
> \- \*\*Tests\*\*
> - Added coverage for DuckDB memory limit selection across scenarios and verified Parquet backup compression uses \*\*ZSTD\*\*.

Concrètement:

- Passage de GZIP à ZSTD
- Borner la mémoire du backup à 1Go max, pas besoin d’avoir plus de cache
- Mieux calculer la limite par défaut

---

<div class="post-metadata">

**Author:** ![lmilcent](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/lmilcent/32/7023_2.png) [@lmilcent](https://community.gladysassistant.com/u/lmilcent)\
**Post date:** [Août 1, 2026, 6:45 UTC](https://community.gladysassistant.com/t/surconsommation-de-memoire-par-le-backup-de-gateway/10387/15 "2026-08-01T18:45:36Z")

</div>

Merci d’avoir répondu plus vite que moi, étant encore en congés loin de chez moi, j’avais pas trop temps 🙃

Merci pour les patchs !

---

<div class="post-metadata">

**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:** [Août 1, 2026, 6:47 UTC](https://community.gladysassistant.com/t/surconsommation-de-memoire-par-le-backup-de-gateway/10387/16 "2026-08-01T18:47:46Z")

</div>

Je suis preneur de vos tests sous LXC bien-sûr ! @mutmut on croise fort les doigts pour que ça corrige ton souci !

---

<div class="post-metadata">

**Author:** ![lmilcent](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/lmilcent/32/7023_2.png) [@lmilcent](https://community.gladysassistant.com/u/lmilcent)\
**Post date:** [Août 27, 2026, 6:30 UTC](https://community.gladysassistant.com/t/surconsommation-de-memoire-par-le-backup-de-gateway/10387/17 "2026-08-27T18:30:09Z")

</div>

Pour ce que ça vaut, toujours pas de plantage depuis !

---

<div class="post-metadata">

**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:** [Août 27, 2026, 6:51 UTC](https://community.gladysassistant.com/t/surconsommation-de-memoire-par-le-backup-de-gateway/10387/18 "2026-08-27T18:51:48Z")

</div>

De mon côté, j’ai passé mon LXC à 13Go donc plus de soucis.  
Néanmoins je remarque qu’en temps normal ça tourne juste en-dessous des 5Go de ram, et quand ça sauvegarde (à vérifier avec les heures exactes car ma courbe est sur 7 jours), ça monte à quasiment 8Go de ram.

 ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/f/f/ff3b3ea79d2fa424ee368350991fc46c2983c707.png)  
 ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/9/9/993fd4e6bda7cf019e1c41d1f68276d4a2670120.png)  
 ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/optimized/3X/6/4/643d00ab8912aea118eb5c86e69ed0755716e601_2_690x39.png)

Allez, je repasse à 10Go de ram pour voir 🙂

---

<div class="post-metadata">

**Author:** ![lmilcent](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/lmilcent/32/7023_2.png) [@lmilcent](https://community.gladysassistant.com/u/lmilcent)\
**Post date:** [Août 27, 2026, 7:45 UTC](https://community.gladysassistant.com/t/surconsommation-de-memoire-par-le-backup-de-gateway/10387/19 "2026-08-27T19:45:37Z")

</div>

Wow, chez moi c’est stable à 3Gb.J’ai mis 4Gb au LXC et limité à 2Gb DuckDB.

 ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/9/3/93ff9894411383c1e6850f2eb373e7b9505229fa.png)

docker-compose :

```yml
services:
  gladys:
    image: gladysassistant/gladys:v4
    container_name: gladys
    restart: always
    privileged: true
    network_mode: host
    cgroup: host
    logging:
      driver: "json-file"
      options:
        max-size: 10m
    environment:
      NODE_ENV: production
      SQLITE_FILE_PATH: /var/lib/gladysassistant/gladys-production.db
      SERVER_PORT: 80
      TZ: America/Toronto
      DUCKDB_MEMORY_LIMIT: 2GB
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /var/lib/gladysassistant:/var/lib/gladysassistant
      - /dev:/dev
      - /run/udev:/run/udev:ro

  watchtower:
    image: containrrr/watchtower
    restart: always
    container_name: watchtower
    command: --cleanup --include-restarting
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

```

---

<div class="post-metadata">

**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:** [Août 27, 2026, 8:29 UTC](https://community.gladysassistant.com/t/surconsommation-de-memoire-par-le-backup-de-gateway/10387/20 "2026-08-27T20:29:36Z")

</div>

Après ma `gladys-production.db` pèse presque 10Go, je pense que c’est un beau bébé.  
De mon côté j’ai diminué à 1GB :

```js
  gladys:
    image: gladysassistant/gladys:v4
    container_name: gladys
    restart: always
    privileged: true
    network_mode: host
    cgroup: host
    logging:
      driver: "json-file"
      options:
        max-size: 10m
    environment:
      NODE_ENV: production
      SQLITE_FILE_PATH: /var/lib/gladysassistant/gladys-production.db
      SERVER_PORT: 8420
      TZ: Europe/Paris
      DUCKDB_MEMORY_LIMIT: 1000MB # limitation utilisation memoire duckDB

    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:rw
      - /var/lib/gladysassistant:/var/lib/gladysassistant:rw
      - /dev:/dev:rw
      - /run/udev:/run/udev:ro
      - /etc/localtime:/etc/locatime:ro
      
  watchtower:
    image: nickfedor/watchtower
    restart: always
    container_name: watchtower

```

 ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/8/6/864c27ab0892be0a5ec91c3f38b8d799f23d6288.png)

Par contre je remarque que tu es toujours sur `containrrr` au lieu de `nickfedor`. Tu as toujours les mises à jour en auto ou tu le fais manuellement ?

[Page suivante](https://community.gladysassistant.com/t/surconsommation-de-memoire-par-le-backup-de-gateway/10387.md?page=2)