Array Transfer/Performance Problem


PsYcRo

Recommended Posts

Hallu UnRaidler,

 

ich habe seit einer Woche mein erstes UnRaid-System im Einsatz auf welchem ich nun meine Daten übers Netzwerk (rsync/smb) kopiere. Dabei habe ich ein Geschwindkeitsproblem wenn ich die Daten übers Netzwerk move.

 

Dieses System habe ich im Einsatz:

 

https://geizhals.at/?cat=WL-2000168

 

Meine Config besteht daraus, das ich ein Array aus 7 x WD 6TB + 1 x WD 8 TB als Parity. Der Cache besteht aus 2 x 1 TB NWMe im RAID1.

 

Nun zu meinem Problem, wenn ich meine Daten über das Netzwerk entweder über Rsync oder SMB kopiere ändert sich die Übertragungsgeschwindigkeit von 112MB/s nach 10-15 min auf langsame 40-45MB/s. Habe auch probeweise den SSD-Sache bei dem Kopiervorgang (Cache = YES) zu aktiviert aber hier gerate ich mit dem Mover in Konflikt da dieser es nicht schnell genug schafft die Daten von der SSD auf das Array zu kopieren und hier bricht der Kopiervorgang ab. Auch die Option mit dem RAM-Cache habe ich probeweise auf 50% (vm.dirty_ratio), aber dies brachte auch keine Besserung.

 

Gibt es irgendwelche Optionen die ich nicht kenne damit ich ich hier meine Netzwerkperformance steigern kann?

 

PS: Anbei ein Screenshot vom meinem UnRaid-System wo gerade die Files vom SSD-Cache "langsam" gemoved werden.

Screenshot 2021-03-15 at 13.18.15.png

Edited by PsYcRo
Screenshot attached
Link to comment

Du musst "reconstruct write" aktivieren. Findet man unter Settings->Disk Settings->"Tunable (md_write_method)" Das muss auf "reconstruct write" gestellt werden:

 

https://wiki.unraid.net/Tips_and_Tweaks#:~:text=A new mode has been,the read then the write).

 

Dann laufen aber auch immer alle Platten. Macht also ggfs. Sinn das wieder auf Auto zu stellen wenn man fertig ist und kurzfristig keine weiteren größeren Kopier-Maßnahmen anstehen.

  • Thanks 2
Link to comment
10 minutes ago, PsYcRo said:

oder verwechsele ich da was?

Ja tust du. Es ist einfach nur eine andere Methode die Parität zu berechnen. Die meisten bevorzugen die Standardmethode wo die meisten HDDs schlafen. Das ist zwar langsamer, aber es reduziert maßgeblich den Stromverbrauch.

 

Dass es nur 40 MB/s sind, liegt übrigens an den HDDs, die du verbaut hast und an der Position der Daten. Da du gerade auf disk3 schreibst, die bereits zur Hälfte gefüllt ist, liegt die Schreibrate nur noch bei ca 130 MB/s, da eine HDD immer langsamer wird, umso voller sie wird:

https://www.hardwareluxx.de/index.php/artikel/hardware/storage/49350-sieben-6-tb-festplatten-verschiedener-hersteller-im-test.html?start=10

3_WD_Blue_6TB_HDTuneR_3A0343E7EE7C482B875D8CD9FA2B1D80.thumb.jpg.77e0c51fec65049b8aba51d491d3549a.jpg

 

Da die Parity bei "auto" = "read/modify/write" erst gelesen und dann geschrieben wird und HDDs das gleichzeitig gar nicht mögen, fällt die Schreibrate auf 40 MB/s. Vor allem auch, weil es nur eine 5400 U/min HDD ist.

 

Bei "reconstruct write" = "turbo write", generiert er die Parity in dem er von allen HDDs gleichzeitig liest. Dadurch gibt es nur einen Schreibprozess auf der Parity Disk und die Geschwindigkeit geht deutlich nach oben. Wobei es hier auf die langsamste HDD im Verbund ankommt. Hast du jetzt also nur 80 MB/s, weil du von doppelt sprachst, dann scheint eine Platte die anderen zu limitieren oder es gibt noch einen parallelen Prozess, der eine der Platten bremst.

 

Um das zu umgehen, bietet sich ein entsprechend großer SSD Cache an. Wer das Geld dafür hat, kann aber auch eine Micron ION 5210 als Parity nutzen. In deinem Fall also eine mit 7.68TB. Eine SSD kann deutlich besser mit parallelem Lesen/Schreiben umgehen. Etwas schneller wird es mit schnelleren HDDs. Ich komme mit WD Ultrastar auf 80 MB/s. In dem Video wird das auch ein wenige thematisiert:

 

Link to comment
2 hours ago, mgutt said:

Ja tust du. Es ist einfach nur eine andere Methode die Parität zu berechnen. Die meisten bevorzugen die Standardmethode wo die meisten HDDs schlafen. Das ist zwar langsamer, aber es reduziert maßgeblich den Stromverbrauch.

 

Dass es nur 40 MB/s sind, liegt übrigens an den HDDs, die du verbaut hast und an der Position der Daten. Da du gerade auf disk3 schreibst, die bereits zur Hälfte gefüllt ist, liegt die Schreibrate nur noch bei ca 130 MB/s, da eine HDD immer langsamer wird, umso voller sie wird:

https://www.hardwareluxx.de/index.php/artikel/hardware/storage/49350-sieben-6-tb-festplatten-verschiedener-hersteller-im-test.html?start=10

3_WD_Blue_6TB_HDTuneR_3A0343E7EE7C482B875D8CD9FA2B1D80.thumb.jpg.77e0c51fec65049b8aba51d491d3549a.jpg

 

Da die Parity bei "auto" = "read/modify/write" erst gelesen und dann geschrieben wird und HDDs das gleichzeitig gar nicht mögen, fällt die Schreibrate auf 40 MB/s. Vor allem auch, weil es nur eine 5400 U/min HDD ist.

 

Bei "reconstruct write" = "turbo write", generiert er die Parity in dem er von allen HDDs gleichzeitig liest. Dadurch gibt es nur einen Schreibprozess auf der Parity Disk und die Geschwindigkeit geht deutlich nach oben. Wobei es hier auf die langsamste HDD im Verbund ankommt. Hast du jetzt also nur 80 MB/s, weil du von doppelt sprachst, dann scheint eine Platte die anderen zu limitieren oder es gibt noch einen parallelen Prozess, der eine der Platten bremst.

 

Um das zu umgehen, bietet sich ein entsprechend großer SSD Cache an. Wer das Geld dafür hat, kann aber auch eine Micron ION 5210 als Parity nutzen. In deinem Fall also eine mit 7.68TB. Eine SSD kann deutlich besser mit parallelem Lesen/Schreiben umgehen. Etwas schneller wird es mit schnelleren HDDs. Ich komme mit WD Ultrastar auf 80 MB/s. In dem Video wird das auch ein wenige thematisiert:

 

Danke das Video habe ich gestern schon angeschaut und von dort diese vm.dirty Werte probiert. Wieso bemerke ich nichts davon bei meinem Kopiervorgang von mehreren TBs an Daten mit dem RAM-Cache?

Link to comment
19 minutes ago, PsYcRo said:

Wieso bemerke ich nichts davon bei meinem Kopiervorgang von mehreren TBs an Daten mit dem RAM-Cache

Wenn du nicht gerade mehrere TB RAM hast, dann ist wohl der RAM schon voll. Wie im Video erklärt, fungiert der RAM nur als Cache bis er voll ist.

Link to comment
  • 1 year later...
On 3/15/2021 at 5:34 PM, mgutt said:

Wenn du nicht gerade mehrere TB RAM hast, dann ist wohl der RAM schon voll. Wie im Video erklärt, fungiert der RAM nur als Cache bis er voll ist.

Ich klinke mich hier kurz ein (Bin Unraid Neuling der sich etwas eingelesen hat).

Setup:

2x Intel Xeon E5-2673 v3 @2,40Ghz (2x 12 Kerne +2x 12 virtuelle Kerne = 48 Threats)

128GB DDR4 ECC RAM (Samsung)

X99 Dual CPU China Motherboard (C610/X99 Chipsatz)

Gbit Ethernet

 

Parity Disk: Seagate 5TB ST5000DM000. SN: W4J01CF1 (über 6 Port SATA Controller AHCI mode)

 

Array Disks (lt. App Diskspeed):

Western Digital: 4TB WD4000FYYZ, SN: WCC130VYK8EA (über 6 Port SATA Controller AHCI mode)

Western Digital: 4TB WD4000FYYZ, SN: WCC132KUEUCN (über 6 Port SATA Controller AHCI mode)

WD Red: 4 TB WD40EFRX, SN: WCC7K4RVZ10N   (über sSATA Chipsatz AHCI mode)

 

Cache Disk :

SSD 970 EVO Plus 256GB (nvme), SN: S4EUNJ0N446661L (Baugleiche SDD vorhanden und wird beim Mainboard wechsel später im Verbund genutzt)

 

Steh noch am Anfang meiner Unraid einrichtung.

Habe meine Shares eingerichtet und wollte beginnen meine Daten vom PC und TrueNAS auf die Shares zu kopieren.

Der oben genannte Tipp "reconstruct write" schien mein Problem zu beheben - allerdings brach dann die Geschwindigkeit, zwar deutlich später als beim vorherigen Kopiervorgang, doch wieder ein (ca. 400GB an Daten, alles große ISO Dateien (ca. 10GB - 60GB je File). Cache habe ich für diese Shares deaktiviert (davor Mover ausgeführt) und dann den neuen 400GB Kopiervorgang gestartet. Zu Beginn lief es so wie es sollte, ein paar drops runter auf 10mb wo er doch vereinzelt kleine Dateien kopiert hat).

Im Angehängten screenshot ist zu sehen das dafür der RAM Cache verwendet wird. Kann das eventuell der Grund sein? 

Bei den Share Eisntellungen habe gesetzt Allocation Method auf "High Water" gestellt.

 

Habe nur gerade zufällig gesehen das Share "Unraid - Dokumente" versehentlich "prefer Cache" eingestellt hat - was doch egal sein sollte da ich auf das Share "Unraid - Games" schreibe und Allocation Method auf "Highwater" steht - oder irre ich mich da?

 

jedenfalls ist es komisch das der RAM Cache so voll läuft - oder ist das normal? Aktuell hab ich nur 3 kleine Docker laufen (fenrus, Diskspeed u. unraid-api).

 

 

Mein genereller Plan wäre eigentlich die Shares alle ohne Cache laufen zu lassen mit Ausnahme "Unraid - Medien". Es soll dann ein Docker Container mit Plex laufen, und die Dateien sollen nach Möglichkeit vom Cache gelesen werden. 

 

Hat jemand eine Idee weshalb die Kopiergeschwindigkeit so einbricht. Ich vermute es liegt irgendwie am vollen RAM Cache. Wenn dem so ist, wie könnte man das unterbinden bzw. was wäre best practise?

 

 

 

 

 


 

 

Kopiervorgang.png

2. Share Settings.png

3. Main Settings.png

Link to comment
58 minutes ago, jj1987 said:

Das scheint eine SMR Festplatte zu sein. Könnte uU daran liegen

Ok muss ich mir mal durchlesen was an SMR schlecht ist für unraid.

 

Aber was hat es mit dem Arbeitsspeicher auf sich das dieser bis zur gänze ausgelastet wird beim schreiben?

Link to comment
23 minutes ago, mgutt said:

Da musst du hoffen, dass die größer ist als die WD Re. Da reichen schon ein paar Byte. Aber das siehst du dann ob unRAID die akzeptiert.

ok, danke.

Werde es mal probieren.  Wenns nicht passt, wäre es dann die nächste Baustelle ^^

Link to comment
11 hours ago, mgutt said:

Da musst du hoffen, dass die größer ist als die WD Re. Da reichen schon ein paar Byte. Aber das siehst du dann ob unRAID die akzeptiert.

Update:

Die neue Parity Disk auch 4TB ist exakt gleich groß. Zumindest hat unraid nicht gemeckert. Somit haben alle verbauten Disks im Unraid-Server CMR.

 

Also hab ich einen neuen versuch gestartet und Daten von meinem PC auf ein Share von Unraid kopiert. 

Zu beginn wieder 113mb/s und dann gings runter auf 38-40mb. Wieder zu erkennen das es langsamer wird sobald der Arbeitsspeicher voll ist als (cache).

Oder liegt es daran das er noch nebenbei die Parität aufbaut? Erklärt das den Lese und Schhreibzugriff in den Statistics (siehe Screenshot)?

 

 

Am Screenshot ganz unten steht auch schon die ganze Zeit Starting Services. WAs ist denn damit gemeint? Die Docker Container, die laufen sollen tun das.

 

memory_cache.png

Link to comment
13 minutes ago, Laho said:

Zu beginn wieder 113mb/s und dann gings runter auf 38-40mb.

Dann ist das vermutlich das Maximum deiner HDD. Die Parität wird ja parallel gelesen und geschrieben. Man kann das zwar mit Reconstruct Write umgehen, aber dann laufen immer alle Platten und es reichen einzelne Zugriffe auf andere Platten des Arrays und schon bremst es wieder.

Link to comment
34 minutes ago, Laho said:

Oder liegt es daran das er noch nebenbei die Parität aufbaut?

 

Jeder Schreibzugriff führt im Parity Protected Array zu vier Zugriffen:

 

https://wiki.unraid.net/Parity#Performance

 

Quote

Each write to a parity-protected unRAID data disk results in 4 disk operations: a read and write for parity, and a read and write for data. The platter of each disk has to make a full revolution after reading to position the disk head back over the sector being written.

 

Simple ausgedrückt: Bei 40 MB/s besitzt die langsamste der am Schreiben beteiligten Disks eine Performance von 160 MB/s. So einfach ist es nicht ganz - reicht aber als Erklärung für den Anfang.

 

Edited by hawihoney
Link to comment
26 minutes ago, mgutt said:

Dann ist das vermutlich das Maximum deiner HDD. Die Parität wird ja parallel gelesen und geschrieben. Man kann das zwar mit Reconstruct Write umgehen, aber dann laufen immer alle Platten und es reichen einzelne Zugriffe auf andere Platten des Arrays und schon bremst es wieder.

"Reconstruct Write" ist bereits eingestellt- Oder verstehe ich da jetzt etwas falsch?

 

Link to comment
11 minutes ago, mgutt said:

Disk1 und Disk3 haben parallele Lese und Schreibzugriffe. Das bremst die Geschwindigkeit so extrem aus.

 

Kopierst du auf zwei Disks gleichzeitig? Dann ist das dein Problem. Und ja das geht nicht schneller (außer schnellere HDDs). Deswegen ja der Cache in unRAID.

 

 

Nein, ich habe nur auf ein Share (Unraid - Games) kopiert. Allocation Method ist auf "High Matter für das Share eingestellt. Nachdem noch genug Speicherplatz vorhanden ist, sollte er nur auf die eine Disk schreiben, wenn ich das jetzt richtig verstehe.

 

Der Kopiervorgang auf das Share ist nun fertig. Ein Blick auf die Arrays zeigt das auf die Parity Disk geschrieben wird und von den anderen Disks gelesen wird.

Auf den Screenshot sieht man links unten das der Parity-Sync läuft. Das wird dieser der Schuldige sein, oder? Kann man den Parity Sync pausieren (damit ich jetzt testen kann ob es wirklich der Sync ist der mir Probleme macht?)

 

speichernutzung.png

r-w_ohne_kopiervorgang.png

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.