Falls du eine Idee hast, um das zu automatisieren, denn es ist wirklich eine sehr saubere Lösung, die Grenze manuell zu setzen, es ist trotzdem verrückt, dass LXC diesen Teil nicht isoliert…
Wenn ich etwas finde, halte ich dich auf dem Laufenden.
Das war ich mit meinem Gladys unter LXC.
Ich werde auch schauen, ob ich einen Weg finde, um den genauen RAM zu bestimmen, der von Proxmox bereitgestellt wird.
Ich habe ein bisschen gesucht, aber jedes Mal bekomme ich den gesamten physischen RAM zurück und nicht den, der meinem LXC zur Verfügung steht.
Ich habe die Frage an die KI gestellt und hier ist die Antwort, die ich erhalten habe
Gladys sollte eine intelligentere RAM-Berechnungsfunktion beim Starten des DuckDB-Dienstes verwenden. Hier ist der Zielalgorithmus:
1. **Cgroup überprüfen (Die echte Grenze):** `/sys/fs/cgroup/memory.max` lesen.
* Wenn es eine Zahl ist (z. B. 8 GB): Diese Wert wird als Basis verwendet.
* Wenn es `max` oder ein Fehler ist: `os.totalmem()` (32 GB) wird als Basis verwendet.
2. **Prozentualen Anteil anwenden (30%):** 30% der gewählten Basis werden berechnet.
3. **„Sicherheitsdeckel“ anwenden (Die Sicherung):** Selbst auf einem Server mit 128 GB benötigt DuckDB in Gladys nicht 40 GB RAM, um Temperaturverläufe zu speichern.
* Das Ergebnis wird auf **2 GB** gedeckelt (ein Wert, der für 99% der Benutzer mehr als ausreichend ist).
* Auf einem Raspberry Pi (2 GB):** DuckDB nimmt ~600 MB (30%). Das ist perfekt.
* Auf einem Proxmox-LXC (8 GB auf einem Host mit 32 GB):
* Wenn Gladys die 8 GB erkennt → sie nimmt 2,4 GB, wird aber durch den Deckel auf **2 GB** begrenzt.
* Wenn Gladys die Erkennung scheitert und 32 GB sieht → sie würde 9 GB nehmen, wird aber auf **2 GB** begrenzt.
Und schlägt sogar ein Codebeispiel vor:
const fs = require('fs');
const os = require('os');
function getDuckDbMemoryLimit() {
// 1. ENV-Variable überprüfen
if (process.env.DUCKDB_MEMORY_LIMIT) return process.env.DUCKDB_MEMORY_LIMIT;
const SAFETY_CAP_GB = 2; // Sicherheitsdeckel für die Hausautomatisierung
let totalDetectedRam = os.totalmem();
// 2. Versuche, die Cgroup-Grenze (LXC/Docker) zu lesen
try {
const cgroupLimit = fs.readFileSync('/sys/fs/cgroup/memory.max', 'utf8').trim();
if (cgroupLimit !== 'max') {
totalDetectedRam = parseInt(cgroupLimit, 10);
}
} catch (e) {
// Fallback zu os.totalmem()
}
// 3. 30% des erkannten RAMs berechnen
const calculatedLimit = totalDetectedRam * 0.30;
// 4. Den kleineren Wert zwischen berechnetem Limit und Sicherheitsdeckel zurückgeben
const safetyCapBytes = SAFETY_CAP_GB * 1024 * 1024 * 1024;
return Math.min(calculatedLimit, safetyCapBytes);
}
Die KI hat leider bei beiden Vorschlägen daneben gelegen 
Wie zuvor getestet, enthält /sys/fs/cgroup/memory.max nicht den verfügbaren RAM-Wert.
Die Idee der Sicherheitsgrenze ist ein wenig die einfachste Lösung, und ich stimme seiner Analyse nicht zu. Ein Benutzer, der 16 GB RAM für Gladys zur Verfügung hat, wird stark von mehr RAM für DuckDB profitieren, wenn er viele Daten und komplexe Kurven hat, wie im Fall der Energienachverfolgung.
Eine willkürliche Begrenzung würde die Leistung für diejenigen einschränken, die ein RAM-reiches System haben, das ist schade 
/sys/fs/cgroup/memory.max gibt max zurück
In diesem Fall sehe ich für einen LXC unter Proxmox keine Lösung, ohne manuell im docker run oder docker compose zu begrenzen.
Ich habe viele Dinge ausprobiert, aber jedes Mal wurde mir der RAM von Proxmox zurückgegeben, aber nicht der des LXC.
Schade! Ich werde die Dokumentation aktualisieren.
Es ist trotzdem verrückt, diese Geschichte. Man könnte meinen, die Isolierung sei gut gemacht und jeder Container sieht nur, was er sehen soll.
Ja, ich dachte auch so.
Allerdings, wie @prohand sagt, gibt es dieses Problem mit einer virtuellen Maschine unter Proxmox nicht.
Also, da die KI nicht wenig Quatsch erzählt, habe ich die KI gefragt 
Mit Perplexity habe ich das:
mount | grep cgroup2
cat /sys/fs/cgroup/memory.current
et das funktioniert gut in meinem LXC mit 6GB 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 die andere Methode (offensichtlich nicht 100% zuverlässig) wäre:
root@gladys:~# cat /proc/meminfo
MemTotal: 6291456 kB
EDIT: oben ist es für cgroup2, für cgroup v1:
In cgroup v1 heißt das Äquivalent von memory.current memory.usage_in_bytes.
In dem LXC-Container unter cgroup v1 kannst du also Folgendes tun:
bash
# Aktueller Speicherverbrauch in MiB
echo $(( $(cat /sys/fs/cgroup/memory/memory.usage_in_bytes) / 1024 / 1024 ))" MiB"
# Aktueller Speicherverbrauch in GiB
echo $(( $(cat /sys/fs/cgroup/memory/memory.usage_in_bytes) / 1024 / 1024 / 1024 ))" GiB"
memory.usage_in_bytes = aktuell vom cgroup verwendeter Speicher (anonym + Cache + Puffer).
Ah interessant!
@Will_71 wenn du folgendes ausführst:
docker exec -it gladys cat /sys/fs/cgroup/memory.current
Siehst du den richtigen Wert?
Ich habe es gerade versucht und es ist nicht zuverlässig, besonders beim Start.
Beim ersten Versuch wurden mir 8 GB angezeigt, obwohl ich 16 GB habe.
Als ich vor ein paar Tagen meinen RAM geändert habe, habe ich den LXC nicht neu gestartet.
Also habe ich neu gestartet und jetzt steigt der Wert langsam an
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
Wenn man den Wert mit der Formel von @mutmut in ein besseres Format umwandelt
root@saga:~# docker exec -it gladys echo $(( $(cat /sys/fs/cgroup/memory.current) / 1000 / 1000 / 1000 ))" Go"
1 Go
Einige zusätzliche Tests aufgrund deiner Anfrage an @Will_71.
Wenn ich docker exec -it gladys cat /sys/fs/cgroup/memory.current in meinem LXC ausführe oder direkt cat /sys/fs/cgroup/memory.current im Gladys-Container, sehe ich jedes Mal 4 GB.
Das scheint den 4 GB zu entsprechen, die ich zu Beginn bei der Erstellung meines LXC zugewiesen hatte, und aufgrund der Speicherlecks, die ich hatte, habe ich den RAM auf 6 GB erhöht.
Aber warum sehe ich nicht die aktuellen 6 GB, das ist eine gute Frage, der ich nachgehen werde.
Was cat /proc/meminfo betrifft, das im Gladys-Container ausgeführt wird, zeigt es mir die 16 GB meines Hosts an, also nicht gut.
Beim Betrachten der Proxmox-Dokumentation zur Erstellung/Bearbeitung des RAMs scheint Proxmox auf cgroup v1 basiert zu sein:
Und als Fortsetzung zu @Will_71’s Bemerkung habe ich auch ein
memory.current des Docker, das sehr langsam im LXC ansteigt und abfällt und mir ebenfalls 4 GB anzeigt 
Es scheint, als ob der RAM dynamisch dem LXC zugewiesen wird, seltsam.
EDIT:
Das scheint sich hier zu bestätigen:
Die Verbrauchsverfolgung ist auch dank memory.current verbessert, das den Echtzeitverbrauch anzeigt.
Ich denke ja, dass es dynamisch verwaltet wird, denn jedes Mal, wenn ich wegen RAM abstürzte, habe ich den Wert in Proxmox erhöht und der LXC ist ohne Neustart wieder gestartet.
In der LXC-Konfigurationsdatei (also direkt auf dem Host) sieht man deutlich, dass es sich um cgroup2 handelt und man den richtigen RAM-Wert hat, der dem LXC zugewiesen ist:
Ich habe den Eindruck, dass Proxmox den Containern den gesamten RAM des Hosts anbietet und nur das liefert, was in der Konfigurationsdatei angefordert wird, was es ermöglichen sollte, den RAM ohne Probleme dynamisch anzupassen, mit einer rein softwarebasierten Begrenzung.
@Will_71
Ich habe gerade gesehen, dass es ein Unterverzeichnis .lxc in cgroup gibt, dort könnte man vielleicht noch etwas retten.
Was hast du, wenn du folgendes ausführst:
docker exec -it gladys cat /sys/fs/cgroup/.lxc/memory.current
Bei mir kommt eine stabile, aber kleine Zahl: 634880
Ich habe kein .lxc-Verzeichnis in cgroup.
ok
Und welcher Wert für:
docker exec -it gladys cat /sys/fs/cgroup/memory.peak
Dieser gibt mir meine 6 GB (oder fast)
EDIT: Beim Überprüfen anderer LXC ist das immer noch nicht die richtige Variable 
das sind 7,6 GB von meinen 16 GB
Ich bin gut mit dem Thema vorangekommen und es scheint sehr kompliziert zu sein, die tatsächliche RAM-Menge einfach aus dem Docker von Gladys zu erhalten
Tatsächlich nimmt Docker immer die Menge des Hosts, selbst wenn der LXC die richtige Menge angibt.
Die einzige Lösung, die ich bisher testen und validieren konnte, besteht darin, die gewünschte RAM-Menge im Docker run oder compose anzugeben.
Ein Beispiel mit docker-compose
services:
gladys:
image: gladysassistant/gladys:v4
...
mem_limit: 6g # RAM-Menge, die dem LXC zugewiesen wurde (hier 6 GB)
memswap_limit: 7g # RAM+Swap-Menge (hier 1 GB Swap)
Nach dem Neustart erhalte ich diese Werte, die ich anschließend nutzen kann:
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
Zur kleinen Geschichte, über Perplexity:
Dies ist ein normales und bekanntes Verhalten mit Docker in LXC unprivileged + nesting=1 auf Proxmox: lxcfs zeigt die richtige LXC-RAM (4 GB) auf Host-Ebene des Containers an, aber Docker (und seine Container) sehen die Host-RAM (16 GB), da nesting den cgroup-Namespace ohne Begrenzung von
/proc/meminfoDocker propagiert.
- lxcfs überschreibt
/proc/meminfodes LXC-Roots →free -mLXC = 4 GB.- Docker mit nesting erstellt seine eigenen cgroup-Kinder → sein
/proc/meminfoliest den cgroup-Parent (LXC-Grenze), aber oft Fallback-Host, wenn nicht propagiert.- Unprivileged + fuse-overlayfs (tteck-Skript) verstärkt dies: Docker ignoriert lxcfs LXC.