Hallo zusammen!

 

Ich habe das Problem, dass bei einem Datentransfer, z.B. ein großes Video über WebDAV, oder Bilder-Transfer bei Immich, etc., die restlichen Container lahmgelegt werden. Selbst das Unraid WebPortal geht dann fast nicht mehr auf, weil Unraid mit dem Datentransfer "beschäftigt" ist.

 

Gibt es denn eine Möglichkeit, den Datentransfer pro Container zu drosseln? So dass z.B. der WebDAV-Container nur 4MB/s "bekommt"?

 

Wie macht Ihr das denn - z.B. große Dateien kopieren, ohne dass die anderen Container beeinträchtigt werden?

7 hours ago, cablesky said:

Wie macht Ihr das denn - z.B. große Dateien kopieren, ohne dass die anderen Container beeinträchtigt werden?

sollte so nicht sein, deutet auf massives i/o Thema hin welches ich nur bei USB Datenträgern kenne ...

 

versuch mal ne diagnostics zu erstellen während das auftritt (sofern es jetzt kein USB Thema sein sollte)

Also grundsätzlich beobachtest Du normales Verhalten, das es so überall bei TCP/IP gibt.

 

Wenn eine Datenverbindung aufgebaut ist, erhält die erste davon 100% der Speicherressourcen und der Bandbreite.

Wenn sie dann schneller "lesen" kann, als die Daten im LAN loszuwerden, dann füllen sich die internen Puffer, irgendwann kommt es dann zum "Stall" (aka: "nichts geht mehr").

Das kannt man hinlänglich hier von Windows Transfers die flott anfangen und irgendwann mal auf 0kb/s zusammenbrechen. Nach ein paar Sekunden gehts dann weiter und das Ganze wiederholt sich in Wellen.

Also: ersmal kriegt einer ALLES.

 

Wenn nun eine zweite Verbindung hinzukommt, geht erstmal ein großer Schock durch den Rechner. Blitzartig wird der laufende Transfer (#1) gestoppt, der zweite gestartet und die Bandbreite jeweils auf die beiden Verbindungen zu 50% verteilt (sollte  eine Verbindung die Bandbreite gar nicht brauchen, so wird sie langsam wieder der anderen zugeschlagen, das dauert aber eine Weile).

 

Ist aber, wie oben erwähnt, #1 gerade eh im Stall_Modus, kann #2 gar nicht gestartet werden, es muss ersmal wieder Puffer freigeräumt werden, danach kommt dann der Split und beide fahren irgendwann gemächlich wieder an.

 

Ziel muss es sein, dass das LAN kein Flaschenhals ist. Also, die LAN Geschwindigkeit immer deutlich über der Festplattengeschwindigkeit liegt.

Bei heutigen Rechnern verwenden aber viele Leute schon schnelle NVMe Platten, benutzen aber immer noch lahmes 1G oder 2,5G LAN (oder gar schauriges WLAN).

Bei PCIe 4.0 Platten muss man schon ein 10G LAN haben, PCIe 5.0 braucht dann schon 25 bzw 40G...

 

ich kann das jetzt so nicht bestätigen das ein Transfer das ganze Sys lahm legt.

 

Natürlich das Verhalten wenn der Sender schneller als der Empfänger ist mit den Wellenbewegungen wenn die Puffer voll laufen, klar,

aber dabei bleibt hier zumindest Unraid nicht stehen ,,,

 

wie oben erwähnt, USB, klar, da i/o da ins Schwanken kommt ... und was mir noch eingefallen ist, diverse plugins wie file activity können so etwas auch hervorrufen da dann inotify im Hintergrund so richtig Gas geben kann

3 hours ago, alturismo said:

ich kann das jetzt so nicht bestätigen das ein Transfer das ganze Sys lahm legt.

Das passiert auch nur in extremen Situationen mit gravierender Schieflast der Geschwindigkeit der Komponenten. Meist bremst die Platte das LAN aus, aber in letzter Zeit sind die Dinger deutlich schneller geworden, so dass nun der umgekehrte Fall häufig eintrifft. Und dieser "Stall" dauert ja auch meist nur ein paar Sekunden (bis zu 30 hab ich schon gesehen), was darüber hinausgeht ist sicherlich ein "richtiger" Fehler mit anderer Ursache.

 

Danke für eure Tips! Es ist wirklich so, dass ich als Parity Platte eine USB-SSD verwende, wogegen die Datenplatten aus 2 NVME Platten bestehen.  

 

Heißt das, dass wenn die Parity Platte auch eine NVME wäre, ich diese Problem nicht mehr hätte?

9 minutes ago, cablesky said:

Danke für eure Tips! Es ist wirklich so, dass ich als Parity Platte eine USB-SSD verwende, wogegen die Datenplatten aus 2 NVME Platten bestehen.  

 

Heißt das, dass wenn die Parity Platte auch eine NVME wäre, ich diese Problem nicht mehr hätte?

 

Parity sollte immer die schnellste Disk im Array sein.

USB ist im Array (und Parity ist ja im Array) nicht empfohlen. [Es ist möglich, aber ggf. riskant]

SSD sind im Array nicht empfohlen (auch, weil kein Trim unterstützt wird) [aber es ist möglich]

USB ist vom Protokoll her etwas instabiler und etwas langsamer (man bekommt nur eine sehr begrenzte Menge der eigentlich möglichen IOPS durch USB gereicht, wobei eine native Anbindung NVME an PCIe weitaus mehr schaffen kann. Gerade die Parity steht etwas stärker unter Schreiblast, als die Daten enthaltenden Datenträger im Array. Gerade die Parity über USB anzubinden, wenn die anderen Datenträger NVME direkt an PCIe Sind, sehe ich persönlich als eine ungünstige Konstellation an.). 

 

Grundlegend funktioniert es, aber Du erlebst in Deiner Erfahrungen einen der Nachteile, wenn man entgegen der üblichen Konstruktionen das System doch sehr 'bemerkenswert anders' aufbaut.

Ich würde als Parity den schnellsten Datenträger im Array verwenden und den nativ anbinden. USB wäre zwar nicht meins, aber wenn, dann schon eher einen Daten tragenden Datenträger per USB.

 

Achja, soweit ich las (oder eben nicht las), scheinst Du keinen Pool als Schreibcahe zu nutzen: Das wirkt sich natürlich auch aus, wenn Du das System voll schreibst.

Wenn ich direkt große Datenmengen (aka große Dateien) ins Array schreibe (und dabei auch den Ram Cache auslaste) brechen meine System auch ein. Dafür hat man ja einen flotten SSD Pool, den man dann als Cache vorschaltet.

41 minutes ago, DataCollector said:

Achja, soweit ich las (oder eben nicht las), scheinst Du keinen Pool als Schreibcahe zu nutzen: Das wirkt sich natürlich auch aus, wenn Du das System voll schreibst.

Wenn ich direkt große Datenmengen (aka große Dateien) ins Array schreibe (und dabei auch den Ram Cache auslaste) brechen meine System auch ein. Dafür hat man ja einen flotten SSD Pool, den man dann als Cache vorschaltet.

Den Abschnitt ignorieren wir lieber mal. Seine Datenplatten sind schneller als jeder SSD Pool sein kann, das ist also hier kontraproduktiv.

Mit 2*NVMe mach die Parity SSD auch wenig Sinn, sie bremst nur.

Und da kein TRIM im UNRAID Array funktioniert sind sowohl die SSD, als auch die NVMes deplaziert.

Der ganze Aufbau ist also mehr als suboptimal.

 

Wäre die SSD weg und eine dritte (gleichartige) NVMe vorhanden, dann wäre ein RAIDZ (ZFS Array) Pool hier wohl die optimale Lösung. Da ist die Parität und der Cache dann gleich mit eingebaut. Aber, es müssen eben DREI GLEICHE Laufwerke sein...

1 hour ago, cablesky said:

Heißt das, dass wenn die Parity Platte auch eine NVME wäre, ich diese Problem nicht mehr hätte?

egal was du machst, wenn die USB Schnittstelle der Flaschenhals ist und i/o hängt ... wird meiner persönlichen Erfahrung nach immer ein Problem auftauchen bei massiven Datentransfers ... also entweder abwarten bis i/o abgearbeitet ist oder den Aufbau überdenken ...

 

Fairerweise, Parity im rwm mode ist der "unglücklichste" Aufbau ... stell mal auf "reconstruct" um in den allgemeinen disk settings, vielleicht hilft das das hier ein Arbeitsschritt entfällt und die USB Kiste entlastet, bei SSD only Aufbau eh irrelevant.

7 minutes ago, MAM59 said:

Den Abschnitt ignorieren wir lieber mal. Seine Datenplatten sind schneller als jeder SSD Pool sein kann, das ist also hier kontraproduktiv.

 

... nicht, wenn eine USB Anbindung hier blockiert, weil alle Datren schreibend 2mal durch den USB Flaschenhals müssen (lesen und schreibend wegen der Parity dort).

Wir wissen nicht einmal wie schnell seine USB Anbindung ist.

Ich hatte schon mitbekommen, daß er SSDs im Array hat, aber ohne zu wissen, wie der Rest aussieht gehe ich davon aus, das seine Scheribvorgänge per USB so viel Last/Blockierung erzeugen, daß das System eben ganau das macht, was er ja erlebt. Und ein abfangender Pool/Cache, der die Schreiblast zu Stoßzeiten aufnimmt, sogrt dafür, daß die Schreiboperationen im Array in lastarmen Offzeiten abgewickelt werden kann (wenn man den Mover entsprechend geschickt einstellt).

 

7 minutes ago, MAM59 said:

Mit 2*NVMe mach die Parity SSD auch wenig Sinn, sie bremst nur.

 

 

Erwähnte ich schon, daß ich das Problem in der Parity an USB sehe und ein puffernder Pool/Cache das abfangen könnte?

 

7 minutes ago, MAM59 said:

Und da kein TRIM im UNRAID Array funktioniert sind sowohl die SSD, als auch die NVMes deplaziert.

 

Hm,. ich glaube auch in der Richtung erwähnte ich es hier schon  😉

 

7 minutes ago, MAM59 said:

Der ganze Aufbau ist also mehr als suboptimal.

 

Das wollte ich damit andeuten. Wenn dann noch USB 2.0 (480MBit/s) oder 3.0 (5GBit/s) ins Spiel kommen wird es echt mies.

 

7 minutes ago, MAM59 said:

Wäre die SSD weg und eine dritte (gleichartige) NVMe vorhanden, dann wäre ein RAIDZ (ZFS Array) Pool hier wohl die optimale Lösung.

 

...wenn man es nicht per USB anbinden würde...

 

7 minutes ago, MAM59 said:

Da ist die Parität und der Cache dann gleich mit eingebaut. Aber, es müssen eben DREI GLEICHE Laufwerke sein...

 

Sie müssen nicht gleich, sein, aber Größenunterschiede machen sich ggf. bemerkbar.

2 minutes ago, DataCollector said:

...wenn man es nicht per USB anbinden würde...

Unwahrscheinlich, wer kastriert schon eine NVMe???

Die beiden werden wohl auf dem Mutterbrett sein und er hat nur die Parity per USB extern angeschlossen.

Quasi als typischen Denkfehler.

1 hour ago, MAM59 said:

Unwahrscheinlich, wer kastriert schon eine NVMe???

 

jemand, der sein Array mit einer USB Parity betreibt.

 

1 hour ago, MAM59 said:

Die beiden werden wohl auf dem Mutterbrett sein und er hat nur die Parity per USB extern angeschlossen.

 

Ja, er hat 2 NVME SSD im Array und er hat wohl eine SSD per USB als Parity und gen au da bremst das USB ja. Sein Problem liegt ja da, daß er makl eben große Dateien ins unraid schreiben will und dann das System eben stockt. Ich ich gehe eben davon aus, daß die SSD per USB das Problem ist, weil bei der Parity ja alles mindestens 2mal durch den selben Flaschenhals muß.

Ob die SSD an USB nun NVMe oder SATA ist, ist dabei unbekannt.

 

1 hour ago, MAM59 said:

Quasi als typischen Denkfehler.

 

Eher der Fehler im Aufbau.

Hi nochmal! Ich danke euch für den Denkanstoß (und die weiteren Tips und Erklärungen)! Werde jetzt die Parity-USB-Platte rausschmeißen und nur mit zwei NVME's Unraid betreiben. Hatte bis jetzt nur 1x 500GB und 1x 250GB Platten hier. Werde mir jetzt 2x 500GB besorgen. 

 

 

31 minutes ago, cablesky said:

Werde jetzt die Parity-USB-Platte rausschmeißen und nur mit zwei NVME's Unraid betreiben. Hatte bis jetzt nur 1x 500GB und 1x 250GB Platten hier. Werde mir jetzt 2x 500GB besorgen.

 

Ich würde gleich 1 oder 2TB nehmen und das dann (wenn Ausfallsicherheit ein Thema ist) als Pool mit Raid1/Mirror zfs (also 2 x 1-2TB) nutzen.

Ich hatte es zumindest so verstanden, daß es (auch) um "große Dateien" geht, da sollte man dann auch Platz für frei haben.

Edited May 5, 20251 yr by DataCollector
Typos

ja, besser zu 2*2 Tb greifen, wird Dich nicht viel ärmer machen heutzutage

 

Darfst ja auch nicht vergessen, dass in dem Cache idR. ja auch die Docker und VMs liegen. 

500GB sind da schon recht knapp. 

58 minutes ago, Sacred said:

Darfst ja auch nicht vergessen, dass in dem Cache idR. ja auch die Docker und VMs liegen. 

500GB sind da schon recht knapp. 

 

Leider wissen wir nicht viel über sein System.

Bei 2x NVMe im Array vermute ich, daß er gar keinen Pool/Cache verwendet und genau dadurch seine stockendne Anwendungen kommen.

Wenn alle sim Array läuft und das Array von "USB (unbekannter Geschwindigkeit) Parity" gebremst wird, ist es abzusehen, daß Schreiben großer Dateien im Array auch die Docker blokciert (die ja auch dort liegen).

 

Deshalb hatte ich ja auch vorgeschlagen das einfach durch zufügen eiens SSD Caches/Pools zu entspannen.

Also zu meinem System: Es ist ein Fujitsu Futro S740 (J4105 Intel Prozessor). Brauche eigentlich nicht mehr Speicherim Moment. Hab mir bei Ebay-Kleinanzeigen jetzt ein 500GB NVME gekauft, die ich statt der 250GB NVME rein setze. 

Braucht man dann wirklich noch einen Cache, wenn das Array nur aus NVME's besteht? Ich dachte, die Cache wird nur benötigt, wenn das Array HDD's sind.. 

Ich krieg' nicht mehr NVME's oder andere Platten in das Gehäuse rein - und ich habe nur 1x Wifi und 1x NVME zur Verfügung. Am Wifie Port hängt eine NVME mit Adapter dran. Deswegen ist die Geschwindigkeit eh' etwas gebremst... 

Edited May 5, 20251 yr by cablesky

36 minutes ago, cablesky said:

Braucht man dann wirklich noch einen Cache, wenn das Array nur aus NVME's besteht?

Nein, dadurch würde es nicht schneller, aber vielleicht langsamer.

Du hast also ne NVME mit nur einer Lane? Da bist Du dann im Speedbereich eines Raspberry Pi 5 🙂

 

Ja leider. Das ist halt so. Hauptsache, ich kann dann bei größeren Datentransfers auf's Webportal noch zugreifen 🙂 

1 hour ago, cablesky said:

Braucht man dann wirklich noch einen Cache, wenn das Array nur aus NVME's besteht?

 

Solange man keine Bremse (wie Deine ursprüngliche USB Parity) einbaut: nein.

Wenn man das Array aber durch irgendwelche (nicht empfohlenen) exotischen Konfigurationen bremst macht es eben sin, das dann ja leider doch wieder verlangsamte Array mit einem Cache beim direkten Schreiben zu 'umgehen'.

 

Vielleicht solltest Du überlegen sowieso das Array zu umgehen und die NVMe SDs direkt als Pool einzzusetzen (seit unraid 7.x kann man ohne Array konfigurieren).

Dann hast Du wenigstens auch noch Trim.

 

1 hour ago, cablesky said:

Ich dachte, die Cache wird nur benötigt, wenn das Array HDD's sind.. 

 

Der Cache word benötigt (oder sagen wir besser: "ist sehr sinnvoll"), wenn das Array bei benutzun ausgelastet ist (weil es ggf. durch eine Flaschenhals augebremst wird).

Da der Futro nicht unbedingt sehr viel RAM hat, werden Schreiboperationen von "großen dateien" auch nicht nennenswert durch den Ranmcache abgefangen. Somit schlägt ein langsames Array eben schnell zu.

NVme SSD sind in der Regel sehr schnell. Die allein sind hier ja auch nicht das Problem. Das Problem entsteht mutmaßlich eben durch die USB Parity. Und ja, der Futro hat ja allerhöchstens USB 5GBit/s (3.0/3.1 gen1/3.2 gen1).

 

1 hour ago, MAM59 said:

Du hast also ne NVME mit nur einer Lane? Da bist Du dann im Speedbereich eines Raspberry Pi 5 🙂

 

Ja, da die CPU sowieso nur "PCI-Express-Version 2.0" beherrscht, ist das also NVMe mit 500MBit/s pro Lane. SATA ist schneller.

Es kristallisiert sich immer mehr (mit jedem Stückchen nachgereichter Info) heraus, warum die Kiste in die Knie geht.

 

Edited May 5, 20251 yr by DataCollector

 

57 minutes ago, cablesky said:

Ja leider. Das ist halt so. Hauptsache, ich kann dann bei größeren Datentransfers auf's Webportal noch zugreifen 🙂 

 

Wenn ein großer Datentransfer nicht durch USB parity gebremst wird und Du die NVme SSD(s) vielleicht als Pool und nicht im Array nutzt hast Du wohl die besten Chancen, daß das System auf dem Web noch erreichbar sein könnte.

Aber Wundser würde ich dennoch nicht erhoffen, wenn Du bei Schreiboperationenn ggf. auch den Ram auslastest. Vielleicht den Ramcache verringern, damit mehr Ram für WebGUI und normaklen Betrieb übrig bleibt (sobald Du Daten ins System rein schreibst).