VM Ram von alleine verdoppelt

Lucar

Active Member
Oct 29, 2019
18
0
41
24
Hi,
ich hab eine VM mit 16GB RAM. In Proxmox steht aktuell auch 11GB von 16GB belegt... Prüfe ich auf der VM zeigt er seit neustem 30GB und nur 5GB benutzt und im Cache 660MB vorher waren es immer so 10GB im Cache und auch so 5GB in Nutzung und insgesamt 16GB keine 30GB!

Wie kann das sein es wurde nicht verändert und plötzlich sagt die VM das sie 30GB RAM hat und Proxmox sagt die gleichen Werte wie vorher. Balloning ist deaktiviert. Es macht für mich wenig Sinn das so wenig jetzt im Cache ist und der RAM sich von alleine verdoppelt hat das hatte ich noch nie.
 
Teile bitte Bilder bzw. Ausgaben von dem was du siehst. Summary der VM und der Node sowie Hardware Tab der VM und free -h.
 
  • Like
Reactions: beisser
Würdet ihr Ballooning aktivieren oder deaktivieren und KSM erlauben oder auch deaktivieren?
 
Kommt darauf an, generell sollte man keine Wunder erwarten, weil man RAM nicht wirklich überprovosionieren kann, siehe hierzu folgenden Post von dunuin: https://forum.proxmox.com/threads/ramverbrauch-bleibt-konstant.107279/#post-461391
Bei VMs wo man ein PCIE-Gerät durchreicht wird außerdem eh immer der gesamte RAM reserviert, da hilft auch kein Balooning. Je nach Szenario kann das Balooning auch unerwünschte Nebenwirkungen haben, weil innerhalb einer VM plötzlich weniger RAM da ist und das VM-Betriebssystem deshalb ram-intensive Anwendungen abschießt.
Trotzdem würde ich das Balooning immer aktivieren (aber für Min- und Max den gleichen Wert angeben, um die Probleme zu umgehen), da sonst man in Proxmox_Dashboard nicht sehen kann, wieviel RAM gerade in der VM verbraucht wird.
KSM finde ich im Homelab sehr praktisch, aber auch das hilft ja nur da, wo man viele ähnliche VMs betreibt, da das ja identische RAM-Inhalte der VM zusammenpackt. Das kostet außerdem CPU-Zeit, was je nach Anwendung unerwünscht sein kann.

Es gibt außerdem Szenarien, wo man KSM für sogenannte side-channel-Angriffe ausnutzen kann. Im Homelab nehme ich das Risiko in Kauf, in einen professionellen Umfeld kann KSM je nach Szenario (bleibt alles in der gleichen Firma oder betreibt man voneinander getrennte VMs für verschiedene Kunden?) unerwünscht oder sogar durch Compilance-Vorgaben ganz verboten sein kann.
Generell sollte man sich den VMs nur soviel RAM zuweisen wie sie benötigen und auch mal die Doku lesen, um zu verstehen, wie das funktioniert und wo die Grenzen sind: https://pve.proxmox.com/wiki/Dynamic_Memory_Management

Danach dann entscheiden, wie man die Vor- und Nachteile bewertet und welche Konsequenz man daraus zieht.
 
Last edited:
Hat sich erledigt
WIllst du auch erklären wie und wieso?
Würdet ihr Ballooning aktivieren oder deaktivieren und KSM erlauben oder auch deaktivieren?
Also ich versuche generell so viel wie möglich aus meinem RAM raus zu holen. Ich nutze Ballooning und KSM sowie ZRAM. Eventuell aber halt nicht für VMs.
Man muss seine Anwendungen/Gäste gut kennen um das vernünftig umzusetzen. Ein OOM sollte durch Ballooning zB. nämlich nicht entstehen.
 
Last edited:
zram nutze ich auch, allerdings sollte man das nur tun, wenn man keinen physikalischen swap hat, etwa wenn man zfs verwendet (immer eine gute Idee ;), da richtet der Proxmox-Installer standardmäßig keinen Swap ein, weil das unter bestimmten Umständen in der Vergangenheit zu Problemen geführt hat. Man sollte dann aber noch einen Userspace-OOM-Killer haben, dafür gibt es so sachen wie earlyoom, nohang oder systemd-oomd. Hat man physikalisches Swap, sollte man nach Meinung von Chris Down (Kernelentwickler, der u.A. auch an der Speicherverwaltung und swap mitentwickelt) stattdessen zswap verwenden. Beides komprimiert Teile des RAMs, aber mit physikalischen Swap ist zram suboptimal:
https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-what.html

Swap will man (egal in welcher Form) schon haben, dazu hat Down auch mal was geschrieben:
https://chrisdown.name/2018/01/02/in-defence-of-swap.html
 
  • Like
Reactions: Impact
Ich habe so ziemlich alle early OOM killer ausprobiert und bin am Ende nun bei der Kernel eigenen min_ttl_ms Option gelandet.
Bash:
@reboot echo 1 > /sys/kernel/mm/lru_gen/enabled; echo 1000 > /sys/kernel/mm/lru_gen/min_ttl_ms
Ich verstehe nicht zu 100% wie das funktioniert und habe auch nicht mit anderen Werten getestet aber in meinen Tests funktionierte das für mich soweit ganz gut und braucht keine extra Resourcen (ja die 30M~ für nohang haben mich gestört) oder Konfiguration. Ohne ZFS (oder wnen ich schlau gewesen wäre und das System anders partiitoniert hätte) würde ich wie im ersten Link geschrieben auch ZSWAP benutzen. Zumindestens für PVE selbst.
 
Last edited:
  • Like
Reactions: Johannes S