RAM Auslastung geht nicht nach Benutzung runter

[FelixIstDa]

Hallo,

Ich habe Proxmox 6.3-3 seit ca. 15 Tage, mein Problem ist, wenn ein vServer den RAM genutzt hat und der vServer die Leistung nicht mehr braucht, reserviert der Dedicated Server den Ram trotzdem für den vServer, erst wenn ich den vServer stoppe geht die RAM Auslastung wieder zurück.
Gibt es dazu eine Möglichkeit das der RAM nur dann von Dedi genutzt wird wenn der vServer den auch braucht?

 

[t.lamprecht]

Hi,

welches OS läuft in der VM?

Was so halbwegs klappt, ist bei der VM Memory "Advanced Setting" ein "Minimum Memory" anzugeben, das ist dann das Basis Memory und der Rest wird dynamisch, bei Bedarf, dazugegeben. Das die VM dass auch wieder reduzieren kann, wenn das Memory nicht mehr benötigt wird ist etwas schwieriger, da muss die VM von innen mitspielen.

Dafür gibt es zurzeit den VirtIO-Balloon Gast Treiber, bei Linux oft schon dabei bei Windows muss man den normal explizit installieren. https://pve.proxmox.com/wiki/Windows_VirtIO_Drivers

 

[t.lamprecht]

Aja, fast vergessen: Folgendes Doku Kapitel könnte hier auch interessant sein:
https://pve.proxmox.com/pve-docs/chapter-qm.html#qm_memory

 

[FelixIstDa]

Ich habe auf beiden Systemen Debian 10 mit Linux 5.4.78-2-pve

Minimum Memory habe ich mit Ballooning Device bereits eingestellt.
Und QEMU Guest Agent läuft auch auf der VM.

 

[H4R0]

Das ist nicht möglich, bis auf regelmäßige cache drops, sollte man aber möglichst vermeiden.

Einfach der VM nicht mehr Arbeitsspeicher geben als sie benötigt.

 

[FelixIstDa]

Auf der VM nutze ich Pterodactyl und das ist immer variabel, weil da jederzeit ein Gameserver hinzugefügt werden kann.

 

[Dunuin]

Linux nutzt aber alles an RAM was du ihm gibst. Gibst du der Linux VM 32 GB RAM und braucht dein Pterodactyl aktuell nur 8GB, dann wird Linux halt die freien 24GB zum Cachen benutzen und Proxmox zeigt dir dann an, dass da 32GB belegt sind, weil sie es in Wirklichkeit auch sind. Alles was dein Linux cacht ist ja auch physisch belegter RAM auf dem Host, auch wenn dir dein Linux in der VM 24GB als "available" anzeigt.
RAM Overcommitment geht bei Linux nicht sinnvoll und Balloning wird dir auch nicht intelligent den durch Cache belegten RAM wieder freimachen. Wenn du eine VM hast wo 80% vom RAM von Programmen benutzt wird und 20% für Cache und eine andere VM wo die Programme nur 20% belegen und 80% der Cache und du bei beiden VM das "Ballooning Minimum" auf 50% stellst, dann wird das Balooning einfach stupide bei beiden VMs 50% vom RAM wegnehmen. Das lässt dann in der ersten VM so lange Programm crashen, bis die wieder in den RAM passen und bei der zweiten VM passiert nichts derartiges, weil da nur die gecachten Daten entsorgt werden.
Willst du nicht, dass da Linux unnötig anderen VMs RAM wegfrisst, dann darfst du den VMs einfach nicht mehr RAM geben, als sie aktuell wirklich brauchen. Oder du musst gucken, dass da in der Summe deine VMs nicht mehr RAM nutzen könnten, als du physischen RAM im Server verbaut hast. Dann wäre es ja auch völlig egal, wie da nun eine VM den RAM genau nutzt, da du keinen Nachteil hättest, wenn alle VMs 100% ihres RAMs nutzen würden.

 

[t.lamprecht]

Naja, der Virtio-Balloon sollte eigentlich auch bei Linux im Memory so aufblasen, dass das freie, aber benützte Memory vom Kernel freigegeben wird und dann von virtio-balloon Treiber an den Host zum wiederverwenden wieder freigegeben wird.

Mehr Hintergrund zu der und anderen Techniken gibts es bspw. in folgenden Slides:
https://static.sched.com/hosted_fil...-(balloon pmem mem) Managing Guest Memory.pdf

Ballooning ist halt kein Zaubermittel, es hat seine Nachteile und funktioniert nicht hyper-dynamisch für dutzende GiB allokieren und releasen in kürzester Zeit. Die technik hat hauptsächlich Vorteil für Migration und dass der page-cache des Hosts weniger "eviction" sieht.

Eins ist aber wirklich wahr: Memory-Overcommitment ist nie gut und wird immer Probleme machen, das ist eine Ressource, die man einfach nicht in Zeitslots teilen kann, wie etwa CPU, und wenn's knapp wird ist die Hölle (bzw. der OOM Killer) los

 

[Dunuin]

Naja, der Virtio-Balloon sollte eigentlich auch bei Linux im Memory so aufblasen, dass das freie, aber benützte Memory vom Kernel freigegeben wird und dann von virtio-balloon Treiber an den Host zum wiederverwenden wieder freigegeben wird.

Bei mir sehe ich vom Ballooning nicht wirklich etwas, solange ich da den minimalen und maximalen RAM gleich hoch setze. Da ist der RAM der Gäste wegen Page Caching trotzdem immer zu 90-95% belegt, auch wenn da die Hälfte nur Caching ist. Proxmox macht da nichts vom RAM frei, auch nicht wenn mein RAM auf dem Host bei über 80% Auslastung liegt.
Wenn ich den minimalen RAM kleiner mache als den maximalen RAM, dann dann sehe ich zwar, dass das Balooning einsetzt, sobald die 80% RAM am Host überschritten werden, aber dann entspricht halt der RAM jedes Gastes einfach dem eingestellten Minimum.
Wenn meine RAM Auslastung am Host immer bei so rund 85% ist, dann laufen eh alle Gäste ständig auf dem eingestellten RAM Minimum und ich sehe da keinen Vorteil. Kommt ja auf das gleiche hinaus, wenn ich den ganzen RAM (also Min und Max) einfach gleich so klein wähle, wie sonst das Minimum.

Ist halt wirklich schade, dass da keine dynamische Regelung geht, weil meine 64GB RAM immer zu über 80% (ohne die KSM Einsparungen wären es wohl 100%) ausgelastet sind, obwohl davon bestimmt mindestens 1/2 einfach nur für Caching benutzt werden.

 

[t.lamprecht]

Bei mir sehe ich vom Ballooning nicht wirklich etwas, solange ich da den minimalen und maximalen RAM gleich hoch setze.

Da ist Ballooning ja auch nicht aktiv, hat erst dann einen Sinn, wenn der Admin eine Untergrenze angibt, sonst wird nur eher der pagecache u.ä. der VM getrashed.