15
4 x 3TB im Raid 5 sehr langsam bei kleinen Dateien, warum?
Hallo,
ich möchte Filme schneiden und habe mir nun eine Systemlösung von VIDEOSTATION zugelegt. Der Rechner läuft sehr gut, allerdings habe ich große Probleme mit dem RAID.
Es sind vier SATA Platten von Seagate (ST3000DM001) mit je 3TB an einem Intel C600 Controller verbaut, die beim Lesen auch guten Datendurchsatz liefern, beim Schreiben aber grottenschlecht sind. Teilweise liegen die Schreibraten bei 12MB/s.
Nun ist eine Besonderheit bei meinen Projekten, dass die Filme nicht aus großen Dateien bestehen, sondern nahezu immer aus einzelnen JPGs zusammengesetzt werden. Die JPGs sind zwischen 1,5 und 7 MB groß, und es sind Hunderttausende. Außerdem verwalte ich die Bilder mit Adobe Lightroom, dessen Kataloge aus unglaublich vielen, winzigen Dateien bestehen.
Sind die Dateien erst mal auf dem RAID, ist alles gut, aber bis sie da sind dauert es Ewigkeiten. Zusätzlich habe ich auch noch das Problem, dass ich die Dateien oftmals redundant halten muss, um verschiedene Sichtweisen auf die Fotos zu haben. Das Anlegen von Kopien vom RAID auf das RAID ist eine Qual. Langer Rede, kurzer Sinn: mein RAID 5 schreibt diese vielen eher kleineren Dateien extrem langsam.
Nun habe ich keine Erfahrung mit RAIDs, die Konfiguration wurde mir vom Hersteller des Schnittrechners für meine Belange empfohlen, ich bin aber ziemlich unglücklich damit.
Meine Frage ist jetzt: Kann es sein, dass mit dem RAID was nicht stimmt, oder ist das RAID 5 technisch in Ordnung aber grundsätzlich eher ungeeignet für meine Anforderungen?
Ich schiebe morgen noch Benchmarks nach, im Moment initialisiert das RAID noch, angeblich soll das etwas Performance bringen.
ich möchte Filme schneiden und habe mir nun eine Systemlösung von VIDEOSTATION zugelegt. Der Rechner läuft sehr gut, allerdings habe ich große Probleme mit dem RAID.
Es sind vier SATA Platten von Seagate (ST3000DM001) mit je 3TB an einem Intel C600 Controller verbaut, die beim Lesen auch guten Datendurchsatz liefern, beim Schreiben aber grottenschlecht sind. Teilweise liegen die Schreibraten bei 12MB/s.
Nun ist eine Besonderheit bei meinen Projekten, dass die Filme nicht aus großen Dateien bestehen, sondern nahezu immer aus einzelnen JPGs zusammengesetzt werden. Die JPGs sind zwischen 1,5 und 7 MB groß, und es sind Hunderttausende. Außerdem verwalte ich die Bilder mit Adobe Lightroom, dessen Kataloge aus unglaublich vielen, winzigen Dateien bestehen.
Sind die Dateien erst mal auf dem RAID, ist alles gut, aber bis sie da sind dauert es Ewigkeiten. Zusätzlich habe ich auch noch das Problem, dass ich die Dateien oftmals redundant halten muss, um verschiedene Sichtweisen auf die Fotos zu haben. Das Anlegen von Kopien vom RAID auf das RAID ist eine Qual. Langer Rede, kurzer Sinn: mein RAID 5 schreibt diese vielen eher kleineren Dateien extrem langsam.
Nun habe ich keine Erfahrung mit RAIDs, die Konfiguration wurde mir vom Hersteller des Schnittrechners für meine Belange empfohlen, ich bin aber ziemlich unglücklich damit.
Meine Frage ist jetzt: Kann es sein, dass mit dem RAID was nicht stimmt, oder ist das RAID 5 technisch in Ordnung aber grundsätzlich eher ungeeignet für meine Anforderungen?
Ich schiebe morgen noch Benchmarks nach, im Moment initialisiert das RAID noch, angeblich soll das etwas Performance bringen.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 240318
Url: https://administrator.de/contentid/240318
Printed on: April 19, 2024 at 11:04 o'clock
15 Comments
Latest comment
Hallo,
Explizit wäre natürlich der RAID Controller und auch die verwendeten HDDs interessant zu wissen.
oder wie kopierst Du die Daten?
Gruß
Dobby
ich möchte Filme schneiden und habe mir nun einen Systemlösung von VIDEOSTATION zugelegt.
Verrätst Du uns denn auch noch was genau für Hardware verbaut wurde?Explizit wäre natürlich der RAID Controller und auch die verwendeten HDDs interessant zu wissen.
Sind die Dateien erst mal auf dem RAID, ist alles gut, aber bis sie da sind dauert es Ewigkeiten.
Und wie kommen die Daten denn dahin? Via USB 2.0, eSATA, SAS, Netzwerk oder USB 3.0,oder wie kopierst Du die Daten?
Gruß
Dobby
Zu erst einmal: Die Empfehlung hat wohl wenig getaugt. Ich würde sagen, gib uns mehr Infos und SSDs sind nun auch nicht mehr soo teuer.
Die Konfiguration ist denkbar ungeeignet. C600 ist ein Chipset, also ist die Frage, ob da überhaupt ein Option-Key drauf ist, oder mit einem reinen RST-Treiber-RAID gearbeitet wird.
Bei Paritäts-RAIDs hat die Anzahl der Platten Einfluss auf die Schreib-Performance.
Die Netto-Plattenzahl ohne Paritätsplatte sollte idealerweise eine Zweierpotenz sein. Eine Abweichung ist bei großen RAIDs in der Regel nicht spürbar, hingegen schon, wenn man wie Du mit der kleinstmöglichen schlechten Plattenzahl auf einem Pseudo-Controller unterwegs ist. Außerdem sollten möglichst große Dateisystem-Cluster gewählt werden, was hier allerdings mit dem Anwendungszweck in Ausgleich zu bringen ist.
Die ST3000DM001 leistet an dedizierten Controllern durchaus gute Dienste.
Grüße
Richard
Bei Paritäts-RAIDs hat die Anzahl der Platten Einfluss auf die Schreib-Performance.
Die Netto-Plattenzahl ohne Paritätsplatte sollte idealerweise eine Zweierpotenz sein. Eine Abweichung ist bei großen RAIDs in der Regel nicht spürbar, hingegen schon, wenn man wie Du mit der kleinstmöglichen schlechten Plattenzahl auf einem Pseudo-Controller unterwegs ist. Außerdem sollten möglichst große Dateisystem-Cluster gewählt werden, was hier allerdings mit dem Anwendungszweck in Ausgleich zu bringen ist.
Die ST3000DM001 leistet an dedizierten Controllern durchaus gute Dienste.
Grüße
Richard
Hallo nochmal,
Die HDDs sind auch extra für den Desktop und RAID Betrieb ausgelegt, gar keine Frage die taugen schon
was, aber ich denke man sollte doch wohl über die Anschaffung eines richtigen RAID Controllers nachdenken
und eventuell sogar über ein Cachemodul, aber das muss auch jeder mit sich selber entscheiden was Ihm das
wert ist.
Und wie kommen die Bilder nun auf den PC oder die WS drauf?
Gruß
Dobby
Es sind vier SATA Platten von Seagate (ST3000DM001) mit je 3TB an einem Intel C600 Controller verbaut,
Hättest ja auch einfach antworten können, aber ok, das ist schon etwas mehr Information.Die HDDs sind auch extra für den Desktop und RAID Betrieb ausgelegt, gar keine Frage die taugen schon
was, aber ich denke man sollte doch wohl über die Anschaffung eines richtigen RAID Controllers nachdenken
und eventuell sogar über ein Cachemodul, aber das muss auch jeder mit sich selber entscheiden was Ihm das
wert ist.
Und wie kommen die Bilder nun auf den PC oder die WS drauf?
Gruß
Dobby
Hallo und danke für Eure Antworten.
Bitte entschuldigt, dass ich die Hardware-Infos erst nachgetragen hatte. Hatte ich gemacht, während hier bereits gelesen wurde!
Also inzwischen ist die Initialisierung des RAID durch, und ich füge Benchmarkergebnisse und Bilder der Konfiguration an. Was sagt ihr zu den Ergebnissen bzw. der Konfiguration?
Zu euren Fragen bzw. Bemerkungen: Das Gehäuse hat Einschübe für SATA-Platten, die meisten Daten habe ich durch den Ausbau der Platten aus dem alten Rechner aufgespielt, also eingeschoben und kopiert. Teilweise kamen die Daten auch über eine externe USB-3.0 Platte.
Ich hatte tatsächlich im Kundengespräch erwähnt, dass mir eher daran gelegen sei, eine superschnelle Lösung mit wenig Speicherkapazität zu haben, als eine mittelschnelle mit viel. Der Berater sagte allerdings, dass SSDs grundsätzlich für die Verwendung in Videoschnittplätzen ungeeignet seien. Mir fällt jetzt gerade nicht mehr ein warum, ich kann das aber nochmal nachfragen. Tatsächlich ist es allerdings so, dass ich nun doch froh wäre, wenn ich eine schnelle Lösung auch im TB-Bereich hätte, eines meiner Projekte besteht aus ca. 1,5 TB Fotos, alle zwei bis fünf MB groß.
Weil ich hier an den Kommentar keine Bilder drangehängt bekomme, habe ich Sie meiner Eingangfrage zugefügt, allerdings sehe ich sie da auch nur, wenn ich die Frage bearbeite.
Sicherheitshalber hier Links zu den Bildern auf meiner Webseite:
ATTO Diskbench
Crsytal Diskmark
Volumeeigenschaften
Platteneigenschaften
Copy Totalcommander A
Copy Totalcommander B
Copy Explorer
Ich danke Euch sehr!
Bitte entschuldigt, dass ich die Hardware-Infos erst nachgetragen hatte. Hatte ich gemacht, während hier bereits gelesen wurde!
Also inzwischen ist die Initialisierung des RAID durch, und ich füge Benchmarkergebnisse und Bilder der Konfiguration an. Was sagt ihr zu den Ergebnissen bzw. der Konfiguration?
Zu euren Fragen bzw. Bemerkungen: Das Gehäuse hat Einschübe für SATA-Platten, die meisten Daten habe ich durch den Ausbau der Platten aus dem alten Rechner aufgespielt, also eingeschoben und kopiert. Teilweise kamen die Daten auch über eine externe USB-3.0 Platte.
Ich hatte tatsächlich im Kundengespräch erwähnt, dass mir eher daran gelegen sei, eine superschnelle Lösung mit wenig Speicherkapazität zu haben, als eine mittelschnelle mit viel. Der Berater sagte allerdings, dass SSDs grundsätzlich für die Verwendung in Videoschnittplätzen ungeeignet seien. Mir fällt jetzt gerade nicht mehr ein warum, ich kann das aber nochmal nachfragen. Tatsächlich ist es allerdings so, dass ich nun doch froh wäre, wenn ich eine schnelle Lösung auch im TB-Bereich hätte, eines meiner Projekte besteht aus ca. 1,5 TB Fotos, alle zwei bis fünf MB groß.
Weil ich hier an den Kommentar keine Bilder drangehängt bekomme, habe ich Sie meiner Eingangfrage zugefügt, allerdings sehe ich sie da auch nur, wenn ich die Frage bearbeite.
Sicherheitshalber hier Links zu den Bildern auf meiner Webseite:
ATTO Diskbench
Crsytal Diskmark
Volumeeigenschaften
Platteneigenschaften
Copy Totalcommander A
Copy Totalcommander B
Copy Explorer
Ich danke Euch sehr!
Hallo nochmal,
nicht an den Symptomen herum doktern sonder das Problem beheben.
Also mit einer USB 3.0 HDD sollte das doch aber flott zur Sache gehen, dann kann es eben nur daran liegen
das der RAID Controller bremst. Ich würde einfach noch einmal zu dem Händler hingehen und dann nachfragen
wie es denn mit einem richtigen Hardware Controller aussieht.
eben auch immer die Frage des Budgets und meist ist das nicht so üppig und dann "fällt" eben hinten etwas herunter
bzw. man hat dann eben einen Flaschenhals im System. Klar mit einem potenten iMac (Intel Core i7 & 32 GB RAM)
und einem Thunderbolt NAS wäre das nicht passiert.
es hier nicht richtig wieder, denn wenn ich einen PC oder eine Workstation habe und installiere das OS und die Software
auf einer 256 GB oder 512 GB SSD z.B. einer Samsung840 Pro dann ist auf jeden Fall schon einmal garantiert dass das
OS und die Software schnell booten und starten aber auch reagieren, und das sicherlich auch bei einer WS für den
VIdeoschnitt, kann es sein das der Berater eventuell die SSD in Zusammenhang mit dem RAID als ungeeignet ansah?
worauf ist denn das Windows OS installiert worden? Auch auf dem RAID5?
- Samsung840 Pro mit 256 GB oder 512 GB für OS und Programme
- Hardware Raidcontroller mit Cachemodul
- Deine HDDs dazu als RAID5
Das ist aber auch immer davon abhängig wie man sich organisiert!
Ich frage mich jetzt schon wie Du die ganzen Bilder und Projekte sicherst?
Also wenn das mit dem Geld nicht so pralle ist kann man sicher auch ein
oder zwei WD VelociRaptor mit 1TB kaufen und diese dann so in das System
(nicht das RAID) einbinden, die drehen mit 10.000 Umdrehungen und sind
dennoch Destop HDDs als keine Server HDDs für 24/7.
an der Stelle einfügen wo die Bilder zusehen seien sollen.
Gruß
Dobby
Also inzwischen ist die Initialisierung des RAID durch, und ich füge Benchmarkergebnisse und Bilder
der Konfiguration an. Was sagt ihr zu den Ergebnissen bzw. der Konfiguration?
Ich denke das ist völlig sekundär! Denn wenn es Dir nicht schnell genug geht sollte mander Konfiguration an. Was sagt ihr zu den Ergebnissen bzw. der Konfiguration?
nicht an den Symptomen herum doktern sonder das Problem beheben.
Also mit einer USB 3.0 HDD sollte das doch aber flott zur Sache gehen, dann kann es eben nur daran liegen
das der RAID Controller bremst. Ich würde einfach noch einmal zu dem Händler hingehen und dann nachfragen
wie es denn mit einem richtigen Hardware Controller aussieht.
Ich hatte tatsächlich im Kundengespräch erwähnt, dass mir eher daran gelegen sei, eine superschnelle Lösung mit wenig
Speicherkapazität zu haben, als eine mittelschnelle mit viel.
Na dann hätte man ja auch einfach andere HDDs und einen echten RAID Controller nehmen können, nur das istSpeicherkapazität zu haben, als eine mittelschnelle mit viel.
eben auch immer die Frage des Budgets und meist ist das nicht so üppig und dann "fällt" eben hinten etwas herunter
bzw. man hat dann eben einen Flaschenhals im System. Klar mit einem potenten iMac (Intel Core i7 & 32 GB RAM)
und einem Thunderbolt NAS wäre das nicht passiert.
Der Berater sagte allerdings, dass SSDs grundsätzlich für die Verwendung in Videoschnittplätzen ungeeignet seien.
Also da ist entweder aneinander vorbei geredet worden und oder Du hast etwas nicht richtig verstanden bzw. gibstes hier nicht richtig wieder, denn wenn ich einen PC oder eine Workstation habe und installiere das OS und die Software
auf einer 256 GB oder 512 GB SSD z.B. einer Samsung840 Pro dann ist auf jeden Fall schon einmal garantiert dass das
OS und die Software schnell booten und starten aber auch reagieren, und das sicherlich auch bei einer WS für den
VIdeoschnitt, kann es sein das der Berater eventuell die SSD in Zusammenhang mit dem RAID als ungeeignet ansah?
Mir fällt jetzt gerade nicht mehr ein warum, ich kann das aber nochmal nachfragen.
Ist nicht weiter wild, Du hast ja schnell HDDs und die bringen auch etwas, aber mal eine ganz andere Sacheworauf ist denn das Windows OS installiert worden? Auch auf dem RAID5?
Tatsächlich ist es allerdings so, dass ich nun doch froh wäre, wenn ich eine schnelle Lösung
auch im TB-Bereich hätte, eines meiner Projekte besteht aus ca. 1,5 TB Fotos, alle zwei bis fünf MB groß.
Also ich würde das so lösen.auch im TB-Bereich hätte, eines meiner Projekte besteht aus ca. 1,5 TB Fotos, alle zwei bis fünf MB groß.
- Samsung840 Pro mit 256 GB oder 512 GB für OS und Programme
- Hardware Raidcontroller mit Cachemodul
- Deine HDDs dazu als RAID5
Das ist aber auch immer davon abhängig wie man sich organisiert!
Ich frage mich jetzt schon wie Du die ganzen Bilder und Projekte sicherst?
Also wenn das mit dem Geld nicht so pralle ist kann man sicher auch ein
oder zwei WD VelociRaptor mit 1TB kaufen und diese dann so in das System
(nicht das RAID) einbinden, die drehen mit 10.000 Umdrehungen und sind
dennoch Destop HDDs als keine Server HDDs für 24/7.
Weil ich hier an den Kommentar keine Bilder drangehängt bekomme, habe ich Sie meiner Eingangfrage zugefügt,
allerdings sehe ich sie da auch nur, wenn ich die Frage bearbeite.
Wenn Dui die Bilder hochgeladen hast, musst Du den Code rechts neben den Bildern kopieren und in den Textallerdings sehe ich sie da auch nur, wenn ich die Frage bearbeite.
an der Stelle einfügen wo die Bilder zusehen seien sollen.
Gruß
Dobby
Hi.
Du hast Dich beraten lassen und bist nun dennoch unzufrieden. Konfrontiere zunächst den Berater damit und bitte ihn um Rat. Lote die Möglichkeiten aus, die Hardware zu tauschen.
Zur Performance: die sequentiellen ("am Stück") Werte der Benchmarks sind akzeptabel. Natürlich ist der Vorgang des sequentiellen Schreibens/Lesens hier nicht gegeben, Du kopierst ja von dem Raid auf das selbe Raid und, wenn ich richtig verstehe, ist das auch ein häufiger Anwendungsfall - also hättest Du den Berater damit konfrontieren müssen und fragen können, was denn da für Werte zu erwarten sind - so wird man dann auch nicht so leicht enttäuscht.
Zur Performance: Ich hätte aus dem Bauch raus getippt, dass das Onboard-Raid nicht so schlecht sein dürfte, wie es sich darstellt - 20-30MB/s bei Deinen Explorer-Copy-Tests (und die Dateien sind NICHT klein, das sind ja schon ein paar MB, klein wäre im kB-Bereich) ist wenig, da hätte ich etwa das 3-fache erwartet.
Die Performance hängt ab von Soft- und Hardware, genauer:
Controller, Cont.-Treiber und -Firmware | Platten, ggf. Plattenfirmware | Betriebssystem + Updates | Softwareumgebung, die Einfluss auf das Lesen/Schreiben nimmt (Virenscanner/Verschlüsselung) | Sonstige Belastung des Dateisystems (OS mit auf dem RAID?)
Wie Du siehst: ein ganz schöner Aufwand, das alles im Blick zu haben. Das muss der Hersteller alles für Dich leisten und wenn es dann noch nicht läuft wie gewünscht, muss er (falls er kulant ist oder vertraglich gebunden) nachbessern.
SSDs würden mit Sicherheit besser abschneiden. Kurzes Beispiel aus einem Rechner, den wir gerade gebaut haben: Raid 5 mit 4x 1TB Samsung 840 EVO an einem 3ware 9750 (Sata3): kopieren von großen Dateien (20x500MB) vom Raid auf's Raid mit ca. 1 GB/s.
Stell also bitte einmal die Beratung in Frage, vielleicht kommt man Dir entgegen.
Du hast Dich beraten lassen und bist nun dennoch unzufrieden. Konfrontiere zunächst den Berater damit und bitte ihn um Rat. Lote die Möglichkeiten aus, die Hardware zu tauschen.
Zur Performance: die sequentiellen ("am Stück") Werte der Benchmarks sind akzeptabel. Natürlich ist der Vorgang des sequentiellen Schreibens/Lesens hier nicht gegeben, Du kopierst ja von dem Raid auf das selbe Raid und, wenn ich richtig verstehe, ist das auch ein häufiger Anwendungsfall - also hättest Du den Berater damit konfrontieren müssen und fragen können, was denn da für Werte zu erwarten sind - so wird man dann auch nicht so leicht enttäuscht.
Zur Performance: Ich hätte aus dem Bauch raus getippt, dass das Onboard-Raid nicht so schlecht sein dürfte, wie es sich darstellt - 20-30MB/s bei Deinen Explorer-Copy-Tests (und die Dateien sind NICHT klein, das sind ja schon ein paar MB, klein wäre im kB-Bereich) ist wenig, da hätte ich etwa das 3-fache erwartet.
Die Performance hängt ab von Soft- und Hardware, genauer:
Controller, Cont.-Treiber und -Firmware | Platten, ggf. Plattenfirmware | Betriebssystem + Updates | Softwareumgebung, die Einfluss auf das Lesen/Schreiben nimmt (Virenscanner/Verschlüsselung) | Sonstige Belastung des Dateisystems (OS mit auf dem RAID?)
Wie Du siehst: ein ganz schöner Aufwand, das alles im Blick zu haben. Das muss der Hersteller alles für Dich leisten und wenn es dann noch nicht läuft wie gewünscht, muss er (falls er kulant ist oder vertraglich gebunden) nachbessern.
SSDs würden mit Sicherheit besser abschneiden. Kurzes Beispiel aus einem Rechner, den wir gerade gebaut haben: Raid 5 mit 4x 1TB Samsung 840 EVO an einem 3ware 9750 (Sata3): kopieren von großen Dateien (20x500MB) vom Raid auf's Raid mit ca. 1 GB/s.
Stell also bitte einmal die Beratung in Frage, vielleicht kommt man Dir entgegen.
Du kannst es weiter eingrenzen, indem Du in den Richtlinien des Volumes im Gerätemanager das von Windows veranlasste Leeren des Schreibcaches deaktivierst. Das ist allerdings ohne USV keine Einstellung für den Produktivbetrieb.
Wenn dabei der extreme Abfall von 0,5k- auf 4k-Random erhalten bleibt, stimmt wahrscheinlich auch das Alignment von RAID und Clustern mit den 4k-Sektoren nicht gegeben. Warum ist schwer zu sagen, weil das bei der Einrichtung des RAIDs mit einem aktueller Treiber an sich automatisch richtig gemacht wird.
Ich bin der Meinung, hier kann man keine SSDs empfehlen. Der mehr als zehnfache Preis pro GB wäre am Onboard-Controller reine Verschwendung. Das Geld ist in einer vernünftigen Karte mit Backup-Unit besser angelegt. Da kannst Du über die Jahre immer noch SSDs dran hängen und auch suboptimale Konfigurationen wie ein Vierer-RAID5 fahren, ohne dass es zu sehr ins Gewicht fällt.
Wenn dabei der extreme Abfall von 0,5k- auf 4k-Random erhalten bleibt, stimmt wahrscheinlich auch das Alignment von RAID und Clustern mit den 4k-Sektoren nicht gegeben. Warum ist schwer zu sagen, weil das bei der Einrichtung des RAIDs mit einem aktueller Treiber an sich automatisch richtig gemacht wird.
Ich bin der Meinung, hier kann man keine SSDs empfehlen. Der mehr als zehnfache Preis pro GB wäre am Onboard-Controller reine Verschwendung. Das Geld ist in einer vernünftigen Karte mit Backup-Unit besser angelegt. Da kannst Du über die Jahre immer noch SSDs dran hängen und auch suboptimale Konfigurationen wie ein Vierer-RAID5 fahren, ohne dass es zu sehr ins Gewicht fällt.
Wenn so etwas noch einmal ansteht bzw. es zu einem Neukauf kommt
mach es gleich "richtig" und investiere gleich in einen iMAC und andere
Software.
Kleine Lösung:
iMac oder MacBook mit Pegasus NAS
Pegasus Thunderbolt NAS Erweiterung
Große Lösung:
Mac Pro + Thunderbolt NAS klein
Mac Pro + Thunderbolt NAS mittel
Mac Pro + Thunderbolt NAS groß
Software:
FinalCut Pro X
Smoke
Das löst zwar Dein jetziges Problem nicht und ist je nach Lösung
auch nicht billig, aber "super schnell" und es läuft!
Gruß
Dobby
mach es gleich "richtig" und investiere gleich in einen iMAC und andere
Software.
Kleine Lösung:
iMac oder MacBook mit Pegasus NAS
Pegasus Thunderbolt NAS Erweiterung
Große Lösung:
Mac Pro + Thunderbolt NAS klein
Mac Pro + Thunderbolt NAS mittel
Mac Pro + Thunderbolt NAS groß
Software:
FinalCut Pro X
Smoke
Das löst zwar Dein jetziges Problem nicht und ist je nach Lösung
auch nicht billig, aber "super schnell" und es läuft!
Gruß
Dobby
Hallo und danke für Eure Beiträge,
also nochmal zur Konfiguration: Im Rechner ist eine 256GB Samsung 840 Pro, darauf das System. Außerdem: i7 CPU, NVIDIA K4000 Karte, 32 GB RAM.
Das RAID ist also nur für die Daten da.
Ein Mac kommt nicht in Frage, weil ich Windows-Programmierer bin und jede Menge Eigensoftware am Start habe, die man so einfach auf dem Mac auch nicht zimmern könnte.
Also wenn ich das richtig sehe, ist das RAID einfach zu langsam. Ich wende mich jetzt letztmalig mal an den Hersteller, der Rechner war ja schon zweimal bei ihm.
Zu den "echten" Controllern: Ist es nicht inzwischen so, dass bei einem i7 die Berechnung der Parität so marginal ist, dass die CPU sowieso nicht mehr wesentlich belastet wird. Was ist der genaue Vorteil eines echten Controllers?
Danke euch sehr!
also nochmal zur Konfiguration: Im Rechner ist eine 256GB Samsung 840 Pro, darauf das System. Außerdem: i7 CPU, NVIDIA K4000 Karte, 32 GB RAM.
Das RAID ist also nur für die Daten da.
Ein Mac kommt nicht in Frage, weil ich Windows-Programmierer bin und jede Menge Eigensoftware am Start habe, die man so einfach auf dem Mac auch nicht zimmern könnte.
Also wenn ich das richtig sehe, ist das RAID einfach zu langsam. Ich wende mich jetzt letztmalig mal an den Hersteller, der Rechner war ja schon zweimal bei ihm.
Zu den "echten" Controllern: Ist es nicht inzwischen so, dass bei einem i7 die Berechnung der Parität so marginal ist, dass die CPU sowieso nicht mehr wesentlich belastet wird. Was ist der genaue Vorteil eines echten Controllers?
Danke euch sehr!
Falls jemand noch an meinem Fall interessiert ist: Ich habe das RAID 5 nun aufgelöst und in ein RAID 10 verwandelt. So verliere ich zwar Speicherplatz, aber ich gewinne deutlich Schreibgeschwindigkeit. Ein Mix aus allen möglichen Datengrößen zeigt beim Kopieren von S-ATA ins RAID 10 nun 110MB/s. Ich weiß nicht, was ich hätte machen können, um das RAID 5 nun doch noch einigermaßen an den Start zu kriegen, so jedenfalls bin ich mit der Performance zufrieden. Ich weiß nun nicht, ob ich den Thread als "Gelöst markieren" sollte!? 
Was mich aber noch interessieren würde: C.R.S. schreibt, dass RAID 5 mit vier Platten suboptimal wären. Warum ist das so? Das habe ich noch nicht verstanden.
Nochmals vielen Dank für Eure Tips!
Was mich aber noch interessieren würde: C.R.S. schreibt, dass RAID 5 mit vier Platten suboptimal wären. Warum ist das so? Das habe ich noch nicht verstanden.
Nochmals vielen Dank für Eure Tips!
Hallo,
schreibe doch mal auf externe Festplatten. Vieleicht ist es dort schneller.
Wie alt sind die "langsamen" Festplatten?
Gruß Marco
schreibe doch mal auf externe Festplatten. Vieleicht ist es dort schneller.
Wie alt sind die "langsamen" Festplatten?
Gruß Marco
Hi,
vor der Erklärung wollte ich mich nicht ohne Grund drücken. Auf deine Nachricht hin versuche ich es mal:
Das hängt damit zusammen, dass ein Dateisystem auf das RAID-Volume immer in seiner jeweiligen Cluster-Größer von 4k, 8k, 16k usw. schreibt. Der Controller hingegen adressiert Sektoren von typischweise 0,5k Größe (in deinem Fall Advanced-Format) und berechnet auf dieser Ebene auch die Parität bei einem Schreibvorgang.
Die Frage führt häufig zu "kontroversen" Diskussionen, weil der Befund in vielen Fällen eindeutig ist, in vielen aber auch nicht, vgl. hier: http://serverfault.com/questions/365903/why-does-raid5-with-an-odd-numb ...
Dabei ist ein üblicher Denkfehler, dass natürlich nicht die Anzahl der Platten die Allokation der Cluster auf einzelnen Stripes bestimmt. Eine Datenmenge x wird nicht zuerst durch die Anzahl der Platten geteilt und dann geschrieben, sondern die Stripes werden "gefüllt".
Der Zusammenhang mit der Anzahl der Platten ergibt sich vielmehr indirekt aus dem Zusammenhang von Cluster- und Sektorgröße. Wenn sich Cluster nicht durch ein ganzzahliges Vielfaches der Netto-Plattenzahl auf Sektoren aufteilen lassen, entsteht bei Schreibvorgängen, die größer als ein Stripe sind, also Nutzdaten-Stripes auf mindestens zwei Platten und das Parity-Stripe auf einer dritten Platte betreffen, ein zusätzlicher Overhead bei der Neuberechnung der Parität eigentlich nicht geänderter Sektoren, der statistisch umso relevanter ist, je größer die Abweichung tatsächlicher Schreibgrößen vom Vielfachen einer Cluster-Größe ist. Oder anders: der unvermeidliche Cluster-Overhead ist im Allgemeinen günstiger allokiert, wenn die Netto-Plattenzahl ganzzahlig mit dem Verhältnis von Cluster- zu Sektor-Größe zusammenhängt. Da beide Größen eine Zweierpotenz sind, ist ihr Verhältnis auch eine, ist die ideale Plattenzahl eine Zweierpotenz plus Paritätsaufwand.
Der Effekt kann zudem unterschiedlich verstärkt werden, abhängig von mehreren zusammenhängenden Faktoren:
- Da der RAID-Controller eine logische Sektorgröße von ebenfalls 0,5k abbildet, ist das Alignment der darauf erstellten Partition granularer als die Cluster-Größe (typischerweise 4k oder mehr). D.h. ein Cluster kann, obwohl die Stripe-Größe ein ganzzahliges Vielfaches der Cluster-Größe ist, in 0,5k-Schritten die Stripe-Grenze überschreiten. Der genannte Overhead bedingt dann, dass der auf Anweisung des Dateisystems geschriebenen Cluster-Overhead die Neuberechnung von Sektor-Paritäten auch für unterschiedliche Platten zur Folge haben kann.
- Bei kleinen Platten-Zahlen (und schlechtem Caching, wie bei Softraids) fällt dann besonders ins Gewicht, dass (im Idealfall) eben nur linear über die Nettokapazität des Stripe-Sets geschrieben werden kann, in deinem Fall 3x128k. Darüber hinaus muss auf die Bereitschaft der "fiktiven fünften" = ersten Platte gewartet werden.
- Dies nur im Idealfall, denn es kommt auf die konkrete Implementierung an: Bei einem linearen Schreibvorgang von genau 384k auf ein 4-Platten-RAID5 mit 128k-Stripes wäre (korrektes Cluster-Alignment vorausgesetzt) die Berechnung der Parität über 3x128k und das lineare Schreiben in genau ein Stripe-Set ideal, also 4x128k auf vier Platten (nahezu) gleichzeitig. Ein RAID ist aber grundsätzlich für Full-Stripe-Writes optimiert, weshalb für den Schreibvorgang nur auf die jeweilige Nutzdaten- und die Paritäts-Platte zugegriffen wird. Es wird ein Nutzdaten-Delta berechnet, das auf die Parität angewendet wird, um die neue Parität zu erhalten. Das sequenziell für drei Nutzdaten-Stripes zu machen, wäre ineffizient, weil dreimal die Parität geändert würde. Ein Kompromiss unter Beibehaltung dieser Berechnungsweise ist, lineare Schreibvorgänge bei Überschreiten der Stripe-Größe in unterschiedliche Stripe-Sets zu verteilen. Das kann bei geringer Anzahl der Platten aber nur bedingt helfen, weil die Paritätsplatten der jeweiligen Stripe-Sets innerhalb des RAIDs rotieren. Die gleichzeitig beschreibbaren Stripe-Sets bzw. Nutzdaten-Paritäts-Paare sind je nach Plattenzahl unterschiedlich: Bei vier Platten kann mit Platte 1 (Parität auf 4) nicht das darauf folgende Stripe-Set auf Platte 2 bearbeitet werden, weil dessen Parität auf der Platte 1 liegt, sondern nur Platten 3-2. Die Frage ist, ob die Implementierung das variiert oder den Performance-Einbruch in ungünstigen Konstellationen in Kauf nimmt.
Grüße
Richard
vor der Erklärung wollte ich mich nicht ohne Grund drücken. Auf deine Nachricht hin versuche ich es mal:
Das hängt damit zusammen, dass ein Dateisystem auf das RAID-Volume immer in seiner jeweiligen Cluster-Größer von 4k, 8k, 16k usw. schreibt. Der Controller hingegen adressiert Sektoren von typischweise 0,5k Größe (in deinem Fall Advanced-Format) und berechnet auf dieser Ebene auch die Parität bei einem Schreibvorgang.
Die Frage führt häufig zu "kontroversen" Diskussionen, weil der Befund in vielen Fällen eindeutig ist, in vielen aber auch nicht, vgl. hier: http://serverfault.com/questions/365903/why-does-raid5-with-an-odd-numb ...
Dabei ist ein üblicher Denkfehler, dass natürlich nicht die Anzahl der Platten die Allokation der Cluster auf einzelnen Stripes bestimmt. Eine Datenmenge x wird nicht zuerst durch die Anzahl der Platten geteilt und dann geschrieben, sondern die Stripes werden "gefüllt".
Der Zusammenhang mit der Anzahl der Platten ergibt sich vielmehr indirekt aus dem Zusammenhang von Cluster- und Sektorgröße. Wenn sich Cluster nicht durch ein ganzzahliges Vielfaches der Netto-Plattenzahl auf Sektoren aufteilen lassen, entsteht bei Schreibvorgängen, die größer als ein Stripe sind, also Nutzdaten-Stripes auf mindestens zwei Platten und das Parity-Stripe auf einer dritten Platte betreffen, ein zusätzlicher Overhead bei der Neuberechnung der Parität eigentlich nicht geänderter Sektoren, der statistisch umso relevanter ist, je größer die Abweichung tatsächlicher Schreibgrößen vom Vielfachen einer Cluster-Größe ist. Oder anders: der unvermeidliche Cluster-Overhead ist im Allgemeinen günstiger allokiert, wenn die Netto-Plattenzahl ganzzahlig mit dem Verhältnis von Cluster- zu Sektor-Größe zusammenhängt. Da beide Größen eine Zweierpotenz sind, ist ihr Verhältnis auch eine, ist die ideale Plattenzahl eine Zweierpotenz plus Paritätsaufwand.
Der Effekt kann zudem unterschiedlich verstärkt werden, abhängig von mehreren zusammenhängenden Faktoren:
- Da der RAID-Controller eine logische Sektorgröße von ebenfalls 0,5k abbildet, ist das Alignment der darauf erstellten Partition granularer als die Cluster-Größe (typischerweise 4k oder mehr). D.h. ein Cluster kann, obwohl die Stripe-Größe ein ganzzahliges Vielfaches der Cluster-Größe ist, in 0,5k-Schritten die Stripe-Grenze überschreiten. Der genannte Overhead bedingt dann, dass der auf Anweisung des Dateisystems geschriebenen Cluster-Overhead die Neuberechnung von Sektor-Paritäten auch für unterschiedliche Platten zur Folge haben kann.
- Bei kleinen Platten-Zahlen (und schlechtem Caching, wie bei Softraids) fällt dann besonders ins Gewicht, dass (im Idealfall) eben nur linear über die Nettokapazität des Stripe-Sets geschrieben werden kann, in deinem Fall 3x128k. Darüber hinaus muss auf die Bereitschaft der "fiktiven fünften" = ersten Platte gewartet werden.
- Dies nur im Idealfall, denn es kommt auf die konkrete Implementierung an: Bei einem linearen Schreibvorgang von genau 384k auf ein 4-Platten-RAID5 mit 128k-Stripes wäre (korrektes Cluster-Alignment vorausgesetzt) die Berechnung der Parität über 3x128k und das lineare Schreiben in genau ein Stripe-Set ideal, also 4x128k auf vier Platten (nahezu) gleichzeitig. Ein RAID ist aber grundsätzlich für Full-Stripe-Writes optimiert, weshalb für den Schreibvorgang nur auf die jeweilige Nutzdaten- und die Paritäts-Platte zugegriffen wird. Es wird ein Nutzdaten-Delta berechnet, das auf die Parität angewendet wird, um die neue Parität zu erhalten. Das sequenziell für drei Nutzdaten-Stripes zu machen, wäre ineffizient, weil dreimal die Parität geändert würde. Ein Kompromiss unter Beibehaltung dieser Berechnungsweise ist, lineare Schreibvorgänge bei Überschreiten der Stripe-Größe in unterschiedliche Stripe-Sets zu verteilen. Das kann bei geringer Anzahl der Platten aber nur bedingt helfen, weil die Paritätsplatten der jeweiligen Stripe-Sets innerhalb des RAIDs rotieren. Die gleichzeitig beschreibbaren Stripe-Sets bzw. Nutzdaten-Paritäts-Paare sind je nach Plattenzahl unterschiedlich: Bei vier Platten kann mit Platte 1 (Parität auf 4) nicht das darauf folgende Stripe-Set auf Platte 2 bearbeitet werden, weil dessen Parität auf der Platte 1 liegt, sondern nur Platten 3-2. Die Frage ist, ob die Implementierung das variiert oder den Performance-Einbruch in ungünstigen Konstellationen in Kauf nimmt.
Grüße
Richard
Hallo Richard, vielen Dank für die Erklärung. Auch wenn ich sie nur ansatzweise wirklich verstehe, weil mir die technischen Grundlagen fehlen, habe ich trotzdem das befriedigende Gefühl, dass es hier einen niedergeschriebenen und nachvollziehbaren Grund für das Versagen meines 4-Platten-RAID-5-Verbundes gibt.
Wäre es nach deinen Informationen richtig, wenn man konklusiv folgendes behaupten würde?
“Ein schreibintensives RAID 5 sollte immer mit einer ungeraden Anzahl von Platten aufgebaut werden.“
Ich danke Dir sehr für deine ausführliche Erklärung! Vielen Dank!
Wäre es nach deinen Informationen richtig, wenn man konklusiv folgendes behaupten würde?
“Ein schreibintensives RAID 5 sollte immer mit einer ungeraden Anzahl von Platten aufgebaut werden.“
Ich danke Dir sehr für deine ausführliche Erklärung! Vielen Dank!
Die genaue ideale Anzahl wäre (n^2)+1 (bzw +2 für RAID6). Da bis zehn Platten sieben Platten die einzige ungerade Konfiguration ist, welche die genaue Regel verletzt, und das schon relativ viele Platten sind (also der Effekt relativ gering ausfällt), kann man der Einfachheit halber von ungeraden Zahlen ausgehen.
