Si jamais tu as une idée pour automatiser ça, parce que c’est vraiment une solution très propre de fixer manuellement la limite, c’est quand même fou que LXC n’isole pas cette partie…
Si je trouve quelque chose je te tiens au courant
1 « J'aime »
C’était moi avec mon Gladys sous LXC.
Je regarderai aussi si je trouve un moyen de déterminer la RAM exacte exposée par Proxmox.
1 « J'aime »
J’ai cherché un peu mais à chaque fois cela me retourne la ram totale physique et pas celle exposée à mon LXC.
J’ai posé la question à l’IA et voilà ce que j’ai eu en retour
Gladys devrait utiliser une fonction de calcul de RAM plus intelligente au démarrage du service DuckDB. Voici l'algorithme cible :
1. **Vérifier le Cgroup (La limite réelle) :** Lire `/sys/fs/cgroup/memory.max`.
* Si c'est un nombre (ex: 8 Go) : On utilise cette valeur comme base.
* Si c'est `max` ou une erreur : On utilise `os.totalmem()` (32 Go) comme base.
2. **Appliquer le pourcentage (30%) :** On calcule 30% de la base choisie.
3. **Appliquer un "Plafond de Sécurité" (Le garde-fou) :** Même sur un serveur de 128 Go, DuckDB dans Gladys n'a pas besoin de 40 Go de RAM pour stocker des historiques de température.
* On plafonne le résultat à **2 Go** (valeur largement suffisante pour 99% des utilisateurs).
* Sur un Raspberry Pi (2 Go) :** DuckDB prendra ~600 Mo (30%). C'est parfait.
* Sur un LXC Proxmox (8 Go sur hôte 32 Go) :
* Si Gladys détecte les 8 Go → elle prendra 2.4 Go, mais sera limitée par le plafond à **2 Go**.
* Si Gladys échoue à détecter et voit 32 Go → elle voudrait 9 Go, mais sera bridée à **2 Go**.
Et propose même un exemple de code:
const fs = require('fs');
const os = require('os');
function getDuckDbMemoryLimit() {
// 1. Check ENV variable
if (process.env.DUCKDB_MEMORY_LIMIT) return process.env.DUCKDB_MEMORY_LIMIT;
const SAFETY_CAP_GB = 2; // Plafond de sécurité pour la domotique
let totalDetectedRam = os.totalmem();
// 2. Try to read Cgroup limit (LXC/Docker)
try {
const cgroupLimit = fs.readFileSync('/sys/fs/cgroup/memory.max', 'utf8').trim();
if (cgroupLimit !== 'max') {
totalDetectedRam = parseInt(cgroupLimit, 10);
}
} catch (e) {
// Fallback to os.totalmem()
}
// 3. Calculate 30% of detected RAM
const calculatedLimit = totalDetectedRam * 0.30;
// 4. Return the minimum between calculated limit and Safety Cap
const safetyCapBytes = SAFETY_CAP_GB * 1024 * 1024 * 1024;
return Math.min(calculatedLimit, safetyCapBytes);
}
L’IA a faux sur les 2 propositions malheureusement 
Comme testé précédemment, /sys/fs/cgroup/memory.max ne contient pas la valeur de RAM disponible.
Pour l’idée du plafond de sécurité, c’est un peu la solution de facilité et je ne suis pas d’accord avec son analyse. Un utilisateur qui a 16 Go de RAM dispo pour Gladys bénéficiera largement d’avoir plus de RAM pour DuckDB s’il a beaucoup de données et des courbes complexes, comme dans le cas du suivi de l’énergie.
Plafonner à une valeur arbitraire limiterait les performances pour ceux qui ont un système riche en RAM, c’est dommage 
/sys/fs/cgroup/memory.max retourne max
Dans ce cas pour un LXC sous proxmox je ne vois pas de solution sans limiter manuellement dans le docker run ou le docker compose.
J’ai testé plein de chose mais a chaque fois cela me retournais la ram de proxmox mais pas du lxc.
Dommage ! Je vais mettre à jour la documentation.
C’est quand même fou cette histoire, on pourrait penser que l’isolation est bien faite et que chaque container ne voit que ce qu’il est censé voir.
Oui je pensais aussi.
Par contre comme la dit @prohand il n’y a pas ce souci avec une machine virtuelle sous proxmox.
1 « J'aime »
Alors comme l’IA raconte pas mal de c*nneries, j’ai demandé à l’IA 
Avec Perplexity, j’ai ça :
mount | grep cgroup2
cat /sys/fs/cgroup/memory.current
et ça fonctionne bien dans mon LXC qui a 6Go de RAM :
root@gladys:~# mount | grep cgroup2
none on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime)
root@gladys:~# cat /sys/fs/cgroup/memory.current
6377263104
root@gladys:~# echo $(( $(cat /sys/fs/cgroup/memory.current) / 1000 / 1000 ))" Mo"
6377 Mo
root@gladys:~# echo $(( $(cat /sys/fs/cgroup/memory.current) / 1000 / 1000 / 1000 ))" Go"
6 Go
et l’autre méthode (pas 100% fiable apparemment) serait :
root@gladys:~# cat /proc/meminfo
MemTotal: 6291456 kB
EDIT : ci-dessus c’est pour cgroup2, pour cgroup v1 :
En cgroup v1, l’équivalent de memory.current s’appelle memory.usage_in_bytes.
Dans le conteneur LXC en cgroup v1, tu peux donc faire :
bash
# Utilisation mémoire actuelle en MiB
echo $(( $(cat /sys/fs/cgroup/memory/memory.usage_in_bytes) / 1024 / 1024 ))" MiB"
# Utilisation mémoire actuelle en GiB
echo $(( $(cat /sys/fs/cgroup/memory/memory.usage_in_bytes) / 1024 / 1024 / 1024 ))" GiB"
memory.usage_in_bytes = mémoire actuellement utilisée par le cgroup (anonyme + cache + buffers).
Ah intéressant !
@Will_71 si tu fais:
docker exec -it gladys cat /sys/fs/cgroup/memory.current
Tu vois la bonne valeur ?
Je viens d’essayer et ce n’est pas fiable surtout au démarrage.
La première fois que j’ai essayé cela m’a retourné 8Go sauf que j’ai 16Go.
Quand j’avais modifié ma RAM l’autre jour je n’avait pas redémarré le LXC.
Donc j’ai redémarré et là la valeur augmente petit à petit
root@saga:~# docker exec -it gladys cat /sys/fs/cgroup/memory.current
1023455232
root@saga:~# docker exec -it gladys cat /sys/fs/cgroup/memory.current
1027911680
root@saga:~# docker exec -it gladys cat /sys/fs/cgroup/memory.current
1029660672
root@saga:~# docker exec -it gladys cat /sys/fs/cgroup/memory.current
1031991296
root@saga:~# docker exec -it gladys cat /sys/fs/cgroup/memory.current
1029668864
root@saga:~# docker exec -it gladys cat /sys/fs/cgroup/memory.current
1030901760
root@saga:~# docker exec -it gladys cat /sys/fs/cgroup/memory.current
1029951488
root@saga:~# docker exec -it gladys cat /sys/fs/cgroup/memory.current
1030709248
root@saga:~# docker exec -it gladys cat /sys/fs/cgroup/memory.current
1030946816
root@saga:~# docker exec -it gladys cat /sys/fs/cgroup/memory.current
1031671808
root@saga:~# docker exec -it gladys cat /sys/fs/cgroup/memory.current
1031319552
root@saga:~# docker exec -it gladys cat /sys/fs/cgroup/memory.current
1022386176
root@saga:~# docker exec -it gladys cat /sys/fs/cgroup/memory.current
1024593920
root@saga:~# docker exec -it gladys cat /sys/fs/cgroup/memory.current
1044897792
root@saga:~# docker exec -it gladys cat /sys/fs/cgroup/memory.current
1045057536
root@saga:~# docker exec -it gladys cat /sys/fs/cgroup/memory.current
1279713280
root@saga:~# docker exec -it gladys cat /sys/fs/cgroup/memory.current
1279754240
SI on converti la valeur dans un meilleur format avec la formule de @mutmut
root@saga:~# docker exec -it gladys echo $(( $(cat /sys/fs/cgroup/memory.current) / 1000 / 1000 / 1000 ))" Go"
1 Go
Quelques tests de plus par rapport à ta demande pour @Will_71 .
Si je fais docker exec -it gladys cat /sys/fs/cgroup/memory.current dans mon LXC ou directement cat /sys/fs/cgroup/memory.current dans le container Gladys, je vois 4Go à chaque fois.
Ca semble correspondre aux 4Go que j’avais alloués au début lors de la création de mon LXC, et suite aux fuites mémoires que j’avais, j’ai augmenté la RAM à 6Go.
Mais pourquoi je ne vois pas les 6Go actuels, c’est une bonne question que je vais creuser.
Concernant cat /proc/meminfo exécuté dans le containeur Gladys, ça me renvoie les 16Go de mon hôte donc pas bon.
En regardant la doc de proxmox pour la création/édition de la RAM, proxmox semble se baser sur cgroup v1 :
Et pour faire suite à la remarque de @Will_71 , j’ai aussi un
memory.current du docker qui augmente et diminue très doucement directement dans le LXC qui m’indique 4Go aussi 
On a l’impression que la RAM est allouée dynamiquement au LXC, bizarre.
EDIT :
ça semble se confirmer ici :
Le suivi de la consommation est aussi amélioré grâce à memory.current, qui affiche la consommation en temps réel.
Je pense oui que c’est gérer dynamiquement car a chaque fois que j’ai été planté a cause de la ram, j’ai augmenté la valeur dans proxmox et le lxc est reparti sans redémarrage.
Dans le fichier de config du LXC (donc directement sur l’hôte), on voit bien que c’est du cgroup2 et on a la bonne valeur de RAM allouée au LXC :
J’ai l’impression que proxmox propose toute la RAM de l’hôte aux containeurs et ne délivre que ce qui est demandé dans le fichier de conf, ce qui doit permettre de modifier à la volée la RAM sans pb avec une limitation purement logicielle.
@Will_71
Je viens de voir qu’il y a un sous-rep .lxc dans cgroup, il y a peut-être des choses à récupérer de là.
Tu as quoi si tu fais :
docker exec -it gladys cat /sys/fs/cgroup/.lxc/memory.current
Chez moi j’ai un chiffre stable mais petit : 634880
je n’ai pas de dossier .lxc dans cgroup
ok
Et quelle valeur pour :
docker exec -it gladys cat /sys/fs/cgroup/memory.peak
Celle-ci me donne mes 6Go (ou presque)
EDIT : en checkant d’autres LXC, ce n’est toujours pas la bonne variable à prendre 
cela me donne 7.6Go loin de mes 16Go
J’ai bien avancé sur le sujet et ça semble très compliqué d’obtenir facilement la vraie quantité de RAM depuis le docker Gladys
En effet, celui-ci prendra toujours la quantité du host même si le LXC donnera la bonne quantité.
La seule solution que j’ai pu tester et valider pour l’instant est de passer dans le docker run ou compose, la quantité de RAM que l’on veut.
Un exemple avec docker-compose
services:
gladys:
image: gladysassistant/gladys:v4
...
mem_limit: 6g # quantité de RAM que l'on a allouée au LXC (ici, 6Go)
memswap_limit: 7g # quantité de RAM+swap (ici, 1Go de swap)
Une fois relancé, j’obtiens ces valeurs que l’on peut exploiter ensuite :
root@gladys-test:~# docker inspect gladys | grep -i memory
"Memory": 6442450944,
"MemoryReservation": 0,
"MemorySwap": 7516192768,
"MemorySwappiness": null,
root@gladys-test:~# docker exec -it gladys cat /sys/fs/cgroup/memory.max
6442450944
root@gladys-test:~# docker exec -it gladys cat /sys/fs/cgroup/memory.swap.max
1073741824
Pour la petite histoire, via Perplexity :
C’est un comportement normal et connu avec Docker dans LXC unprivileged + nesting=1 sur Proxmox : lxcfs expose la bonne RAM LXC (4 GB) au niveau host du conteneur , mais Docker (et ses conteneurs) voient la RAM host (16 GB) car nesting propage le cgroup namespace sans limiter
/proc/meminfoDocker.
- lxcfs réécrit
/proc/meminfodu LXC root →free -mLXC = 4 GB.- Docker avec nesting crée ses propres cgroups enfants → son
/proc/meminfolit cgroup parent (LXC limit) mais souvent fallback host si pas propagé.- Unprivileged + fuse-overlayfs (script tteck) accentue : Docker ignore lxcfs LXC.
1 « J'aime »