JokerHD Posted January 13 Share Posted January 13 (edited) Hallo zusammen, ich bin noch relativ neu in der unRaid-Thematik und bin auf ein Problem gestoßen, dass ich mir nicht erklären kann. Wenn ich mein Array mit meinen Daten befülle, wird mit ca. 120 MB/s über das Netzwerk kopiert. Nach ca. 15-20 Minuten fällt der Transfer auf 5-20 KB/s und die CPU-Auslastung am unRaid geht auf über 80%. Pausiere ich das kopieren und warte ein paar Minuten, hab ich wieder die volle Leistung. Eine Cache-SSD-Platte hab ich erstmal noch deaktiviert, da ich mein Array noch am Befüllen bin, danach wird die SSD wieder aktiviert. Im Array-Betrieb sind 3x8TB Platten (1xParität und 2xDatenträger). Was hab ich übersehen? Woran könnte das alles liegen? Hier noch ein Screenshot von der CPU-Auslastung. Achja, ich kopiere von einem Windows 11 Rechner die Daten auf das Array. Danke schon mal für die Antworten. Daniel Edited January 13 by JokerHD Quote Link to comment
hawihoney Posted January 13 Share Posted January 13 1 hour ago, JokerHD said: Was hab ich übersehen? Guck Mal in top/htop ob das nicht IO-wait ist. Die Unraid Anzeige macht da keinen Unterschied. Der Linux Cache speichert zunächst ins RAM und wartet irgendwann auf die Platten. Quote Link to comment
DataCollector Posted January 13 Share Posted January 13 46 minutes ago, JokerHD said: ich bin noch relativ neu in der unRaid-Thematik und bin auf ein Problem gestoßen, dass ich mir nicht erklären kann. Erklärung: Die Anzeige zeigt falsch an. 46 minutes ago, JokerHD said: Wenn ich mein Array mit meinen Daten befülle, wird mit ca. 120 MB/s über das Netzwerk kopiert. Nach ca. 15-20 Minuten fällt der Transfer auf 5-20 KB/s Ich vermute mal, du hast die übliche Einstellung, daß die Schreibvorgängen Daten zuerst im RamCache, dann im zweiten Schritt in einem SSD Cache (ein Pool) und dann zuletzt ins Array geschrieben werden. Somit befüllst Du gar nicht direkt das Array, sondern schreibst in die Caches. Den nbei der Datenmenge (144GByte oder mehr) kann es nicht sein, daß Du daíeses Stocken erst nach 15-20 Minuten erlebst, denn das würde bedeuten, daß Du bei der Defaulteinstellung von unraid rund 250-400GB Ram haben müsstest. Deshalb vermute ich, daß Du doch einen SSD Cache dazwischen hast, sonst sollet das Stocken schon dirket nach 1-2 Minuten auftauchen. 1. Der RamCache ist eigentlich sehr fix und wird somit mit dem Maximum, was Dein LAN hergibt befüllt (bis zu 10GBLan kein Problem). Deine Angabe von ca. 120MByte/ deutet auf 1GBLan mit seinen maximal rund 112 MByte/s hin (+ etwas Messfehlertolleranz). 2. Wenn der Ramcache voll ist oder auch so ca. 20 Sekunden vergangen sind (Defaulteinstellung) schreibt der Ramcache in den SSD Cache. SSDs schreiben bei kleinen Datenmengen und kurzer Belastung alle sehr schnell die Daten weg. Aber wenn es größere Datenmengen sind trennt sich da die Spreu vom Weizen. Viele Günstige SSD tricksen, indem sie einerseits die ersten zu schreibenden Daten in einem SLC Pufferbereich schnell zwischenlagern und dann in späteren Ruhezeiten die Daten intern langdsam umkopieren, da sie eigentlich die Speicherzellen eher mit MLC oder QLC oder so befüllen. Dann ist der SLC Bereich wieder frei und sie kann das nächste kleine zu schreibende Häppchen wieder schnell verarbeiten. Zusätzlich werden SSDs unter hoher Last auch schnell warm und je nach Modell drosselt diese dann dei Arbeitsgeschwindigkeit herab. Einige SSDs gehen dann soweit runter in der Geschwindigkeit, daß man meinen könnte, sie sind "stehen geblieben". Da ich gerne große Datenmengen in meinen unraid SSD Cache schreibe, bevorzuge ich an der Stelle SSDs, die ziemlich Dauerschreibfest sind. Diese Modelle zu finden ist aber nicht so einfach. Falls ich mit meiner Annahme Deiner Konfiguration recht habe: Welche SSD setzt Du als Cache ein? 3. Sobald auch der SSD Cache voll ist (bis zum eingestellten Grenzwert) oder wenn kein SSD Cache zwischengeschaltet ist: dann schreibt unraid eben direkt auf das Array. Das Array schreibt aber (je nachdem, wie es eingestellt ist) mit nur 1/2 bis 1/3 der Geschwindigkeit der Parityfestplatte, weshalb dann einiges weggeschrieben wird und während dies geschrieben wird, unraid aus dem LAn nichts mehr entgegen nehmen kann. Dadurch sieht es so aus, als wenn für die Zeit unraid eben af wenigste kByte/s einbricht oder gar bei 0 steht. In Wirklichkeit schreibt unraid die Daten ins Array und erst, wenn das Häppchen ins Array komplett fertig geschrieben wurde kann der Teil aus dem jeweiligen Cache gelöscht werden und über LAN wieder etwas neues aufgenommen werden. Du schreibst von ca. 15-20 Minuten mit rund 120MBytes/s. Das bedeutet Du versuchst am Stück 120MByte/s * 60 Sekunden * 20 Minuten = 144000MByte = 144 GByte (und noch mehr) zu schreiben. Bei eine so hohen Zahl vermute ich, daß eben der Punkt 2 zum Tragen kommt: Du schreibst in den SSD Ccahe und bei der Menge kombinieren sich dann einmal hohe SSD Temperatur (=Drosselung) und vollgeschriebener SLC Pufferbereich (= zusätzliche Drosselung). 46 minutes ago, JokerHD said: und die CPU-Auslastung am unRaid geht auf über 80%. Das ist ein Anzeigefehler. Die Dashboardanzeige scheint auch Leerlaufzeiten/Wartezeiten mit als "beschäftigt" anzugeben. Ich glaube im Terminal der Befehl htop zeigt reale Werte an. 46 minutes ago, JokerHD said: Pausiere ich das kopieren und warte ein paar Minuten, hab ich wieder die volle Leistung. ...weil dann die SSD sich umsortieren konnte und der SLC Bereich wieder frei und die Temperatur wieder gesunken sein dürfte. 46 minutes ago, JokerHD said: Eine Cache-SSD-Platte hab ich erstmal noch deaktiviert, da ich mein Array noch am Befüllen bin, danach wird die SSD wieder aktiviert. Im Array-Betrieb sind 3x8TB Platten (1xParität und 2xDatenträger). Das kann ich so nicht glauben, da die Stockung sehr spät auftritt. 46 minutes ago, JokerHD said: Was hab ich übersehen? Das ein Array mit Parity nur 1/2 bei 1/3 der Schreibgeschwindigkeit der Parity erreicht, Du aber schneller Daten in urnaid rein pumpst und diese dann eben erst weggeschrieben werden müssen, deshalb stockt es dann. Bei 8TB Festplatten sollte Deine Reale Schreibgeschwindigkeit im Array mit Parity bei Defaulteinstellungen (also ohne Reconstruction Write) ungefär 40-60MByte/s erreichen. Und dann wären selbst 128GB Ram bei 20% Cacheeinstellung nach zu schreibenden 30-50GByte die Stockungen zu erleben. Nicht erst bei ca. 144GByte Datenmenge. 46 minutes ago, JokerHD said: Woran könnte das alles liegen? Hier noch ein Screenshot von der CPU-Auslastung. Zeige mal leigber die betreffende Share Einstellung und im Main Tab, welche SSDs und Festplattentypen du verwendest. 46 minutes ago, JokerHD said: Achja, ich kopiere von einem Windows 11 Rechner die Daten auf das Array. Also ganz normale SMB Freigabe. Quote Link to comment
JokerHD Posted January 13 Author Share Posted January 13 Vor 7 Minuten, hawihoney sagte: Guck Mal in top/htop ob das nicht IO-wait ist. Die Unraid Anzeige macht da keinen Unterschied. Der Linux Cache speichert zunächst ins RAM und wartet irgendwann auf die Platten. äh, Bahnhof? Sorry, ich komme an sich von der Windows-Welt und bin nicht sonderlich fit mit Linux. Aber ich hab das Ganze System gerade mal neu gestartet und die Docker nicht gleich mit gestartet, jetzt rennt die Kopieraktion. Scheint als habe ein Docker (es laufen 10 Stück) alles ausgebremst.... keine Ahnung. Quote Link to comment
JokerHD Posted January 13 Author Share Posted January 13 (edited) 39 minutes ago, DataCollector said: Das ein Array mit Parity nur 1/2 bei 1/3 der Schreibgeschwindigkeit der Parity erreicht, Du aber schneller Daten in urnaid rein pumpst und diese dann eben erst weggeschrieben werden müssen, deshalb stockt es dann. Bei 8TB Festplatten sollte Deine Reale Schreibgeschwindigkeit im Array mit Parity bei Defaulteinstellungen (also ohne Reconstruction Write) ungefär 40-60MByte/s erreichen. Und dann wären selbst 128GB Ram bei 20% Cacheeinstellung nach zu schreibenden 30-50GByte die Stockungen zu erleben. Nicht erst bei ca. 144GByte Datenmenge. Zeige mal leigber die betreffende Share Einstellung und im Main Tab, welche SSDs und Festplattentypen du verwendest. Jetzt als ich alles neu gestartet habe und die Docker nicht im Autostart hatte, läuft die Kopieraktion mit 40-55 MB/s! Das ist OK für mich. zu früh gefreut... jetzt kopiere ich wieder mit 100-120 kb/s Edited January 13 by JokerHD Quote Link to comment
alturismo Posted January 13 Share Posted January 13 37 minutes ago, JokerHD said: zu früh gefreut... jetzt kopiere ich wieder mit 100-120 kb/s das ist die Summe deiner Platten wahrscheinlich. du kannst versuchen Turbowrite (reconstruct) zu aktivieren für die Befüllung anstelle Standard. das umstellen auf reconstruct, geht auch im laufenden Betrieb. und nur gefragt, du hast keine USB Platten am Start ? Quote Link to comment
JokerHD Posted January 13 Author Share Posted January 13 Nein, keine USB-Platten! Alle am Mainboard angesteckt. md_write_method hab ich jetzt auf rekonstruktiv gesetzt und teste es erneut. Quote Link to comment
hawihoney Posted January 13 Share Posted January 13 (edited) 1 hour ago, JokerHD said: Scheint als habe ein Docker (es laufen 10 Stück) alles ausgebremst.... keine Ahnung. Docker Container haben per se nix damit zu tun - es sei denn sie schreiben gerade wie wild selbst auf die Platten. Das wüsstest Du aber, denn Du hättest das dann ja selbst initiiert. 1 hour ago, JokerHD said: äh, Bahnhof? Sorry, ich komme an sich von der Windows-Welt und bin nicht sonderlich fit mit Linux. Wenn man etwas nutzt, dann muss man sich über kurz oder lang damit beschäftigen. Eine erste kleine Starthilfe. Wenn die Werte so niedrig sind einfach mal die Unraid Konsole aufrufen: "top<Enter>" eingeben. TOP startet. Mit "q" beendest Du TOP. Mit "exit" verlässt Du die Konsole. Diesen Wert posten: Edited January 13 by hawihoney Quote Link to comment
hawihoney Posted January 13 Share Posted January 13 12 minutes ago, JokerHD said: md_write_method hab ich jetzt auf rekonstruktiv gesetzt und teste es erneut. Sollte aber nur eine Übergangslösung sein. Ist beim Schreiben - nur beim Schreiben - schneller aber dafür stromhungriger. Quote Link to comment
JokerHD Posted January 13 Author Share Posted January 13 kann es am Mover liegen? Denn jetzt wollte unRaid anscheinend noch irgendwelche Daten vom Cache auf das Array verschieben und plötzlich ist alles langsam. Im Cache sind auch noch ein paar Ordner, die er irgendwie auch nicht verschieben kann? Oder gehören die dort hin? Quote Link to comment
JokerHD Posted January 13 Author Share Posted January 13 4 minutes ago, hawihoney said: "top<Enter>" eingeben. TOP startet. Mit "q" kommst Du wieder raus. Mit "exit" verlässt Du die Konsole. Diesen Wert posten: hier meine Werte: Quote Link to comment
hawihoney Posted January 13 Share Posted January 13 Just now, JokerHD said: kann es am Mover liegen? Ja loggisch. Wenn von zwei Seiten gleichzeitig massiv geschrieben wird. 1 minute ago, JokerHD said: Oder gehören die dort hin? Die bleiben da. Im Gegenteil. Die sollten auch nicht woanders liegen. Quote Link to comment
hawihoney Posted January 13 Share Posted January 13 (edited) 2 minutes ago, JokerHD said: hier meine Werte zu 20 % wartet die CPU das die Platten mit dem Schreiben fertig werden - die CPU schläft. Sieht nicht tragisch aus. Könnte schlimmer sein. Es könnte das parallele Schreiben von MOVER und Dir sein. Edited January 13 by hawihoney Quote Link to comment
JokerHD Posted January 13 Author Share Posted January 13 wie beende ich den Mover bzw. was kopiert er denn? Es ist ja nichts mehr auf der Cache-SSD... ich versteh es nicht. Warum wird der Mover nicht fertig? Wenn ich mir die Übersicht anschaue, wird auf der Cache-SSD nichts gelesen/geschrieben. Vielen dank für eure Hilfe!!!! Ohne euch wäre ich aufgeschmissen, da ich sonst keinen kenne der irgendetwas mit Linux macht Quote Link to comment
DataCollector Posted January 13 Share Posted January 13 Danke für die Screenshots. Bei den Einstellungen wundert mich aber die geschriebene Datenmenge bis zum Stocken (bis zu 144GByte) sehr. Das hätte schon viel früher auffallen müssen. 2 hours ago, JokerHD said: zu früh gefreut... jetzt kopiere ich wieder mit 100-120 kb/s Wenn die Datenrate abfällt, wartest Du dann ein bisschen, bis es wieder steigt oder brichst Du ab, weil Du meinst, es steigt nicht wieder? Das Array schreibt im "Wellen". Quote Link to comment
DataCollector Posted January 13 Share Posted January 13 (edited) 1 hour ago, JokerHD said: kann es am Mover liegen? Denn jetzt wollte unRaid anscheinend noch irgendwelche Daten vom Cache auf das Array verschieben und plötzlich ist alles langsam. Wenn mehrere gleichzeitig auf die selbe Festplatte schreiben wollen ist es selbstverständlich noch langsamer. Da sich alle Schreibvorgänger bei der Parity treffen muß die dann zusätzlich die Köpfe nicht nur zum Suchen der normalen Datenströmen (Deine MP3) positionieren sondern kurz danach auch noch für die Schreiberei der anderen Quelle (Mover) neu positionieren. Und dann auch noch die Daten für die Parity jedesmal erst einlesen, warten bis die Datenposition (die ja gerade gelesen wurde) wieder unter dem Kopf ankommt um die dann zu schreiben..... Wenn dann der andere Datenstrom den Kopf wieder wegbewegen läßt .... naja, dann bremsen sich beide Datenströme gegenseitig stark aus. und die Geschwindigkleit der Parity bricht weiter ein. Festplatten mögen es eben nicht, sich mit Gleichzeitigen Schreiboperationen zu beschäftigen. Zusätzlich vermute ich anhand des Share-Namens, daß Du da viele kleine Dateien schreiben willst. Das wirst Du aus der Windowswelt ja auch kennen, wenn Du eine große Datei am Stück schreibst geht das wegen sequentieller Kopfbewegung sehr 'schnell'. Wenn aber für jede einzelne Datei der Kopf neu positioniert werden muß (um die Datei im Dateiverzeichnis einzutragen und dann die nächste freie Stelle zu suchen) geht schon da die Geschwindigkeit massiv herunter. Ob der Mover läuft kannst Du im Main Tab unten sehen. 1 hour ago, JokerHD said: Im Cache sind auch noch ein paar Ordner, die er irgendwie auch nicht verschieben kann? Oder gehören die dort hin? Es macht Sinn die relevanten Systemverzeichnisse nicht auf das langsame Array zu verschieben. Per Default ist das so eingestellt, daß die Verzeichnisse im Pool/Cache bleiben, weil sonst bei jedem Schreibvorgang darauf das Array anspringen müßte. Ich empfehle ernsthaft mal die Dokumentation von unraid durchzulesen (siehe bei unraid in der WebGui ganz unten rechts den Link). Edited January 13 by DataCollector Ergänzungen Quote Link to comment
JokerHD Posted January 13 Author Share Posted January 13 wenn es langsamer wird, mach ich kurz eine Pause und mach dann in ca. 2-3 Minuten wieder weiter. Dann läuft es wieder schnell. Gerade läuft es mit 5-20 kb/s und der Mover ist deaktiviert. Folglich kann es auch nicht am Mover liegen. Ich versteh es einfach nicht... es sind auch viele kleine MP3s die kopiert werden, aber das die Geschwindigkeit so in die Knie geht, ist nicht normal. Die Platten machen auch keine komischen Geräusche und schnurren vor sich hin. Aber jetzt geh ich erst mal an die frische Luft und mach meinen Kopf wieder etwas klarer. 1 Quote Link to comment
DataCollector Posted January 13 Share Posted January 13 (edited) 1 hour ago, JokerHD said: wie beende ich den Mover bzw. was kopiert er denn? Wie Du den Mover beenden kannst: Siehe Screenshot unten. Du öffnest die Konsole/Terminal (roter kreis) im neuen Fenster gibst Du mover stop ein und nach wenigen Sekunden sollte er Vollzug anzeigen. Das, was im Ram ist, schreibt er aber erst noch weg. [unten im Screenshot siehst Du auch die Schreibgeschwindigkeit, die ich auf dem Array mit 12TB Festplatten (7200Rpm non-SMR) in einem ganz gut gefüllten Zustand erreiche. Da schreibt er gerade vom Cache (NVMe SSD Pool) veranlaßt durch dem Mover diverse Videodateien (je ca. 1GB) auf das FestplattenArray.] 1 hour ago, JokerHD said: Es ist ja nichts mehr auf der Cache-SSD... ich versteh es nicht. Je nachdem, wie die jeweiligen Shares eingestellt sind vollzieht der Mover die dort festgelegten Operationen. Wenn nichts auf dem Cache ist und sogar der Inhalt der Systemverzeichnisse ins Array verschoben wurden, kommen die Schreiboperation in die Systemverzeichnisse Deinen eigenen Kopieraktionen in die Quere. 1 hour ago, JokerHD said: Warum wird der Mover nicht fertig? Er braucht so lange, wie die jeweilige Kopieraktion dieser betroffenen Dateien eben braucht. Er ist nicht langsamer oder schneller wie normale Schreiboperationen auch. 1 hour ago, JokerHD said: Wenn ich mir die Übersicht anschaue, wird auf der Cache-SSD nichts gelesen/geschrieben. Hast Du vielleicht irgendwelche anderen shares, die Du eventuell ungünstig eingestellt hast, so daß der mover dort irgendetwas macht? Edited January 13 by DataCollector Quote Link to comment
alturismo Posted January 13 Share Posted January 13 und vielleicht nochmals als Hinweis, der /system Share ... und wenn Docker Directory anstelle Image eingestellt ist ... und dann der mover läuft, vor allem wenn die Dockers aus sind ... kopiert xyz Betriebssysteme (in den Dockers ist jeweils ein kleines OS drin) mit gefühlten mio Dateien ... das ist "Kopfschuss" ... gelesen werden die recht flott in den RAM cache (Linux macht das immer so), der writeout auf die disks ... dauert aber ... also, falls docker directory eingestellt ist anstelle docker image ... wäre dies auch eine Ursache. Quote Link to comment
JokerHD Posted January 13 Author Share Posted January 13 ich glaub ich hab Docker so eingestellt, dass er ein Directory erstellt und nicht ein Image macht... könnte natürlich auch daran liegen.... mein aktueller Plattenspeed ist bei 1,2 MB... jetzt hab ich den cache deaktiviert, so dass ich direkt auf das Array speichere und es ist auch nicht besser. Oder hab ich etwas bei den Freigaben falsch gemacht? Quote Link to comment
alturismo Posted January 13 Share Posted January 13 52 minutes ago, JokerHD said: ich glaub ich hab Docker so eingestellt, dass er ein Directory erstellt und nicht ein Image macht... könnte natürlich auch daran liegen.... dann hast du das Szenario ... gefühlt 1 mrd Dateien (kleine ...) die auf das Array wollten ... sofern vorher cache > array da eingestellt war, wenn jetzt gerade das Ganze retour läuft weil umgestellt dann liest er die ganzen Dateien usw usw ... wenn aktuell kein mover läuft, dann passt was nicht, kenne ich nur von "zu Ende" gehenden Platten. Quote Link to comment
JokerHD Posted January 13 Author Share Posted January 13 Docker hatte ich vorher auch schon auf Verzeichnis gehabt, da ich das irgendwo gelesen habe, dass es so besser sein soll. Wenn es etwas bringt kann ich auch auf xfs-vdisk stellen. Aber an dem wird es vermutlich nicht liegen, denn der Mover läuft gerade nicht und es schwangt mit der Geschwindigkeit. Von 0 bis 2,4 bis 80 MB/s ist alles dabei. Die obere Platte ist die Parity und die beiden anderen das Array. An den Platten dürfte es auch nicht liegen, die sind ca. 1 - 1,5 Jahre alt und wurden nur selten benutzt. Sind allerdings ganz normale Seagate-Platten. Quote Link to comment
JokerHD Posted January 13 Author Share Posted January 13 habe mir gerade noch einen Test-Server ohne Lizenz aufgebaut und dort wird gerade die Parität geprüft und Daten kopiert und ich komme auf knappe 50 MB/s! Also muss ich irgendetwas am System verstellt haben... nur was? Quote Link to comment
DataCollector Posted January 13 Share Posted January 13 (edited) 2 hours ago, JokerHD said: mein aktueller Plattenspeed ist bei 1,2 MB... jetzt hab ich den cache deaktiviert, so dass ich direkt auf das Array speichere und es ist auch nicht besser. Oder hab ich etwas bei den Freigaben falsch gemacht? Du schreibst gleichzeitig auf mehrere Datenträger im Array? Wie angedeutet, wenn Du Parity nutzt, kommen die sich auf der Parity alle Schreibvorgänge in die Quere und es bremst zusätzlich. Edited January 13 by DataCollector Quote Link to comment
JokerHD Posted January 13 Author Share Posted January 13 Ich hab drei 8TB Platten, davon ist eine die Parity und zwei im Array. Die zweite Platte ist bis jetzt aus geblieben, da die erste noch nicht voll ist. Somit wird an sich nur auf zwei Platten geschrieben, oder? Oder hab ich hier einen kompletten Gedankenfehler? Seit ca. 15 Minuten kopiert er mit 80-100 MB/s! Keine Ahnung warum die Geschwindigkeit jetzt wieder passt. Quote Link to comment
Recommended Posts
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.