Hardware oder Software Problem ?

[frogger13]

Moin...

 

Ich bastel seit ca. einer Woche an einem Unraid Server, der primär erstmal als NAS dienen soll. Mit vielen Tipps von hier und aus anderen Posts habe ich die Config eigentlich erstmal fertig.

 

Nun habe ich angefangen die Daten zurück zu sichern.  Leider haben sich immer wieder Probleme aufgetan. Der Kopiervorgang ist grundsätzlich zu langsam finde ich...ich komme im besten Fall auf ca. 50 MB/s im Durchschnitt bei einer GB Leitung. Das Schlimme dabei ist aber, dass der Kopiervorgang nach ein paar Stunden komplett langsam wird und dann im KB Bereich landet. Wenn ich das dann abbreche und neu starte ist es erstmal wieder wie am Anfang.

 

Ich habe auch verschieden Quellen in meinem Netz versucht: Von dem Backup NAS (Intel basierend),  von einer QNAP und von meinem PC an dem ich gerade sitze. Überall der gleiche Verlauf. Und auch die Art und Weise, wie ich kopiere ist egal. LuckyBackup (also rsync) und manuell über Kommando Zeile. Alles Egal.... Die Quell Ressource ist immer per NFS angebunden.

 

Die Hardware ist ein Asus Prime B450M mit einem Athlon 3000G - 16 GB Ram und 5 x 16TB Seagate Exos HDDs. Ich kopiere direkt auf das Array OHNE Cache dazwischen.

 

Jemand einen tollen Tipp ? Ich bin kurz davor mir neue Hardware zu kaufen.... oder doch ein anderes OS ?

 

Gruß

Reiner

 

[hawihoney]

21 minutes ago, frogger13 said:

ich komme im besten Fall auf ca. 50 MB/s im Durchschnitt

 

Beim Schreiben auf das Array? Normal - entspricht ca. 150-200 MB/s. Hier die englischsprachige Begründung aus dem Unraid Manual:

 

Quote

To summarize, for the "read/modify/write" method, you need to:

read in the parity block and read in the existing data block (can be done simultaneously)

compare the data blocks, then use the difference to change the parity block to produce a new parity block (very short)

wait for platter rotation (very long!)

write out the parity block and write out the data block (can be done simultaneously)

That's 2 reads, a calc, a long wait, and 2 writes.

The advantages of this approach are:

Only the parity drive(s) and the drive being updated need to be spun up.

Minimises power usage as array drives can be kept spun down when not being accessed

Does not require all the other array drives to be working perfectly

 

Der Einbruch der Performance ist nicht normal. Sind das SSDs?

 

Edited April 21, 2022 by hawihoney

[DataCollector]

1 hour ago, hawihoney said:

Beim Schreiben auf das Array? Normal - entspricht ca. 150-200 MB/s. Hier die englischsprachige Begründung aus dem Unraid Manual:

Wegen diesem Zeitverzug bei dem Übertragen großer Datenmengen bei Erstbefüllung hatte ich vorgeschlagen das Array erst einmal ohne Parität zu betreiben.

 

1 hour ago, hawihoney said:

Der Einbruch der Performance ist nicht normal. Sind das SSDs?

Ich schätze er meint, daß er direkt auf die "5 x 16TB Seagate Exos HDDs" schreibt und dann schreibt er somit direkt auf CMS Festplatten ohne SSD Cache dazwischen. Ja, ich stimme zu, daß der Einbruch nicht ins Bild passt. und auf ein weiteres Problem hinweisst.

[hawihoney]

45 minutes ago, DataCollector said:

Wegen diesem Zeitverzug bei dem Übertragen großer Datenmengen bei Erstbefüllung hatte ich vorgeschlagen das Array erst einmal ohne Parität zu betreiben.

 

Wo? Nicht in diesem Thread.

 

Wie auch immer. Ich hielt es für wichtig zu erläutern warum das bei einem Array mit Parität Disks so ist wie es eben ist. 

 

Nahezu jeder Unraid Starter stolpert über die Performance. Das es aber durchaus Sinn ergibt genau diese Art der Ausfallsicherheit zu verwenden, statt eines traditionellen RAIDs, wird meines Erachtens zu wenig verbreitet.

 

Das müssen wir aber nicht weiter diskutieren. Jetzt geht es nur noch um die Performance Einbrüche beim OP. Da bin ich wegen 0,0 NFS Erfahrung raus. Habe ich noch nie vermisst.

 

[mgutt]

Da du eh keinen Cache hast, könntest du es mal bei NFS mir /mnt/disk1/sharename statt /mnt/user/sharename als Ziel probieren. Das entlastet die CPU.

 

PS sehe kleine Dateien resultieren immer eine langsame Geschwindigkeit.

[DataCollector]

2 hours ago, hawihoney said:

Wo? Nicht in diesem Thread.

Der hier ursprünglich fragende frogger13 hatte folgenden Beitrag verfasst
"neuer Unraid Server - Umsteiger von OMV"
in dessem Verlauf ich davon schrieb:

 

2 hours ago, hawihoney said:

Wie auch immer. Ich hielt es für wichtig zu erläutern warum das bei einem Array mit Parität Disks so ist wie es eben ist. 

Da sage ich ja auch nichts gegen. Mir erscheinen die ca. 50MByte/s auf ein solches Array mit Parity zwar mindestens 10MByte/ zu langsam zu sein, aber Du hast doch vollkommen recht, dass die Parität auf einer heutigen Festplatte eben starkt bremst.

Deshalb hatte ich anfangs auch mit Parität auf SSD experimentiert, bin aber an Kostengrenze bei 18 oder mehr TB Datenkapazität pro Datenfestplatte im Array davon abgegangen.

Auch deshalb will ich ja im Wirkbetrieb später meinen Cache auf 8 oder mehr TB NVMe SSD ausbauen um bei der Nutzung schreibend nicht zu sehr ausgebremst zu werden.

 

2 hours ago, hawihoney said:

Jetzt geht es nur noch um die Performance Einbrüche beim OP. Da bin ich wegen 0,0 NFS Erfahrung raus. Habe ich noch nie vermisst.

Ich überlege zwar später wegen meinen VU+ Receivern auch NFS zu nutzen, aber wegen meinen Windowssystemen wird das meiste dennoch über SMB/CIFS laufen.

Zu NFS habe ich auch noch zu wenig Erfahrung.

[frogger13]

Moinsen...

 

Hat etwas gedauert, da ich ja immer etwas warten muss, bis mein Problem wieder auftritt, nachdem man etwas geändert hat.

 

Ich habe aber scheinbar die Lösung: Ich habe das Ganze auf eine SMB Freigabe umgestellt und siehe da. Heute den Tag über lief ein Backup Job über 13 Stunden ohne Problem. Meine bisherigen Versuche mit NFS Freigaben waren da schon lange abgebrochen.

 

Ich bevorzuge eigentlich NFS, weil das etwas wenige Overhead hat und eigentlich schneller sein sollte. Außerdem habe ich auch 2 Receiver, die Linux basierend sind und mit NFS mehr anfangen können. Und die Geschwindigkeit der aktuellen Sicherung ist auch kleiner als bei den Tests mit NFS - wenn auch nur wenig, aber bei mehreren TB zum Kopieren ist das schon ein Vorteil. Im täglichen Leben nachher bei eine "normalen" Datensicherung ist das evtl. zu vernachlässigen. Mal schauen....

 

Gruß

Reiner

 

[alturismo]

1 hour ago, frogger13 said:

der aktuellen Sicherung ist auch kleiner als bei den Tests mit NFS - wenn auch nur wenig, aber bei mehreren TB zum Kopieren ist das schon ein Vorteil.

 

On 4/21/2022 at 8:00 PM, frogger13 said:

ich komme im besten Fall auf ca. 50 MB/s im Durchschnitt bei einer GB Leitung

 

ich glaube jetzt nicht das SMB der limitierende Faktor ist sondern eher parity im laufenden Betrieb, SMB schafft auch mehr als 50 MB/s

 

ich hatte mit SMB auch mit meiner 10G Karte fast Anschlag mit 1 GB/s ... hab meine nur ausgebaut da kein Bedarf und die die Kühlung der GPU nicht mehr optimal war, anderes Thema  und meine VU etc ... kommt ganz bequem mit ~ 110 MB/s von und zu den smb shares ... schon immer, auch vor smb multichannel und co ...

 

erstmal gut dass du einspielen kannst, wenn das erledigt ist und du dann cache aktiviert hast wird sich zeigen was Sache ist mit smb und co über den schnellen cache ohne parity Aktivität, dann kannst du da nochmal ansetzen wenn Bedarf.