Ubuntu KVM große Dateien kopieren System friert ein.

G

goifalracer

Member
Mar 29, 2023
79
3
8
Hallo,

Ich habe unter PMX 8 eine Ubuntu 22.04 VM am laufen.
Das ganze funktioniert zufriedenstellend.
Jedoch habe ich Probleme beim kopieren von größeren Dateien von einer Qnap (NFS Freigabe) auf die Ubuntu VM.
Die ZIP Datei ist 3Gb groß.
Wenn ich den Kopiervorgang starte läuft es erst flüssig, dann friert mir die ganze VM ein. Sogar die GUI vom PMX Server verliert kurz die Verbindung.
Die VM lässt sich nur durch neustarten wiederbeleben.
Auslastung lt Htop nicht mal bei 5% CPU.
Kann mir hier jemand einen Tipp geben?
Bei kleinen Dateien z.B. 300Mb, geht das kopieren blitzschnell. Auch der umgekehrte Weg, Kopiervorgang von VM zur Qnap läuft auch bei 4 Gb flüssig.

Danke...
 
Wenn alles einfriert könnte es an der Disk liegen, dass da ein fehlerhafter Sektor ist oder RAM befüllt sich komplett. Da musst du dir die Logs in der VM anschauen, außer du hast I/O Delay im Host.
 
Hardware ist nagelneu. Kann ich mir fast nicht vorstellen.
Der RAM der VM ist auf 95 %, der RAM vom Host ist bei 40 %.
Die 95 % sind aber eigentlich immer belegt, warum weiß ich nicht, ich habe der VM 6 GB zur Verfügung gestellt. Balloning habe ich aktiviert.


Die CPU ist nicht wirklich ausgelastet.

Meinst du den Syslog vom Node selbst?
 
Direkt im Dashboard siehst du den Delay. Wird auch schön als Graph mit angezeigt.
Dann guck mal in die Logs der VM.
 
I starte Abends mal nochmal einen Kopiervorgang und schaue den IO Delay an, aber ich meine das der gestern nie über 40 % war und im syslog war auch kein OoM.
Den log der VM schaue ich mir auch an.
Ich habe die NFS Freigabe von der ich die Datei kopiere mir der GUI über den Dateimanager von Ubuntu temporär eingehängt.
Bin zu doof das über die fstab zu lösen.
Ich habe den Verdacht das mir der Dateimangaer einfriert und mir die ganze VM mit runterzieht.
Wenn das mit dem mounten in fstab klappen würde dann könnte ich den Kopiervorgang mal mit dem command 'cp' anstoßen. Vielleicht klappt es hier besser.
 
Wenn du schon 40% Delay hast, läuft schon etwas nicht richtig. Ich habe nie über 5%.
 
Ja 40% ist schon sehr sehr hoch. Welche Hardware verwendest du? Welchen Storgaespeicher und welchen Typ? Also LVM, ZFS...
 
Also habe gerade nochmal 3 Gb von meinem Qnap, auf ein Ubuntu in den Home Ordner übertragen. Dann ist die VM wieder eingfroren.
Die NFS Freigabe habe ich temporär mit dem Dateimanager eingebunden.
Ich hatte nach ca. 1 min 95 % IO Delay.

Ich habe einen NUC 12 mit i3 ich glaube 12 Gen. mit 32 Gb RAM.
2 x SATA als ZFS1 RAID. 512 Gb.

Der VM die Probleme macht habe ich 6 GB RAM und 4 Kerne zugewiesen. Das sollte doch reichen oder?
Eine identische VM tuckelt auch noch vor sich hin und ein Ubuntu LXC Container.

Das Logfile der VM ist hier, zwischen 10:46 und 10:49 wurde der Vorgang ausgeführt.
Das Passiert erst ab Datein über 1 GB, vielleicht reicht der Cache nicht aus?

Code: 
Jan 31 10:43:08 UbuntuVMSymconTest systemd[1242]: Starting Tracker metadata extractor...
Jan 31 10:43:08 UbuntuVMSymconTest dbus-daemon[1264]: [session uid=1000 pid=1264] Successfully activated service 'org.freedesktop.Tracker3.Miner.Extract'
Jan 31 10:43:08 UbuntuVMSymconTest systemd[1242]: Started Tracker metadata extractor.
Jan 31 10:43:16 UbuntuVMSymconTest systemd[1]: fprintd.service: Deactivated successfully.
Jan 31 10:45:48 UbuntuVMSymconTest systemd[1]: Starting Daily apt download activities...
Jan 31 10:45:49 UbuntuVMSymconTest systemd[1]: apt-daily.service: Deactivated successfully.
Jan 31 10:45:49 UbuntuVMSymconTest systemd[1]: Finished Daily apt download activities.
Jan 31 10:45:50 UbuntuVMSymconTest dbus-daemon[1264]: [session uid=1000 pid=1264] Activating via systemd: service name='org.freedesktop.Tracker3.Miner.Extract' unit='tracker-extract-3.service' requested by ':1.7' (uid=1000 pid=1315 comm="/usr/libexec/tracker-miner-fs-3 " label="unconfined")
Jan 31 10:45:50 UbuntuVMSymconTest systemd[1242]: Starting Tracker metadata extractor...
Jan 31 10:45:50 UbuntuVMSymconTest dbus-daemon[1264]: [session uid=1000 pid=1264] Successfully activated service 'org.freedesktop.Tracker3.Miner.Extract'
Jan 31 10:45:50 UbuntuVMSymconTest systemd[1242]: Started Tracker metadata extractor.
Jan 31 10:48:30 UbuntuVMSymconTest qemu-ga: info: guest-ping called
Jan 31 10:48:40 UbuntuVMSymconTest dbus-daemon[1264]: [session uid=1000 pid=1264] Activating via systemd: service name='org.freedesktop.Tracker3.Miner.Extract' unit='tracker-extract-3.service' requested by ':1.7' (uid=1000 pid=1315 comm="/usr/libexec/tracker-miner-fs-3 " label="unconfined")
Jan 31 10:48:40 UbuntuVMSymconTest systemd[1242]: Starting Tracker metadata extractor...
Jan 31 10:48:41 UbuntuVMSymconTest qemu-ga: info: guest-ping called
Jan 31 10:48:42 UbuntuVMSymconTest dbus-daemon[1264]: [session uid=1000 pid=1264] Successfully activated service 'org.freedesktop.Tracker3.Miner.Extract'
Jan 31 10:48:42 UbuntuVMSymconTest systemd[1242]: Started Tracker metadata extractor.
Jan 31 10:48:52 UbuntuVMSymconTest qemu-ga: info: guest-ping called
Jan 31 10:49:13 UbuntuVMSymconTest qemu-ga: message repeated 2 times: [ info: guest-ping called]
Jan 31 10:49:18 UbuntuVMSymconTest nautilus[21849]: Called "net usershare info" but it failed: Kindprozess »net« konnte nicht ausgeführt werden (No such file or directory)
Jan 31 10:49:24 UbuntuVMSymconTest qemu-ga: info: guest-ping called
Jan 31 10:49:25 UbuntuVMSymconTest dbus-daemon[1264]: [session uid=1000 pid=1264] Activating service name='org.gnome.gedit' requested by ':1.124' (uid=1000 pid=21849 comm="/usr/bin/nautilus --gapplication-service " label="unconfined")
Jan 31 10:49:25 UbuntuVMSymconTest dbus-daemon[1264]: [session uid=1000 pid=1264] Successfully activated service 'org.gnome.gedit'
Jan 31 10:49:28 UbuntuVMSymconTest avahi-daemon[448]: Registering new address record for 2003:e1:2f43:a500:3aed:aa26:8d96:3097 on ens18.*.
Jan 31 10:49:28 UbuntuVMSymconTest avahi-daemon[448]: Withdrawing address record for 2003:e1:2f43:a500:516c:1b6f:aa73:bb35 on ens18.
Jan 31 10:49:28 UbuntuVMSymconTest avahi-daemon[448]: Withdrawing address record for 2003:e1:2f43:a500:559c:7777:263f:77b1 on ens18.
Jan 31 10:49:28 UbuntuVMSymconTest avahi-daemon[448]: Withdrawing address record for 2003:e1:2f43:a500:cd3b:16b8:98e5:ecb0 on ens18.
Jan 31 10:49:28 UbuntuVMSymconTest avahi-daemon[448]: Withdrawing address record for 2003:e1:2f43:a500:4f0a:87c8:82f0:1847 on ens18.
Jan 31 10:49:28 UbuntuVMSymconTest avahi-daemon[448]: Withdrawing address record for 2003:e1:2f43:a500:690f:d21d:905c:2876 on ens18.
Jan 31 10:49:28 UbuntuVMSymconTest avahi-daemon[448]: Withdrawing address record for 2003:e1:2f43:a500:c26b:5469:7c06:d6c5 on ens18.
Jan 31 10:49:28 UbuntuVMSymconTest avahi-daemon[448]: Withdrawing address record for 192.168.178.146 on ens18.
Jan 31 10:49:28 UbuntuVMSymconTest avahi-daemon[448]: Withdrawing address record for ::1 on lo.
Jan 31 10:49:28 UbuntuVMSymconTest avahi-daemon[448]: Withdrawing address record for 127.0.0.1 on lo.
Jan 31 10:49:28 UbuntuVMSymconTest avahi-daemon[448]: Host name conflict, retrying with UbuntuVMSymconTest-139
Jan 31 10:49:28 UbuntuVMSymconTest avahi-daemon[448]: Registering new address record for 2003:e1:2f43:a500:3aed:aa26:8d96:3097 on ens18.*.
Jan 31 10:49:28 UbuntuVMSymconTest avahi-daemon[448]: Registering new address record for 2003:e1:2f43:a500:516c:1b6f:aa73:bb35 on ens18.*.
Jan 31 10:49:28 UbuntuVMSymconTest avahi-daemon[448]: Registering new address record for 2003:e1:2f43:a500:559c:7777:263f:77b1 on ens18.*.
Jan 31 10:49:28 UbuntuVMSymconTest avahi-daemon[448]: Registering new address record for 2003:e1:2f43:a500:cd3b:16b8:98e5:ecb0 on ens18.*.
Jan 31 10:49:28 UbuntuVMSymconTest avahi-daemon[448]: Registering new address record for 2003:e1:2f43:a500:4f0a:87c8:82f0:1847 on ens18.*.
Jan 31 10:49:28 UbuntuVMSymconTest avahi-daemon[448]: Registering new address record for 2003:e1:2f43:a500:690f:d21d:905c:2876 on ens18.*.
Jan 31 10:49:28 UbuntuVMSymconTest avahi-daemon[448]: Registering new address record for 2003:e1:2f43:a500:c26b:5469:7c06:d6c5 on ens18.*.
Jan 31 10:49:28 UbuntuVMSymconTest avahi-daemon[448]: Registering new address record for 192.168.178.146 on ens18.IPv4.
Jan 31 10:49:28 UbuntuVMSymconTest avahi-daemon[448]: Registering new address record for ::1 on lo.*.
Jan 31 10:49:28 UbuntuVMSymconTest avahi-daemon[448]: Registering new address record for 127.0.0.1 on lo.IPv4.
Jan 31 10:49:29 UbuntuVMSymconTest kernel: [38985.704788] IPv6: ens18: IPv6 duplicate address 2003:e1:2f43:a500:3aed:aa26:8d96:3097 used by bc:24:11:b2:1a:94 detected!
Jan 31 10:49:29 UbuntuVMSymconTest avahi-daemon[448]: Withdrawing address record for 2003:e1:2f43:a500:3aed:aa26:8d96:3097 on ens18.
Jan 31 10:49:29 UbuntuVMSymconTest avahi-daemon[448]: Registering new address record for 2003:e1:2f43:a500:4492:223e:4b6c:2f9a on ens18.*.
Jan 31 10:49:29 UbuntuVMSymconTest gnome-shell[1404]: meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed
Jan 31 10:49:30 UbuntuVMSymconTest avahi-daemon[448]: Server startup complete. Host name is UbuntuVMSymconTest-139.local. Local service cookie is 411533920.
Jan 31 10:49:34 UbuntuVMSymconTest qemu-ga: info: guest-ping called
Jan 31 10:49:45 UbuntuVMSymconTest qemu-ga: info: guest-ping called
Jan 31 10:49:46 UbuntuVMSymconTest dbus-daemon[1264]: [session uid=1000 pid=1264] Activating service name='org.gnome.gedit' requested by ':1.124' (uid=1000 pid=21849 comm="/usr/bin/nautilus --gapplication-service " label="unconfined")
Jan 31 10:49:46 UbuntuVMSymconTest dbus-daemon[1264]: [session uid=1000 pid=1264] Successfully activated service 'org.gnome.gedit'
Jan 31 10:49:46 UbuntuVMSymconTest gnome-shell[1404]: meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed
 
Wenn du 95% Delay hast, muss die VM ja einfrieren, da auf der Disk nix mehr geht. Ist das eventuell eine günstige QLC SSD? Wenn der Cache vollläuft hält die alles an, bis die Daten geschrieben wurden.
 
Ich habe eine eine Smasung EVO 2280 NVMe und eine Transcend 2242 NVMe zum ZFS Raid 1 zusammengefasst. Beider 512 Gb.
Wenn ich die Dateien zurück auf das NAS kopiere, ist alles OK, der IO Delay ist max bei 1 %.
Dann muss es am CACHE liegen oder?
Meinst du es ist die NVMe?
Die SSD von Transcend sollte eine TLC sein. Und die Samsung EVO sind ja normal super.
 
Last edited:
Für Clients sind SSDs gut geeignet, für ZFS eher nicht. Ich denke mal wenn der Cache voll ist, gehen die SSDs voll auf die Bretter.
In der Regel schaffen die dann 20-30 MB/s und wenn du den Cache vorher voll geknallt hast, dauert das gern ein paar Minuten bis der wieder leer ist.
Deshalb für ZFS nur SSDs mit PLP kaufen.
 
Ja die Hardware ist jetzt da und auch Nagelneu.
ZFS im RAID 1 mit Proxmox hat für mich viele Vorteile für meine Homeautomation.
Und der Intel NUCist stromsparend.
Deswegen die Entscheidung.

Kann ich jetzt hier irgendwas optimieren damit das System trotzdem stabil läuft bei solchen Kopiervorgängen?
Will mir jetzt keine neue Hardware anschaffen...
 
Entweder damit leben oder neu installieren mit z.B. BTRFS oder md Raid. Dann werden die SSDs nicht so schnell tot geschrieben.
 
Falk R. said:
Entweder damit leben oder neu installieren mit z.B. BTRFS oder md Raid. Dann werden die SSDs nicht so schnell tot geschrieben.
Click to expand...
Oja, bei unserem Test waren die EVO's nach 8 Monaten hinüber...
 
Wäre vielleicht einer von euch so nett und würde mir eine Produktempfehlung für eine NVMe 2280 und eine 2.5 Zoll SSD beide mit PLP vorschlagen?
Falls das hier erlaubt ist. Ich will nicht schon wieder das falsche kaufen.
Ich möchte auch bei ZFS bleiben.

Bei 500 GB Plattengrösse sollten die Dinger nicht so teuer sein....

Mein NUC hat leider nur einen Sata Anschluss die anderen beiden sind 2280 und 2242.

Danke.
 
Ist die Destination eine VM mit einer virtuellen Platte?

Um die IO-Last (auf der physisch vorhandenen SSD) zu reduzieren kann man den Durchsatz pro VM, also pro virtueller Platte, bremsen. <VM> --> Hardware --> <Hard Disk> --> Edit --> zweiter Tab = Bandwidth.

Das erscheint kontraproduktiv und man will das auch normalerweise nicht. Aber eine Reduzierung entlastet das physische System "unter" der virtuellen Hardware.

Vielleicht magst du das mal testen...
 
Danke Udo,


also ich habe jetzt die Bandwith auf

1706711522076.png

eingestellt, könnte man hier noch mehr optimieren.?
Der IO Delay ging schon kurz mal auf 40 %, aber das System lies sich unterm Kopiervorgang flüssig bedienen.

Nichts desto trotz möchte ich an ZFS festhalten, wegen der Vorteile.
Ich möchte mir 2 neue SSD,s kaufen.

Wären das die richtigen damit das Caching und die Lebensdauer für ZFS passen ???
1 x

Kingston DC1000B
480 GB​

1 x

SEDC600M/480G Kingston DC600M SSD 480 GB​

 
Die DC-Serie von denen hat PLP eingebaut. Laufwerke mit PLP haben automatisch einen größeren Cache, um eben die Daten in ausreichender Menge puffern und zurückschreiben zu können, falls der Strom wegfällt. Gibt noch bessere Laufwerke, aber für das Homelab m.E. ausreichend. Die S-ATA SSDs DC600m habe ich bspw. in der 3,84TB Variante im striped mirror (8 Stück) im Einsatz und bisher keinerlei Probleme gehabt unter ZFS. Wearing ist nach 6 Monaten immer noch bei 0%.
 
You must log in or register to reply here.

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!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

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!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back