Hallo zusammen,
kurzes Vorwort:
vor ein paar Jahren habe ich einen alten Server geschenkt bekommen und mir einen Server mit Proxmox installiert. Damit habe ich auch die ersten Versuche gemacht und manch ein Container hat deshalb eine etwas ungeschickte Konfiguration.
Ich habe einen HP ProLiant DL360 G7 Server. Darin befinden sich 7 Western Digital Red Plus 1TB in 2.5 Zoll Format. Diese 7 Platten sind vorne in den Hotswap Bays eingesteckt. Zusätzlich hatte ich bis vor kurzem eine 4TB HDD, die ich intern per SATA direkt an das Mainboard angeschlossen habe.
Ich hab hier halt Reste verwertet und wusste noch gar nicht so recht, wo die Reise denn mit diesem Server hingehen soll.
Proxmox läuft mittlerweile in der Version 7.4-16.
Die 7 WD-Platten sind als ZFS raidz1-0 Pool zusammen gestellt. Die 4TB HDD war separat mit ZFS formatiert und eingehängt.
So, mein Nextcloud-Container ist jedoch über die Jahre nun über 150GB groß geworden. Ich glaube, dass das letzte Backup über 12h auf die HDD gedauert hat.
Daher hab ich die HDD gegen eine SSD (Crucial BX500 2TB 3D NAND SATA 2,5 Zoll Interne SSD) ausgetauscht.
Wie bin ich vorgegangen?
Alte HDD ausgebaut und neue SSD angeschlossen. Server hochgefahren.
Dann in der UI hab ich hab meinen Node ausgewählt -> Disks -> /dev/sda (das ist die SSD) angeklickt und "initialise Disk with GPT" geklickt.
Anschließend auf "Directory" -> Create Directory. Die SSD ausgewählt, XFS als Filesystem gewählt und den Namen Backup vergeben.
Problem:
Wenn ich nun einen Container herunterfahre, in den Tab Backup gehe und dann auf "Backup now" klicke, dann dauert ziemlich lange.
Beispiel:
Der Container 105 ist ein Samba-FS. Zugewiesene Disk-Size sind 500G. Das Backup dauerte 18 Minuten und war anschließend 25G (tar.zst) groß.
Der Container 104 ist ein Debian auf dem ich testweise mal die Software ntopng installiert hatte. Root Disk ist 8G groß. Das Backup dauerte fast 8 Minuten und die (nur .tar) auf der Backup-SSD ist 1.5G groß.
Ein anderer Container, in dem ecodms installiert ist, hat eine Root Disk von 16G. Das Backup auf die SSD habe ich beim ersten mal nach 11 Minuten abgebrochen. Beim zweiten mal war es nach 5 Minuten fertig und die tar.zst ist nun 9G groß.
Analysen:
Ich hab dann mal eine Ubunu-ISO (4,7G) auf den ZFS-Pool heruntergeladen und nach einem kompletten Reboot (wegen eventuellem Caching) anschließend auf die Backup-SSD kopiert
-> cp ubuntu-22.04.3-desktop-amd64.iso /mnt/pve/backup/
Dieser Kopiervorgang von 4.7G dauerte nur 38 Sekunden.
Daher habe anschließend mal nmon und watch ls -lah geöffnet und bei einem dump eines Containers beobachtet:
Hier ein Screen Capture:
https://vimeo.com/871189042?share=copy
Was mir auffällt:
1) im linken Putty-Fenster ist der Dump der zweitletzte Eintrag. Die ersten 80M dürften deshalb so schnell gekommen sein, weil ich vor dem Capture kurz auf Backup klicke und dies aber abgebrochen hatte, weil die Aufnahme nicht lief
Danach sieht man aber, wie die MBs nur so spärlich hochgehen.
2) Die SSD ist quasi null ausgelastet, wenn der dump des Containers läuft.
3) Die anderen Platten vom ZFS-Pool sind aber auch nicht sonderlich aktiv.
4) Hab jetzt keinen Screen-Capture davon, aber wenn ich über die Console wieder das Ubuntu kopiere, dann sehe ich sehr schön, wie die Auslastung von /dev/sda (der SSD hoch geht und oben bleibt, bis der Kopiervorgang abgeschlossen ist.
5) Als noch die alte Backup-HDD drin war und ein dump lief, war die Auslastung von /dev/sda in nmon durchgehend bei 100%.
6) bei htop wird die load auf 1.20 beim dump angegeben. Die 16 Kerne bzw. Threads sind auch nur minimalst belastet.
Frage:
Was mach ich falsch bzw. wo ist mein Fehler? Ich erwarte ja keine High-Performance für meinen Home-Server, aber ein bissl schneller könnts doch laufen. Was ist mein Bootle-Neck?
Vielen Dank schonmal!
kurzes Vorwort:
vor ein paar Jahren habe ich einen alten Server geschenkt bekommen und mir einen Server mit Proxmox installiert. Damit habe ich auch die ersten Versuche gemacht und manch ein Container hat deshalb eine etwas ungeschickte Konfiguration.
Ich habe einen HP ProLiant DL360 G7 Server. Darin befinden sich 7 Western Digital Red Plus 1TB in 2.5 Zoll Format. Diese 7 Platten sind vorne in den Hotswap Bays eingesteckt. Zusätzlich hatte ich bis vor kurzem eine 4TB HDD, die ich intern per SATA direkt an das Mainboard angeschlossen habe.
Ich hab hier halt Reste verwertet und wusste noch gar nicht so recht, wo die Reise denn mit diesem Server hingehen soll.
Proxmox läuft mittlerweile in der Version 7.4-16.
Die 7 WD-Platten sind als ZFS raidz1-0 Pool zusammen gestellt. Die 4TB HDD war separat mit ZFS formatiert und eingehängt.
So, mein Nextcloud-Container ist jedoch über die Jahre nun über 150GB groß geworden. Ich glaube, dass das letzte Backup über 12h auf die HDD gedauert hat.
Daher hab ich die HDD gegen eine SSD (Crucial BX500 2TB 3D NAND SATA 2,5 Zoll Interne SSD) ausgetauscht.
Wie bin ich vorgegangen?
Alte HDD ausgebaut und neue SSD angeschlossen. Server hochgefahren.
Dann in der UI hab ich hab meinen Node ausgewählt -> Disks -> /dev/sda (das ist die SSD) angeklickt und "initialise Disk with GPT" geklickt.
Anschließend auf "Directory" -> Create Directory. Die SSD ausgewählt, XFS als Filesystem gewählt und den Namen Backup vergeben.
Problem:
Wenn ich nun einen Container herunterfahre, in den Tab Backup gehe und dann auf "Backup now" klicke, dann dauert ziemlich lange.
Beispiel:
Der Container 105 ist ein Samba-FS. Zugewiesene Disk-Size sind 500G. Das Backup dauerte 18 Minuten und war anschließend 25G (tar.zst) groß.
Der Container 104 ist ein Debian auf dem ich testweise mal die Software ntopng installiert hatte. Root Disk ist 8G groß. Das Backup dauerte fast 8 Minuten und die (nur .tar) auf der Backup-SSD ist 1.5G groß.
Ein anderer Container, in dem ecodms installiert ist, hat eine Root Disk von 16G. Das Backup auf die SSD habe ich beim ersten mal nach 11 Minuten abgebrochen. Beim zweiten mal war es nach 5 Minuten fertig und die tar.zst ist nun 9G groß.
Analysen:
Ich hab dann mal eine Ubunu-ISO (4,7G) auf den ZFS-Pool heruntergeladen und nach einem kompletten Reboot (wegen eventuellem Caching) anschließend auf die Backup-SSD kopiert
-> cp ubuntu-22.04.3-desktop-amd64.iso /mnt/pve/backup/
Dieser Kopiervorgang von 4.7G dauerte nur 38 Sekunden.
Daher habe anschließend mal nmon und watch ls -lah geöffnet und bei einem dump eines Containers beobachtet:
Hier ein Screen Capture:
https://vimeo.com/871189042?share=copy
Was mir auffällt:
1) im linken Putty-Fenster ist der Dump der zweitletzte Eintrag. Die ersten 80M dürften deshalb so schnell gekommen sein, weil ich vor dem Capture kurz auf Backup klicke und dies aber abgebrochen hatte, weil die Aufnahme nicht lief
Danach sieht man aber, wie die MBs nur so spärlich hochgehen.2) Die SSD ist quasi null ausgelastet, wenn der dump des Containers läuft.
3) Die anderen Platten vom ZFS-Pool sind aber auch nicht sonderlich aktiv.
4) Hab jetzt keinen Screen-Capture davon, aber wenn ich über die Console wieder das Ubuntu kopiere, dann sehe ich sehr schön, wie die Auslastung von /dev/sda (der SSD hoch geht und oben bleibt, bis der Kopiervorgang abgeschlossen ist.
5) Als noch die alte Backup-HDD drin war und ein dump lief, war die Auslastung von /dev/sda in nmon durchgehend bei 100%.
6) bei htop wird die load auf 1.20 beim dump angegeben. Die 16 Kerne bzw. Threads sind auch nur minimalst belastet.
Frage:
Was mach ich falsch bzw. wo ist mein Fehler? Ich erwarte ja keine High-Performance für meinen Home-Server, aber ein bissl schneller könnts doch laufen. Was ist mein Bootle-Neck?
Vielen Dank schonmal!
