Hoher RAM Verbraucht durch VMs?
- Thread starter superwinni2
- Start date
Hi, die Diskrepanz zwischen den konfigurierten 512MB für VM 101 und der Resident Set Size (RES) von 1904MB aus dem htop-Screenshot ist allerdings merkwürdig. Die Configs schauen recht gewöhnlich aus. Einen gewissen Overhead durch QEMU könnte ich mir auch noch vorstellen, aber ~1.5GB scheinen dafür auch etwas exzessiv.
Es wäre schon interessant, herauszufinden, warum der RAM-Verbrauch so hoch ist. Könntest du den Output von den folgenden Kommandos posten?
Es wäre schon interessant, herauszufinden, warum der RAM-Verbrauch so hoch ist. Könntest du den Output von den folgenden Kommandos posten?
Code:
pveversion -v
grep '' /sys/kernel/mm/ksm/pages_*
cat /proc/$(cat /var/run/qemu-server/101.pid)/{status,cmdline}
Last edited:
Das QEMU auch etwas haben möchte ist verständlich und auch vollkommen in Ordnung.
Das Problem ist halt eher, dass wenn dies dann 10 VMs machen mein RAM ganz schnell ganz voll wird.
Das Problem ist halt eher, dass wenn dies dann 10 VMs machen mein RAM ganz schnell ganz voll wird.
Code:
root@proxmox1:~# pveversion -v
proxmox-ve: 8.0.1 (running kernel: 6.2.16-5-pve)
pve-manager: 8.0.3 (running version: 8.0.3/bbf3993334bfa916)
pve-kernel-6.2: 8.0.4
pve-kernel-5.15: 7.4-4
pve-kernel-6.2.16-5-pve: 6.2.16-6
pve-kernel-6.2.16-4-pve: 6.2.16-5
pve-kernel-6.2.16-3-pve: 6.2.16-3
pve-kernel-5.15.108-1-pve: 5.15.108-1
pve-kernel-5.15.107-2-pve: 5.15.107-2
pve-kernel-5.15.107-1-pve: 5.15.107-1
ceph-fuse: 16.2.11+ds-2
corosync: 3.1.7-pve3
criu: 3.17.1-2
glusterfs-client: 10.3-5
ifupdown: residual config
ifupdown2: 3.2.0-1+pmx3
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-3
libknet1: 1.25-pve1
libproxmox-acme-perl: 1.4.6
libproxmox-backup-qemu0: 1.4.0
libproxmox-rs-perl: 0.3.0
libpve-access-control: 8.0.3
libpve-apiclient-perl: 3.3.1
libpve-common-perl: 8.0.6
libpve-guest-common-perl: 5.0.3
libpve-http-server-perl: 5.0.4
libpve-rs-perl: 0.8.4
libpve-storage-perl: 8.0.2
libqb0: 1.0.5-1
libspice-server1: 0.15.1-1
lvm2: 2.03.16-2
lxc-pve: 5.0.2-4
lxcfs: 5.0.3-pve3
novnc-pve: 1.4.0-2
proxmox-backup-client: 3.0.1-1
proxmox-backup-file-restore: 3.0.1-1
proxmox-kernel-helper: 8.0.2
proxmox-mail-forward: 0.2.0
proxmox-mini-journalreader: 1.4.0
proxmox-offline-mirror-helper: 0.6.2
proxmox-widget-toolkit: 4.0.6
pve-cluster: 8.0.2
pve-container: 5.0.4
pve-docs: 8.0.4
pve-edk2-firmware: 3.20230228-4
pve-firewall: 5.0.3
pve-firmware: 3.7-1
pve-ha-manager: 4.0.2
pve-i18n: 3.0.5
pve-qemu-kvm: 8.0.2-3
pve-xtermjs: 4.16.0-3
qemu-server: 8.0.6
smartmontools: 7.3-pve1
spiceterm: 3.3.0
swtpm: 0.8.0+pve1
vncterm: 1.8.0
zfsutils-linux: 2.1.12-pve1
Code:
root@proxmox1:~# grep '' /sys/kernel/mm/ksm/pages_*
/sys/kernel/mm/ksm/pages_shared:109884
/sys/kernel/mm/ksm/pages_sharing:461803
/sys/kernel/mm/ksm/pages_to_scan:1250
/sys/kernel/mm/ksm/pages_unshared:820733
/sys/kernel/mm/ksm/pages_volatile:72493
Code:
root@proxmox1:~# cat /proc/$(cat /var/run/qemu-server/101.pid)/{status,cmdline}
Name: kvm
Umask: 0027
State: S (sleeping)
Tgid: 1855969
Ngid: 0
Pid: 1855969
PPid: 1
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 256
Groups:
NStgid: 1855969
NSpid: 1855969
NSpgid: 1855967
NSsid: 1855967
VmPeak: 5851568 kB
VmSize: 5851568 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 2042772 kB
VmRSS: 2007212 kB
RssAnon: 1997996 kB
RssFile: 9216 kB
RssShmem: 0 kB
VmData: 4979116 kB
VmStk: 972 kB
VmExe: 6220 kB
VmLib: 45776 kB
VmPTE: 9692 kB
VmSwap: 0 kB
HugetlbPages: 0 kB
CoreDumping: 0
THP_enabled: 1
Threads: 15
SigQ: 2/63362
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000010002240
SigIgn: 0000000000381000
SigCgt: 0000000100004243
CapInh: 0000000000000000
CapPrm: 000001ffffffffff
CapEff: 000001ffffffffff
CapBnd: 000001ffffffffff
CapAmb: 0000000000000000
NoNewPrivs: 0
Seccomp: 0
Seccomp_filters: 0
Speculation_Store_Bypass: vulnerable
SpeculationIndirectBranch: always enabled
Cpus_allowed: ff
Cpus_allowed_list: 0-7
Mems_allowed: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
Mems_allowed_list: 0
voluntary_ctxt_switches: 1435440
nonvoluntary_ctxt_switches: 335873
/usr/bin/kvm-id101-nameOMV5,debug-threads=on-no-shutdown-chardevsocket,id=qmp,path=/var/run/qemu-server/101.qmp,server=on,wait=off-monchardev=qmp,mode=control-chardevsocket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect=5-monchardev=qmp-event,mode=control-pidfile/var/run/qemu-server/101.pid-daemonize-smbiostype=1,uuid=a3c34b44-a055-4d28-94ee-bf00e18699f4-smp2,sockets=1,cores=2,maxcpus=2-nodefaults-bootmenu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg-vncunix:/var/run/qemu-server/101.vnc,password=on-cpuhost,+kvm_pv_eoi,+kvm_pv_unhalt-m512-objectiothread,id=iothread-virtio0-objectiothread,id=iothread-virtio1-objectiothread,id=iothread-virtio2-objectiothread,id=iothread-virtio3-objectiothread,id=iothread-virtio4-devicepci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e-devicepci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f-devicevmgenid,guid=d31e42a6-0876-4494-98bb-b40236134407-devicepiix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2-deviceusb-tablet,id=tablet,bus=uhci.0,port=1-chardevsocket,id=serial0,path=/var/run/qemu-server/101.serial0,server=on,wait=off-deviceisa-serial,chardev=serial0-deviceVGA,id=vga,bus=pci.0,addr=0x2-chardevsocket,path=/var/run/qemu-server/101.qga,server=on,wait=off,id=qga0-devicevirtio-serial,id=qga0,bus=pci.0,addr=0x8-devicevirtserialport,chardev=qga0,name=org.qemu.guest_agent.0-devicevirtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3,free-page-reporting=on-iscsiinitiator-name=iqn.1993-08.org.debian:01:a32a56846ef-driveif=none,id=drive-ide2,media=cdrom,aio=io_uring-deviceide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200-drivefile=/dev/pve/vm-101-disk-0,if=none,id=drive-virtio0,discard=on,format=raw,cache=none,aio=io_uring,detect-zeroes=unmap-devicevirtio-blk-pci,drive=drive-virtio0,id=virtio0,bus=pci.0,addr=0xa,iothread=iothread-virtio0,bootindex=100-drivefile=/dev/pve/vm-101-disk-1,if=none,id=drive-virtio1,discard=on,format=raw,cache=none,aio=io_uring,detect-zeroes=unmap-devicevirtio-blk-pci,drive=drive-virtio1,id=virtio1,bus=pci.0,addr=0xb,iothread=iothread-virtio1-drivefile=/dev/pve/vm-101-disk-2,if=none,id=drive-virtio2,discard=on,format=raw,cache=none,aio=io_uring,detect-zeroes=unmap-devicevirtio-blk-pci,drive=drive-virtio2,id=virtio2,bus=pci.0,addr=0xc,iothread=iothread-virtio2-drivefile=/dev/pve/vm-101-disk-4,if=none,id=drive-virtio3,discard=on,format=raw,cache=none,aio=io_uring,detect-zeroes=unmap-devicevirtio-blk-pci,drive=drive-virtio3,id=virtio3,bus=pci.0,addr=0xd,iothread=iothread-virtio3-drivefile=/dev/pve/vm-101-disk-3,if=none,id=drive-virtio4,discard=on,format=raw,cache=none,aio=io_uring,detect-zeroes=unmap-devicevirtio-blk-pci,drive=drive-virtio4,id=virtio4,bus=pci.0,addr=0xe,iothread=iothread-virtio4-netdevtype=tap,id=net0,ifname=tap101i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on-devicevirtio-net-pci,mac=D2:45:17:4E:E7:37,netdev=net0,bus=pci.0,addr=0x12,id=net0,rx_queue_size=1024,tx_queue_size=1024,bootindex=300-machinetype=pc+pve0Danke. Ich kann lokal reproduzieren, dass der RAM-Verbrauch des QEMU-Prozesses massiv ansteigt, wenn ein Backup auf PBS gemacht wird -- allerdings nur, wenn die VM virtio -Disks verwendet. Dann scheint der RAM-Verbrauch proportional zur Anzahl der virtio-Disks zu steigen. Das würde erklären, warum deine VM 101 ca 1.5GB zuviel RAM verbraucht (denn das Backup beinhaltet 3 virtio-Disks), während die VM 110 "nur" 1GB zuviel RAM verbraucht (das Backup beinhaltet nur 2 virtio-Disks). Ich werde mal versuchen herauszufinden, woran das liegt.
Derweil könntest du versuchen, statt virtio-Disks scsi-Disks (mit dem SCSI-Controller VirtIO SCSI Single) zu verwenden und zu schauen, ob der RAM-Verbrauch nach dem Backup weiterhin so stark steigt. SCSI-Disks und VirtIO SCSI Single sind auch der Default bei neu erstellen VMs [1].
[1] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#qm_hard_disk
Derweil könntest du versuchen, statt virtio-Disks scsi-Disks (mit dem SCSI-Controller VirtIO SCSI Single) zu verwenden und zu schauen, ob der RAM-Verbrauch nach dem Backup weiterhin so stark steigt. SCSI-Disks und VirtIO SCSI Single sind auch der Default bei neu erstellen VMs [1].
[1] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#qm_hard_disk
Habe alles umgestellt und den Backup Job von Hand gestartet.
Sieht erstmal besser aus wenn auch noch nicht ganz perferkt oder?
Laut GUI sind 10.27 GiB belegt. Weniger als vorher bei mehr VMs.
Hier noch ein Auszug aus den Configs sowie htop:
Sieht erstmal besser aus wenn auch noch nicht ganz perferkt oder?
Laut GUI sind 10.27 GiB belegt. Weniger als vorher bei mehr VMs.
Hier noch ein Auszug aus den Configs sowie htop:
Code:
Config: Wert: htop RES:
101.conf 512 1282M
103.conf 512 837M
105.conf 512 779M
107.conf 320 502M
108.conf 320 496M
109.conf 384 368M
110.conf 1024 1160M
111.conf 288 635M
112.conf 256 436M
114.conf 1024 583M
116.conf 2048 1809M
191.conf 1024 1257M
SUMME: 8224 10144MNun ist auch das automatische Backup gelaufen.
Nun sind die Werte wie folgt:
Mich wundert es noch immer warum die VMs mehr RAM im Einsatz haben als zugewiesen. Bissel mehr ist ja in Ordnung. Aber bei VM101 sind es ja weiterhin über das Doppelte.
Habe nun erstmal das Backup deaktiviert und den Server neugestartet und ein paar Minuten hochfahren lassen damit alles gestartet ist. Dann kann ich morgen vergleichen ob es auch noch anderweitig Auswirkungen hat.
Das wären die Zahlen nach dem neustart:
Nun sind die Werte wie folgt:
Code:
Config: Wert: htop RES:
101.conf 512 1310M
103.conf 512 843M
104.conf 512 643M
105.conf 512 785M
107.conf 320 494M
108.conf 320 505M
109.conf 384 384M
110.conf 1024 1229M
111.conf 288 405M
112.conf 256 449M
114.conf 1024 1157M
116.conf 2048 1993M
191.conf 1024 1276M
SUMME: 8736 11473MMich wundert es noch immer warum die VMs mehr RAM im Einsatz haben als zugewiesen. Bissel mehr ist ja in Ordnung. Aber bei VM101 sind es ja weiterhin über das Doppelte.
Habe nun erstmal das Backup deaktiviert und den Server neugestartet und ein paar Minuten hochfahren lassen damit alles gestartet ist. Dann kann ich morgen vergleichen ob es auch noch anderweitig Auswirkungen hat.
Das wären die Zahlen nach dem neustart:
Code:
Config: Wert: htop RES:
101.conf 512 533M
103.conf 512 504M
104.conf 512 535M
105.conf 512 526M
107.conf 320 348M
108.conf 320 362M
109.conf 384 263M
110.conf 1024 1068M
111.conf 288 277M
112.conf 256 288M
114.conf 1024 475M
116.conf 2048 1512M
191.conf 1024 1074M
SUMME: 8736 7765MInzwischen ist Montag. Ich habe am Sonntag nichts am System verändert oder gemacht.
Die RAM Auslastung sieht vollkommen in Ordnung aus.
Laut GUI werden 8.44 GiB benutzt.
Laut htop ist der RAM wie folgt belegt:
Somit hat die Veränderung von virtio zu SCSI eine erhebliche Verbesserung gebracht wenn man Proxmox Backup Server einsetzt.
Vielen Dank nochmals!
Die RAM Auslastung sieht vollkommen in Ordnung aus.
Laut GUI werden 8.44 GiB benutzt.
Laut htop ist der RAM wie folgt belegt:
Code:
Mem: 15.5G
used:7.86G
buffers: 637M
shared 68M
cache: 3.98G
available: 7.24G
Code:
Config: Wert: htop RES:
101.conf 512 509M
103.conf 512 556M
104.conf 512 553M
105.conf 512 554M
107.conf 320 352M
108.conf 320 362M
109.conf 384 283M
110.conf 1024 1016M
111.conf 288 287M
112.conf 256 294M
114.conf 1024 941M
116.conf 2048 1731M
191.conf 1024 1075M
SUMME: 8736 8513MSomit hat die Veränderung von virtio zu SCSI eine erhebliche Verbesserung gebracht wenn man Proxmox Backup Server einsetzt.
Vielen Dank nochmals!
Hi, danke fürs Ausprobieren und die Rückmeldung. Freut mich, dass der Umstieg zu SCSI erstmal hilft.
@fiona und ich haben uns das Problem nochmal angesehen, und tatsächlich scheint auch bei SCSI-Disks der RAM-Verbrauch nach dem PBS-Backup ziemlich anzusteigen, nur nicht ganz so massiv wie bei VirtIO-Disks. Das deckt sich auch mit deinem ersten Listing aus Post #27. Wir schauen uns das weiter an und ich werde nochmal hier posten, wenn sich etwas neues ergibt.
Noch ein Tipp: Wenn du den Speicherverbrauch des QEMU-Prozesses für eine VM wissen willst, kannst du auch folgendes Kommando benutzen (
Das ist etwas komfortabler als den Verbrauch aus htop abzulesen.
Das schaut tatsächlich besser aus. Eine Verständnisfrage: Ist hier seit dem Reboot denn ein Backup gelaufen?
@fiona und ich haben uns das Problem nochmal angesehen, und tatsächlich scheint auch bei SCSI-Disks der RAM-Verbrauch nach dem PBS-Backup ziemlich anzusteigen, nur nicht ganz so massiv wie bei VirtIO-Disks. Das deckt sich auch mit deinem ersten Listing aus Post #27. Wir schauen uns das weiter an und ich werde nochmal hier posten, wenn sich etwas neues ergibt.
Noch ein Tipp: Wenn du den Speicherverbrauch des QEMU-Prozesses für eine VM wissen willst, kannst du auch folgendes Kommando benutzen (
VMID durch die ID ersetzen):
Code:
grep VmRSS /proc/$(cat /var/run/qemu-server/VMID.pid)/status
Hi,
es gibt jetzt einen Änderungsvorschlag auf der Developer-Mailing-Liste: https://lists.proxmox.com/pipermail/pve-devel/2023-August/058756.html
Nachdem das diskutiert wird und falls es für richtig und sinnvoll befunden wird, wird es in künftige Versionen eingepflegt werden.
EDIT: Ein bisschen einen Overhead wird es allerdings immer geben, selbst mit dem Trimmen kann ein bisschen was übrigbleiben. Und proportional zur Disk-Größe für die dirty Bitmaps wird auch Speicher benötigt. Diese werden für PBS benutzt, um sich zu merken, welche Blöcke sich seit dem letzten Backup geändert haben.
Und nochmal Danke für den Report!
es gibt jetzt einen Änderungsvorschlag auf der Developer-Mailing-Liste: https://lists.proxmox.com/pipermail/pve-devel/2023-August/058756.html
Nachdem das diskutiert wird und falls es für richtig und sinnvoll befunden wird, wird es in künftige Versionen eingepflegt werden.
EDIT: Ein bisschen einen Overhead wird es allerdings immer geben, selbst mit dem Trimmen kann ein bisschen was übrigbleiben. Und proportional zur Disk-Größe für die dirty Bitmaps wird auch Speicher benötigt. Diese werden für PBS benutzt, um sich zu merken, welche Blöcke sich seit dem letzten Backup geändert haben.
Und nochmal Danke für den Report!
Last edited:
Ach mist. Habe ja das Backup deaktiviert. Somit ist kein Backup gelaufen.
Habe dieses nun wieder aktiviert. Werde vermutlich gegen 12 Uhr den Job von Hand starten und dann nochmals berichten.
Vielleicht gibt dies ein paar mehr Infos die vielleicht helfen.
Danke für den Tipp mit dem auslesen der RAM Informationen! Bei den paar VMs geht das noch.
Etwas Overhead an sich ist vollkommen in Ordnung. Irgendwelche Ressourcen braucht der PVE ja selbst auch.
Gestern war leider zu viel los um nochmals zu Berichten. Daher kommt der Bericht erst jetzt...
In der GUI sehe ich, dass um 12 Uhr (Backupstart) der RAM verbrauch von ~8,6 GiB (12:00 Uhr) zu 10,12 GiB (12:30 Uhr) gestiegen ist.
Auch nun ist der RAM Verbrauch bei ~10,77 GiB laut GUI und 10,38 GiB in der Statistik.
In der GUI sehe ich, dass um 12 Uhr (Backupstart) der RAM verbrauch von ~8,6 GiB (12:00 Uhr) zu 10,12 GiB (12:30 Uhr) gestiegen ist.
Auch nun ist der RAM Verbrauch bei ~10,77 GiB laut GUI und 10,38 GiB in der Statistik.
Code:
Mem: 15.5G
used: 10.1G
buffers: 504M
shared 65M
cache: 4.59G
available: 4.98G
Code:
Config: Wert: htop RES:
101.conf 512 753M
103.conf 1024 1318M
104.conf 512 611M
105.conf 512 575M
107.conf 320 434M
108.conf 320 459M
109.conf 384 479M
110.conf 1024 1103M
111.conf 288 475M
112.conf 256 350M
114.conf 1024 1053M
116.conf 2048 1911M
191.conf 1024 1214M
SUMME: 8736 10735MBackup ist gelaufen.
Sieht alles weiterhin aus wie davor. Paar MB unterschiede gibt es aber das ist ja so bei einem laufendem System. Nicht das auffällig hoch oder niedrig wäre.
Sieht alles weiterhin aus wie davor. Paar MB unterschiede gibt es aber das ist ja so bei einem laufendem System. Nicht das auffällig hoch oder niedrig wäre.