Realer RAM-Verbrauch von VMs

ferdl9999

Renowned Member
Nov 7, 2015
52
0
73
Hallo,

der in Proxmox angezeigte RAM-Verbrauch einer VM spiegelt leider nicht den "tatsächlichen" RAM-Verbrauch wider (zumindest nicht bei mir). Das Ganze wurde schon in diversen anderen Threads diskutiert. So wie ich das verstanden habe, müsste Proxmox allerdings den realen Verbrauch anzeigen, sofern das Ballooning-Device aktiviert ist.

Ich verwende keine dynamische Speicherallokation, minimaler und maximaler Speicherwert bei mir sind also identisch.
Balloning ist ebenfalls aktiviert.

Bei meinen Linux-VMs wird aber nicht der tatsächliche RAM-Verbrauch angezeigt, sondern stets nur ein langsam immer bis zu 100% anwachsender Wert.

Ist es irgendwie möglich, hier den realen Verbrauch anzuzeigen? Bzw. mache ich etwas falsch? Muss vielleicht auf der Linux-VM noch etwas getan werden? Auch mit installiertem Guest-Agent wird der "falsche" (nicht-reale) Wert angezeigt.

Bei meinen Windows-VMs hingegen wird der tatsächliche Verbrauch zurückgeliefert, hier habe ich das Balloning-Device und sämtliche anderen VirtIO-Treiber inklusive Guest-Agent installiert.

Viele Grüße und danke für eure Hilfe!
 
// Edit:

https://www.tecmint.com/clear-ram-memory-cache-buffer-and-swap-space-on-linux/
Durch Leeren des Caches auf der VM wird wieder der "reale" Verbrauch meiner VM angezeigt.
Code:
sync; echo 1 > /proc/sys/vm/drop_caches

Nun meine Frage: Gibt es hier eventuell eine bessere Methode? Den Cache regelmäßig zu leeren ist sicher nicht elegant und vermutlich auch nicht zielführend, zumal es in einem Produktivsystem ja gar nicht getan werden sollte, wenn man sich dazu etwas beliest.

Idee: Kann seitens Proxmox nicht theoretisch über den Guest-Agent der tatsächliche RAM-Verbrauch "nativ" abgefragt werden (falls Guest-Agent installiert)? Oder ist es irgendwie möglich, mittels des Ballooning-Devices den "gecacheten" RAM von der Anzeige abzuziehen?
 
Last edited:
Welcher Treiber genau? Ich habe das Problem ja nur mit Linux-VMs. Meines Wissens nach ist der Ballooning-Treiber ja schon direkt im Linux-Kernel mit integriert.

// Nachtrag: Das Kernel-Modul ist auch geladen, das Ballooning-Device wird ebenfalls erkannt:
Code:
root@test:~# lspci -knn | grep -i ball
00:03.0 Unclassified device [00ff]: Red Hat, Inc Virtio memory balloon [1af4:1002]
        Subsystem: Red Hat, Inc Virtio memory balloon [1af4:0005]

root@test:~# lsmod | grep -i virtio_balloon
virtio_balloon         20480  0
virtio_ring            28672  5 virtio_console,virtio_balloon,virtio_scsi,virtio_pci,virtio_net
virtio                 16384  5 virtio_console,virtio_balloon,virtio_scsi,virtio_pci,virtio_net
 
Last edited:
Ich dachte das wäre aber auch normal. "frei" ist ja eine Frage der Definition. Wenn du 10GB RAM im Gast hast, davon 5GB Applikationen verwenden und 4GB für den Cache verwendet werden, dann werden ja 90% vom RAM des Gastes benutzt und auch 90% Usage angezeigt. Physisch braucht das ja auch 9GB vom RAM auf dem Host. Die 4GB Cache sind zwar keine wichtigen Daten und der Gast kann die schnell beseite schaufeln, wenn er mehr RAM für Apps braucht, aber wirklich frei sind die dann ja von Seite des Hostes auch nicht, der muss ja schließlich die vollen 9GB verwalten und die stehen weder dem Host noch einer anderen VM mehr zur Verfügung.

Das Ganze mit dem RAM finde ich aber auch etwas problematisch, wenn man RAM Overprovisioning benutzen muss, weil nicht mehr RAM in den Rechner passen und das Geld für bessere Hardware fehlt. Hier daheim haben meine VMs in der Summe z.B. mehr RAM zugeteilt bekommen als was da an RAM physisch zur Verfügung steht. Die VMs müssen sich also den knappen RAM teilen und alle VMs cachen bis der Gast-RAM zu über 90% voll ist, dann geht dem Host der RAM aus, das Balooning fängt an den nutzbaren RAM in den Gästen auf den "Min RAM"-Wert zu setzen, die Gäste geraten in Panik und versuchen den Cache zu leeren und mit Pech wird dann noch ordentlich geswappt.
Ich hatte schon geguckt, ob man in Linux irgendwie das Cachen begrenzen kann (so wie bei ZFS mit dem ARC z.B.) aber da scheint es wohl leider keine Optionen für zu geben.

Wenn ich einer VM z.B. 8 GB RAM gebe weil die unter kurzer Last auch mal 6GB RAM für Anwendungen braucht, die aber meist nur im Leerlauf so 2GB RAM für Anwendungen benötigt, dann will ich eigentlich nicht, dass die VM da die kompletten 6GB freien RAM für Caching nutzt. Da würde auch 1GB fürs Caching vollkommen reichen und die 5GB die dann frei wären könnten andere VMs dann viel besser nutzen.
 
Last edited:
Was mich dann aber verwundert, ist dass bei Windows-VMs dann der tatsächliche Verbrauch angezeigt wird (mit installierten VirtIO-Treibern). Windows betreibt ja meines Wissens nach auch Caching und wenn man direkt die RAM-Nutzung des QEMU-Prozesses auf dem Hypervisor ansieht, liegt dieser auch über dem in Proxmox angezeigten Wert. Dennoch ist der Wert in Proxmox der "real" durch Applikationen + System verwendete Arbeitsspeicher, Caching wird hier meiner Beobachtung nach außen vor gelassen.

An sich stimmt das schon @Dunuin, da gebe ich dir vollkommen recht. Aber interessanter ist doch dann eher der Wert, der durch System + Applikationen "real" verursacht wird, den Cache also außer Acht gelassen. Sprich: Wie viel steht dem Guest denn noch effektiv zur Verfügung? Und nicht: Wie viel wird aus Sicht des Hypervisors belegt?
So wird es ja anscheinend auch bei Windows-VMs gemacht. Korrigiert mich bitte, wenn ich hier falsch liege.
Bei mir steigt nach einigen Tagen der RAM-Verbrauch von quasi jeder VM auf 100% an. Wenn ich direkt auf der VM nachsehe, ist dort aber noch genug frei. Klar, ich verstehe (mittlerweile) die Hintergründe dafür, aber sonderlich informativ ist diese Anzeige in Proxmox (und auch der Graph) meiner Meinung nach dann nicht.
Der Mehrwert an Informationen ist quasi nicht vorhanden, wenn ich in Proxmox nachsehe und dort stets knapp 100% nach einiger Zeit angezeigt werden, obwohl ja eigentlich an sich doch noch was frei ist, der freie Speicher nur für Caching genutzt wird.
 
Was ich mich dabei aber noch gefragt habe ist, ob die angezeigte "RAM usage" nur optisch für die Graphen ist oder ob der Wert dort z.B. auch für Balooning, KSM und den Panik-Mode benutzt wird der dann ggf. VMs notabschatet.
Ich habe z.B. auch eine OPNsense-VM die auf FreeBSD läuft und für Unix gibt es wohl keinen qemu-guest-agent. Proxmox zeigt bei FreeBSD genau das falsche an. Wenn mir FreeBSD sagt mein RAM ist zu 70% "free" (also wiklich komplett ungenutzt, auch nicht durch Caching belegt oder so) dann sagt mir Proxmox die "RAM usage" wäre 70%. Sagt mir FreeBSD 25% "free" sagt mir Proxmox 25% "RAM usage". Habe das mehrfach durchgetestet und Proxmox zeigt wirklich immer genau den umgekehrten Wert an. Da war ich dann auch schon besorgt, dass da vielleicht Proxmox anfängt zu spinnen, weil es denkt da wäre mehr RAM verbraucht als es wirklich der Fall ist.

Bei Win10 bin ich bei mir nicht ganz sicher was er da anzeigt. Mit allen Virtio-Diensten installiert und Balooning aktiviert zeigt er mit in Proxmox das an, was mir auch der Task-Manager in Windows selbst anzeigt. Ich habe in Windows aber nicht herausfinden können, wie ich den RAM dort weiter aufschlüsseln könnte. Sah für mich eher so aus als wenn Windows im Task-Manager auch schon direkt den Cache als belegt einbezieht und einrechnet und in Proxmox wäre dann Win10 auch inkl. belegtem Cache angezeigt.
 
Last edited:
Das Verhalten ist ja ziemlich merkwürdig... Konnte ich glücklicherweise bisher noch nicht beobachten, habe allerdings auch nur Debian- und Ubuntu-VMs am laufen (+ Windows).

Mir fällt nur einfach auf, dass bei quasi beinahe allen meiner Linux-VMs die Memory Usage unter Proxmox sich nach einigen Tagen den 100% annähert. Klar, es landet nach und nach immer mehr im Cache, insofern ist das schon nachvollziehbar.
Im Vergleich dazu eine Windows-VM mit mehreren Monaten Uptime und 12GB zugewiesenem RAM. Hier wird aktuell ein Wert von unter 2GB in Proxmox angezeigt, was auch ungefähr dem Wert im Task-Manager entspricht. Ich kann mir nicht vorstellen, dass hier der Cache inbegriffen ist. Die RAM-Auslastung der einzigen Anwendung, die darauf läuft, entspricht ca. 70% der gesamten RAM-Auslastung der VM. So viel bleibt also für Caching gar nicht mehr übrig, wenn das da inbegriffen sein soll.

Wie dem auch sei: Meiner Meinung nach ist die Anzeige mit dem inbegriffenen Cache nicht wirklich informativ. Es wächst nach einiger Zeit einfach immer mehr und mehr an, es sinkt ja quasi auch nicht, außer man rebootet die VM. Informativer wäre denke ich die Anzeige ohne inbegriffenen Cache. Insbesondere auch für den Graphen. Bei meinen Linux-VMs geht dieser nur nach "oben", er sinkt nicht.
 
Last edited:
Bei mir hängt das mit dem Cachen auch stark von den Anwendungen ab.

Meine Graylog-VM (Debian) ist pausenlos am Schreiben und der Cache leert sich nie. Hab den RAM schon verkleinert, damit da nicht zu viel unnötig gecacht wird:
ram1.jpg

Meine Emby-VM (Debian) schreibt selten etwas und es wird kaum Cache genutzt. Außer ich lasse mir gelegendlich mal ein Video streamen, dann wird massig gecacht und nach einigen Stunden ist der RAM dann auch wieder frei:
ram2.jpg
Ganz bekloppt halt bei der OPNsense-VM, welche immer nur so 400MB für Alles inkl Cache belegt aber das Inverse angezeigt wird:
ram3.jpg

Bei der Win10-VM bin ich mir nicht ganz sicher. Da hatten Proxmox + Task Manager z.B. beide mal so um die 7GB RAM usage angezeigt aber alle laufenden Anwendungen und Dieste zusammen im Taskmanager hatten keine 2GB RAM belegt. Weiß also nicht warum dort der RAM auf 7 GB hätte sein sollen, wenn da nicht beide auch den Cache einberechnet hätten:
ram4.jpg

Eine Sache die ich auch sehr verwirrend finde ist, dass da der durchs Ballooning limitierte RAM nicht im Diagramm angezeigt wird. Bei dem Bild der Emby-VM sieht man z.B. zwischen dem 10. und 11. Dezember, dass da 8GB RAM verfügbar sind aber die "RAM usage" bis auf 4GB ansteigt und dann auf knapp unter 4GB stagniert. Das liegt aber nur einfach daran, dass da das Ballooning eingesetzt hat und das Linux nur noch 4GB nutzen dürfte, da ich dort im Ballooning "Min: 4GB" und "Max: 8GB" eingestellt hatte. Also eigentlich hatte die VM ihren RAM komplett ausgelastet wenn sie bei 4GB von 4GB war nur Proxmox zeigt einem das nirgends und man denkt der VM würden 8GB zur Verfügung stehen.
Da wäre es deutlich besser, wenn das Diagramm nicht "Total" und "RAM Usage" angeigen würde sondern vielleicht auch wieviel von dem RAM denn zu dem jeweiligen Zeitpunkt überhaupt maximal nutzbar wäre (wenn das das Ballooning den Total RAM limitiert).
Den "RAM usage" im Diagram noch etwas aufzuschlüsseln wäre aber auch wirklich nicht verkehrt.

So etwas hier würde ich sehr nett finden:
ram5.jpg
Dann könnte man besser sehen wenn der RAM im Gast nur voll ist wegen Caching und man könnte sehen wann da das Ballooning wieviel RAM limitiert hat.


Vielleicht kann da ja mal einer aus dem Team was zu sagen, wie das genau intern abläuft. Also vorallem ob das nur kosmetisch ist oder auch intern ohne Bezug auf Cache geregelt wird. Und vorallem ob da bei FreeBSD z.B. KSM/Ballooning zu spinnen anfangen könnte, wenn da Proxmox die RAM usage falsch interpretiert und "Free" mit "Used" verwechselt.
 
Last edited:
Wenn ich auf den Hypervisor gehe will ich den realen ram verbrauch sehen inklusive cache halt was physikalisch belegt ist.

Für alles andere hat man sein monitoring, incinga, grafana, munin etc. das geht dann auch ins detail.

Ist bei esxi, hyper-v, xen, etc. nicht anders.
 
@H4R0 Gut, da gehen die Meinungen auseinander. Ich persönlich fände eine Übersicht ganz gut, bei der ich auf einen Blick sehe, wie viel RAM hier tatsächlich genutzt wird. Damit kann ich z.B. einsehen, wenn eine VM mehr RAM benötigen sollte und ihr entsprechend mehr RAM zuweisen. Wenn bei allen VMs nach und nach der Verbrauch kontinuierlich anwächst und dann überall eine extrem hohe Auslastung angezeigt wird, bringt mir das an sich nichts. Ich sehe zwar, wie viel RAM die VMs tatsächlich auf dem Hypervisor benötigen, jedoch nicht, welche VM gerade tatsächlich an RAM-Knappheit "leidet" und welche VMs hier einfach nur Caching betreiben, einfach weil so viel RAM frei ist.
Klar, man könnte auch Monitoring-Software einsetzen. Aber speziell für VMs, auf die man keinen direkten Zugriff hat, ist das doch interessant. Und ich sehe auch gerade keinen Grund, weshalb man das nicht zusätzlich integrieren sollte (sofern technisch machbar). Man sollte es natürlich so umsetzen, dass die aktuelle Information (RAM-Anzeige aus Sicht des Hypervisors) nicht verloren geht, sondern einfach mit der zusätzlichen Anzeige ergänzt wird.

Deshalb finde ich den Vorschlag von @Dunuin eigentlich grandios: Einfach eine detailliertere Anzeige. Wenn man den RAM-Verbrauch aus Sicht des Hypervisors einsehen will, dann kann man das problemlos weiterhin machen. Im gleichen Graphen sieht man aber auch die Anzeige aus Sicht der VM, worin der Cache nicht mit inbegriffen ist. Sowas wäre doch perfekt!

Falls das im Bereich des Möglichen liegt, fände ich so eine detailliertere Anzeige, wie du (@Dunuin) vorgeschlagen hast, fantastisch! Am besten dann auch direkt in die API integrieren.
Danke dir für die Unterstützung und das Feedback mit einbringen! Dein letzter Post hat denke ich nochmal ziemlich gut alles zusammengefasst, das mit dem letzten Bild wäre meiner Meinung nach die perfekte Umsetzung. Leider weiß ich nicht, inwiefern das technisch möglich ist.

Es wäre super, wenn hierzu jemand aus dem Proxmox-Team etwas sagen könnte.

Danke an alle für's mit diskutieren!
 
Last edited:
Ich habe noch einmal nachgeguckt. Bei Win10 scheint Proxmox im Diagramm wirklich den Cache wegzulassen. Proxmox zeigte hier 2,8GB von 6GB "RAM usage" und der Task Manager meinte 2,78GB wurden aktiv benutzt, 3,1GB für Cache und 0,1GB waren frei/ungenutzt.
 
Gleiches konnte ich auch feststellen. Wäre dann wenn man es streng nimmt so gesehen eine gewisse Inkonsistenz - bei Windows wird nur der durch System+Applikationen genutzte RAM angezeigt, bei Linux-VMs hingegen inklusive Cache.
Bei deinem Beispiel resultiert das bei mir bei meinen Linux-VMs langfristig immer mit einer Anzeige von nahezu 100% RAM-Belegung.

Optimal wäre natürlich dein Vorschlag, damit dürfte dann denke ich auch jeder zufrieden sein :D
Es stimmt schon was @H4R0 sagt, die Anzeige des aus Sicht des Hypervisors genutzten RAMs sollte definitiv erhalten bleiben, sie sollte nur meiner Meinung nach aufgeschlüsselt und um detailliertere Informationen ergänzt werden. Nur weiß ich nicht, inwiefern das technisch lösbar ist. Ich bin hier sehr gespannt auf die Antwort des Proxmox-Teams.
 
Last edited:
Hallo! Ich wollte an dieser Stelle nochmal um eine kleine Antwort des Proxmox-Teams bitten. Wäre super, wenn sich jemand falls es zeitlich passt das Ganze mal durchlesen könnte. Ich finde den Vorschlag von @Dunuin nach wie vor super. Vielleicht gibt es ja eine kleine Stellungnahme von offizieller Seite
 
Ich denke das müsste man im Bugtracker als Feature-Wunsch vorschlagen, damit sich das Team überlegt, ob sowas umzusetzen lohnt.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!