RAM Verbrauch steigt stetig und leise

[gmed]

Guten Morgen,

Eine unserer Maschinen zeigt ein sehr seltsames Verhalten.
Und zwar wird Tag für Tag ca. 1-2MB mehr RAM in Beschlag genommen, aber nie frei gegeben.
Das führte vor ein paar Wochen zu der Situation, das der Host begann VM's zu beenden, um nicht selbst "stecken" zu bleiben.

Als Gäste werden ein MS-Server2008R2 inkl. virtio-Treiber und aktivem Ballooning betrieben.
Dazu kommen noch zwei Linux-Gäste, ebenfalls virtio und mit Ballooning.

Der Host hat 64GB RAM
Die Gäste haben davon lediglich 28GB als RAM zugewiesen bekommen.
Mitlerweile sind wieder 36GB RAM in Beschlag.

top zeigt nichts ungewöhnliches und nun der übliche Spruch:
Baugleiche Maschinen mit selbem Patchstand zeigen dieses Verhalten nicht...
Ein Herunterfahren des MS-Servers gibt den RAM wieder frei.
Aber das ist nun nicht die beste Variante.


Ich wäre für Tipps und Rat dankbar.

System:
proxmox-ve: 6.1-2 (running kernel: 5.3.13-1-pve)
pve-manager: 6.1-5 (running version: 6.1-5/9bf06119)
pve-kernel-5.3: 6.1-1
pve-kernel-helper: 6.1-1 pve-kernel-5.0: 6.0-11
pve-kernel-5.3.13-1-pve: 5.3.13-1
pve-kernel-5.0.21-5-pve: 5.0.21-10
pve-kernel-5.0.21-3-pve: 5.0.21-7
pve-kernel-5.0.21-2-pve: 5.0.21-7
pve-kernel-5.0.15-1-pve: 5.0.15-1
ceph-fuse: 12.2.11+dfsg1-2.1+b1
corosync: 3.0.2-pve4 criu: 3.11-3
glusterfs-client: 5.5-3
ifupdown: 0.8.35+pve1
ksm-control-daemon: 1.3-1
libjs-extjs: 6.0.1-10
libknet1: 1.13-pve1
libpve-access-control: 6.0-5
libpve-apiclient-perl: 3.0-2
libpve-common-perl: 6.0-9
libpve-guest-common-perl: 3.0-3
libpve-http-server-perl: 3.0-3
libpve-storage-perl: 6.1-3
libqb0: 1.0.5-1
libspice-server1: 0.14.2-4~pve6+1
lvm2: 2.03.02-pve3
lxc-pve: 3.2.1-1
lxcfs: 3.0.3-pve60
novnc-pve: 1.1.0-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.1-1
pve-cluster: 6.1-2
pve-container: 3.0-15
pve-docs: 6.1-3
pve-edk2-firmware: 2.20191127-1
pve-firewall: 4.0-9
pve-firmware: 3.0-4
pve-ha-manager: 3.0-8
pve-i18n: 2.0-3
pve-qemu-kvm: 4.1.1-2
pve-xtermjs: 3.13.2-1
qemu-server: 6.1-4
smartmontools: 7.0-pve2
spiceterm: 3.1-1
vncterm: 1.6-1
zfsutils-linux: 0.8.2-pve2

 

[Ingo S]

Die drei kvm Prozesse gehören ja zu den VMs.
Nur um sicher zu gehen, dass es wirklich diese VM ist:
Ist es denn der kvm Prozess der Win Server 2008R2 Maschine der tatsächlich den RAM für sich in Beschlag nimmt? Also, steigt der RAM "Verbrauch" dieses Prozesses auch in top sichtbar an?

 

[Chris]

Hi,
dies klingt nach einem memory leak in einem Prozess der in der Windows VM laeuft. Was gibt Windows fuer eine RAM-Belegung an? Gibt es einen Prozess der besonders viel belegt?

 

[Ingo S]

Verständnisfrage meinerseits:
Insgesamt wurden den Maschinen aber doch nur 28GB RAM zugewiesen, also z.B. den beiden Linux Kisten 6GB jeweils und dem Windoof Server 16GB. Selbst wenn ein Prozess innerhalb der VM einen Leak hat, kann doch die VM nicht mehr als 16GB RAM belegen.
Oder verstehe ich da was falsch?

 

[Chris]

Verständnisfrage meinerseits:
Insgesamt wurden den Maschinen aber doch nur 28GB RAM zugewiesen, also z.B. den beiden Linux Kisten 6GB jeweils und dem Windoof Server 16GB. Selbst wenn ein Prozess innerhalb der VM einen Leak hat, kann doch die VM nicht mehr als 16GB RAM belegen.
Oder verstehe ich da was falsch?

Nun ja dies wird aus dem posting nicht so ganz klar. @gmed bitte auch die VM config posten! laut top sind fuer einen der kvm prozesse jedenfalls 27.3g reserviert.

 

[gmed]

Guten Morgen,

top zeigt mir, dass die VM mit dem MS Server nun 29,2GB RAM reserviert hat.
Gestern waren es 27,6GB.


die Konfiguration dieser VM:
agent: 1
balloon: 12288
boot: cdn
bootdisk: virtio0
cores: 4
ide2: local:iso/virtio-win-0.1.141.iso,media=cdrom,size=309208K
memory: 16384
name: DBS1-Wadern
net0: virtio=2A:2A:BE:49:52:5F,bridge=vmbr0,firewall=1
numa: 0
onboot: 1
ostype: win7
scsihw: virtio-scsi-pci
smbios1: uuid=724231bd-3d05-48cf-a95f-a954f342d925
sockets: 1
startup: order=1,up=300
virtio0: Maschinen:vm-100-disk-0,size=270G
virtio1: Maschinen:vm-100-disk-1,size=120G

Die PID 4365 ist der KVM-Prozess des MS-Servers.
Darauf läuft eine IBM DB2. Zusätzlich gibt es zwei kleinere Feigaben.
Er bedient ca. 10 Arbeitsplätze.

Mir ist nicht ganz klar, warum dieser Prozess sich mehr RAM genehmigt, als die Konfiguration das eigentlich hergibt.

 

[Chris]

Guten Morgen,

top zeigt mir, dass die VM mit dem MS Server nun 29,2GB RAM reserviert hat.
Gestern waren es 27,6GB.


die Konfiguration dieser VM:
agent: 1
balloon: 12288
boot: cdn
bootdisk: virtio0
cores: 4
ide2: local:iso/virtio-win-0.1.141.iso,media=cdrom,size=309208K
memory: 16384
name: DBS1-Wadern
net0: virtio=2A:2A:BE:49:52:5F,bridge=vmbr0,firewall=1
numa: 0
onboot: 1
ostype: win7
scsihw: virtio-scsi-pci
smbios1: uuid=724231bd-3d05-48cf-a95f-a954f342d925
sockets: 1
startup: order=1,up=300
virtio0: Maschinen:vm-100-disk-0,size=270G
virtio1: Maschinen:vm-100-disk-1,size=120G

Die PID 4365 ist der KVM-Prozess des MS-Servers.
Darauf läuft eine IBM DB2. Zusätzlich gibt es zwei kleinere Feigaben.
Er bedient ca. 10 Arbeitsplätze.

Mir ist nicht ganz klar, warum dieser Prozess sich mehr RAM genehmigt, als die Konfiguration das eigentlich hergibt.

Das ein kvm prozess mehr RAM benoetigt als das gesetzte Limit kann schon vorkommen, es gibt immer einen overhead. HIer duerfte es aber nicht davon kommen. Sind die disk images lokal? Um welchen Typ von storage handelt es sich bei "Maschinen"? Wird ZFS verwendet?
Siehe auch https://forum.proxmox.com/threads/proxmox-6-1-oom-killed-a-vm.63288/#post-288066

 

[fabian]

auch die frage wie im Englischen Forum:
lässt sich der Beginn des Problems mit einem eingespielten Upgrade korrelieren, und falls ja, welche Pakete wurden von welcher Version auf welche Version aktualisiert (/var/log/apt/history.log)

 

[gmed]

@Chris:
"Maschienen" ist lokaler Storage aus SSD's als Raid10 auf ded. Avago Raid Controller. Mit BBU, daher mit write-thrue. Damit sollte der RAM des hosts eigentlich entlastet sein.

@fabian:
Einen direkten Zusammenhang kann ich nicht erkennen. Ich upgrade recht regelmässig, aber bis zum ersten Abwürgen einer VM achtete ich auch nicht auf den RAM.
Mea culpa. Aber durch die lange Zeit sind sicher einige upgrades gelaufen.

Was mir noch eingefallen ist, ist das die VM folgende virtio-Treiber nutzt. virtio-win-0.1.141. Auf den anderen Geräten sind es die aktuellen virtio-win-0.1.171.iso.
Am Sonntag ist Pflegetag und ich werde die Treiber inkl. guest-additions aktualisieren.

 

[gmed]

Kurzer Nachtrag:
Das Backup dieses Hosts geht per nfs auf ein Qnap-NAS.
(Wie bei den anderen Maschinen auch)
Ich kann das auf cifs umstellen.
Evtl. hilft das auch.

Wobei es seltsam ist, dass ich dieses Verhalten an nur einem Standort bei jeweils gleicher Hardware und Patchstand sowohl für den Hast als auch für das NAS habe?

 

[Chris]

Kurzer Nachtrag:
Das Backup dieses Hosts geht per nfs auf ein Qnap-NAS.
(Wie bei den anderen Maschinen auch)
Ich kann das auf cifs umstellen.
Evtl. hilft das auch.

Wobei es seltsam ist, dass ich dieses Verhalten an nur einem Standort bei jeweils gleicher Hardware und Patchstand sowohl für den Hast als auch für das NAS habe?

Okay, bitte um Rueckmedlung falls ein Update des virtio-Teibers oder des Umstellen auf CIFS etwas am Verhalten aendert.
Noch ein paar kurze Fragen bezueglich Backups:
* Wie regelmaessig werden die Backups erstellt?
* Werden dazu die PVE Tools verwendet?
* Wenn ja, welcher Modus wird verwendet?

 

[gmed]

Die MS-VM wird täglich gesichert.
Es wird mit den PVE-Tools Backups als Snapshots erstellt.
Komprimiert wird LZO.

Eine der beiden Linux VM's wird auf die selbe Art gesichert.
Allerdings nur alle 3 Tage.

Die dritte VM wird im Stop-Modus und GZIP gesichert.
Auch wieder nur alle 3 Tage.

Rückmeldung in Bezug auf Treiber und evtl. das Verhalten bei CIFS-Storage für's Backup kann ich erst ab Montag geben.
Die VM's kann ich erst am Sonntag wieder entsprechend umstellen.

 

[gmed]

Guten Morgen,

Nach Aktualisieung der virtio-Treiber zeigt sich anhängendes Bild.
top zeigt der MS-Server VM nun reservierte ~16GB RAM, was ok ist.
Der gesamte genutzte RAM laut Web-UI liegt im Moment bei ca. 25GB und ist über Nacht nur marginal mehr geworden.

Ich werde das heute Abend nochmal vergleichen, um zu sehen, ob sich über Tag bei aktiver Nutzung was getan hat.

 

[gmed]

Guten Abend,

Laut GUI ist der RAM im Moment bei 27,5GB, ein Plus von 2,5GB gegenüber heute morgen.
top zeigt für den MS-Server die gleichen Zahlen wie heute morgen. ~16GB reserviert.

Trotzdem sieht man einen Anstieg über Tag.

Auf einer zweiten VM (hier die PID 1572) läuft ein Linux als OS für Firefox und Thunderbird, welche dann auf den Windows-Desktops via X2GO zum surfen und mailen genutzt werden.
Eine Angewohnheit meiner lieben Kollegen ist, dass sie den Firefox morgens starten und z.B. T-Online.de als Nachrichtenportal ansurfen und das dann den ganzen Tag durchnudeln lassen-> diese Firefoxprozesse genehmigen sich alles an RAM, was sie kriegen können.
Der Screenshot "firefox270120.png" zeigt so einen Anstieg bis ich den Prozess dann heute Mittag abschoß.

Kann sowas dazu führen, dass sich diese VM mehr RAM aneignet, als ihr eigentlich zusteht?

 

[Chris]

Guten Abend,

Laut GUI ist der RAM im Moment bei 27,5GB, ein Plus von 2,5GB gegenüber heute morgen.
top zeigt für den MS-Server die gleichen Zahlen wie heute morgen. ~16GB reserviert.

Trotzdem sieht man einen Anstieg über Tag.

Auf einer zweiten VM (hier die PID 1572) läuft ein Linux als OS für Firefox und Thunderbird, welche dann auf den Windows-Desktops via X2GO zum surfen und mailen genutzt werden.
Eine Angewohnheit meiner lieben Kollegen ist, dass sie den Firefox morgens starten und z.B. T-Online.de als Nachrichtenportal ansurfen und das dann den ganzen Tag durchnudeln lassen-> diese Firefoxprozesse genehmigen sich alles an RAM, was sie kriegen können.
Der Screenshot "firefox270120.png" zeigt so einen Anstieg bis ich den Prozess dann heute Mittag abschoß.

Kann sowas dazu führen, dass sich diese VM mehr RAM aneignet, als ihr eigentlich zusteht?

Guten Morgen,
ein allozieren ueber das gesetzte memory limit der VM hinweg ist nicht moeglich. Einzig overhead fuer caches ecc. kann zu einer erhoehter RAM Auslastung fuehren.
* Was wird innerhalb der VMs fuer eine RAM Auslastung angegeben?
* Gibt es Hinweise im syslog der Linux VM ueber zu wenig Speicher (OOM killer)?

 

[gmed]

Hi,

Ich denke, die Kuh ist erst mal vom Eis.
Wie man auf anhängendem Screenshot sieht, ist der RAM-Anstieg erst mal erledigt.

Der Tausch der Virtio-Treiber hat hier wohl ABhilfe geschafft.
Auch der Wechsel auf CIFS als Backup-Verbindung an Stelle von NFS hat sich positiv bemerkbar gemacht.
Backups laufen was 1/3 schneller und der IO Durchsatz ist ein gutes Stück höher.

Die Linux VM läuft auch bei dauerhaft ausgeführtem Firefox stabil und wurde noch nie abgeschossen.
Sie hat auch nie mehr RAM bekommen, als ihr zugewiesen ist.

Im Unterschied zur MS-Server VM, welche ja anfangs deutlich mehr RAM nutzte als die max. 16GB, die zugewiesen waren.

Danke für die Hilfsbereitschaft und Infos.

 

[Chris]

Hi,

Ich denke, die Kuh ist erst mal vom Eis.
Wie man auf anhängendem Screenshot sieht, ist der RAM-Anstieg erst mal erledigt.

Der Tausch der Virtio-Treiber hat hier wohl ABhilfe geschafft.
Auch der Wechsel auf CIFS als Backup-Verbindung an Stelle von NFS hat sich positiv bemerkbar gemacht.
Backups laufen was 1/3 schneller und der IO Durchsatz ist ein gutes Stück höher.

Die Linux VM läuft auch bei dauerhaft ausgeführtem Firefox stabil und wurde noch nie abgeschossen.
Sie hat auch nie mehr RAM bekommen, als ihr zugewiesen ist.

Im Unterschied zur MS-Server VM, welche ja anfangs deutlich mehr RAM nutzte als die max. 16GB, die zugewiesen waren.

Danke für die Hilfsbereitschaft und Infos.

Gut zu wissen das es sich mit dem virtio update scheinbar erledigt hat.