Speicherfresser univention-virtual-machine-manager-daemon?

Hallo,

wir beobachten hier schon seit längerem, dass auf unseren Virtualisierungshosts langsam aber stetig erst der RAM und anschließend der Swap-Speicher zunehmend beansprucht wird, so dass wir in regelmäßigen Abständen die Hosts (und damit auch die virtuellen Maschinen darauf) rebooten müssen, um Crashs zu vermeiden. Nachdem wir jetzt angefangen haben, überall RAM aufzurüsten, ist das Problem zwar abgemildert, weil wir jetzt wesentlich seltener rebooten müssen, aber eben noch nicht vom Tisch.

Mutmaßlicher Auslöser ist der univention-virtual-machine-manager-daemon, der stetisch mehr RAM benutzt.

[code]top - 15:15:28 up 76 days, 4:40, 1 user, load average: 0.24, 0.37, 0.41
Tasks: 206 total, 1 running, 203 sleeping, 0 stopped, 2 zombie
Cpu(s): 3.5%us, 0.4%sy, 0.0%ni, 96.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 24640836k total, 21562720k used, 3078116k free, 5736k buffers
Swap: 10485756k total, 7729356k used, 2756400k free, 64420k cached

PID USER PR NI VIRT RES SHR S %CPU TIME+ %MEM COMMAND
173645 libvirt- 20 0 8880m 7.0g 768 S 42 8571:36 30.0 kvm
146129 root 20 0 7474m 5.8g 2812 S 2 911:10.15 24.8 univention-virt
2710 libvirt- 20 0 8828m 3.3g 760 S 0 6351:08 14.0 kvm
2691 libvirt- 20 0 4449m 3.1g 764 S 8 10907:30 13.2 kvm[/code]

Die drei kvm-Prozesse sind drei virtuelle Maschinen. Der Speicherverbrauch bleibt, auch wenn sämtliche virtuellen Maschinen heruntergefahren wurden:

[code]top - 15:26:03 up 76 days, 4:51, 1 user, load average: 0.08, 1.05, 0.99
Tasks: 217 total, 1 running, 214 sleeping, 0 stopped, 2 zombie
Cpu(s): 2.1%us, 0.3%sy, 0.0%ni, 97.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 24640836k total, 6700676k used, 17940160k free, 5484k buffers
Swap: 10485756k total, 608544k used, 9877212k free, 73960k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
146129 root 20 0 7475m 5.8g 2812 S 4 24.8 911:25.89 univention-virt
[/code]

Nach einem Reboot sieht alles wieder normal aus:

[code]top - 15:36:20 up 7 min, 1 user, load average: 0.65, 1.27, 0.77
Tasks: 197 total, 1 running, 196 sleeping, 0 stopped, 0 zombie
Cpu(s): 3.0%us, 0.4%sy, 0.0%ni, 94.9%id, 1.8%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 24640836k total, 7230108k used, 17410728k free, 66696k buffers
Swap: 10485756k total, 0k used, 10485756k free, 127816k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2779 libvirt- 20 0 4385m 3.9g 6020 S 33 16.7 2:32.01 kvm
2759 libvirt- 20 0 9110m 1.7g 6072 S 12 7.4 1:58.64 kvm
2739 libvirt- 20 0 8680m 643m 6064 S 3 2.7 1:02.18 kvm
1671 root 20 0 1165m 34m 11m S 3 0.1 0:06.91 univention-virt
[/code]

Das Problem tritt bei uns sowohl unter UCS 3.1 als auch unter 3.2 auf - ausnahmslos auf jedem Host.

Hat sonst irgendwo jemand dieses Verhalten beobachtet und gibt es vielleicht Möglichkeiten, das Problem ohne Reboot zu beheben?

Hallo,

ein Neustart vom UVMMD wirkt sich nach meiner Erfahrung nicht auf laufende VMs aus.

root@kvm:~# free total used free shared buffers cached Mem: 16171880 13451460 2720420 0 215496 264388 -/+ buffers/cache: 12971576 3200304 Swap: 10485756 2226140 8259616 root@kvm:~# /etc/init.d/univention-virtual-machine-manager-daemon restart [ ok ] Restarting UCS Virtual Machine Manager: univention-virtual-machine-manager-daemon. root@kvm:~# free total used free shared buffers cached Mem: 16171880 10424604 5747276 0 215496 264392 -/+ buffers/cache: 9944716 6227164 Swap: 10485756 2226140 8259616

Inzwischen scheint die Ursache aber gefunden. [bug]36640[/bug] steht auf resolved, allerdings sieht es für mich so aus, als wenn es erstmal nur für UCS 4 ein Erratum gibt.

Viele Grüße,
Dirk Ahrnke

[quote=“ahrnke”]Inzwischen scheint die Ursache aber gefunden. [bug]36640[/bug] steht auf resolved, allerdings sieht es für mich so aus, als wenn es erstmal nur für UCS 4 ein Erratum gibt.
[/quote]

Ich rechne damit, dass wir nächste Woche mit der QA durch sind und danach veröffentlichen können.

Viele Grüße
Stefan

Hallo,

ich schätze, diesen Erfahrungswert kann ich jetzt bestätigen. Ein Cronjob, der genau das einmal die Woche macht, sollte für unsere Zwecke vorläufig ausreichend sein.

Vielen Dank und frohe Ostern!
Thomas

Mastodon