koelner-x
Anmeldungsdatum: 4. August 2008
Beiträge: 15
|
Hallo, ich habe erfolgreich meinen zweiten Fileserver aufgesetzt, diesmal einfach mit Systemverwaltung/Laufwerksverwaltung aus 11 Stück unpartitionierten 1,5TB HDD's ein 15TB Software - Raid5 bauen lassen und mit EXT4 formatiert, noch kurz mdadm.conf und fstab gemäss Wiki angepasst und soweit alles gut. (Betriebssystem liegt auf eigener Platte) Kopiere ich nun von einer esata angebundenen Platte Daten auf das Raid, erreiche ich auch gute Schreibraten, die etwa den max. Leseraten der ext. Platten entsprechen, teilweise über 90MB/sec. 👍 Nun hatte ich ein paar Daten sortiert und wollte wieder welche auslagern. Das Kopieren/Verschieben auf die ext. Platte (gleiche Konfiguration wie beim Daten holen von ext.) erreicht aber nur Transfer-Raten von ca. 37MB/sec. 👿 Ich dachte an ein seltenes Phänomen, wo die Leserate des Raid drastisch schlecht sein könnte, aber ein Lesetest in der Laufwerksverwaltung zeigt Leseraten von ca. 300MB bis 600MB/sec. Als nächstes hatte ich den PCIe - esata Controller im Verdacht, aber ein Test mit Kopieren auf die Systemplatte, die eine sehr hohe Schreibrate von 150MB/sec hat, war genauso langsam ... 😢 Durch die hier stattfindende "Doppelbelastung" der Systemplatte hätte ich ja auch etwa die Hälfte von 70-80MB/sec akzeptiert, aber keine 37MB/sec ... Weiss jemand Rat ? Gruss
Andi (System-Hardware M4N78 PRO, Dual Core 2,8GHZ, 4GB RAM, falls das irgendwie wichtig ist, die CPU langweilt sich die ganze Zeit 😉 auch bei 90MB/sec)
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7657
|
Wenn ich dich richtig verstehe meinst du also, das RAID ist langsam wenn du Dateien davon liest? Und NICHT die eSATA-Platte (Topic) da das bei der (internen?) Systemplatte auch auftritt? Du kannst ja mal ein paar Pseudo-Benchmarks machen für reines lesen: dd if=/dev/md0 of=/dev/null bs=1M count=10000 (liest 10GB - das sollte den besten Wert liefern da null overhead + schnellster Bereich von den Festplatten genutzt wird) dd if=/mnt/raid/testdatei of=/dev/null bs=1M count=10000 (liest 10GB aus einer Datei - wenn du keine so große hast leg halt eine an z.B. mit dem folgenden Befehl) dd if=/dev/urandom of=/mnt/raid/testdatei bs=1M count=10000 Das ist kein richtiger Benchmark - du solltest dazwischen auch mal das RAID neu mounten um Dateisystemcache etc. loszuwerden - aber kann ein Anhaltspunkt sein ob das RAID selbst oder das Dateisystem darauf spinnt. Falls diese Tests alle die gewünschte Geschwindigkeit liefern ist das RAID und das Dateiystem erstmal grundlegend in Ordnung. Dann gibt es andere Möglichkeiten: - Zieldevice/Zieldateisystem ist schuld
- Flaschenhals irgendwo (PCI, Kabel)
- Die Dateien die du kopierst/liest sind sehr stark fragmentiert (passiert z.B. bei Torrents durch den Download in zufälliger Reihenfolge)
- Viel Overhead durch viele kleine Dateien (z.B. Kernel-Sourcen zu kopieren kann verdammt langsam sein...) Schau in jedem Fall auch mal in /proc/mdstat, wenn das RAID z.B. noch am Synchronisieren ist oder wenn eine Festplatte rausgefallen ist, wäre das auch ein Grund...
|
agaida
Anmeldungsdatum: 24. Februar 2010
Beiträge: 3348
Wohnort: Bielefeld
|
Kreative Anwendung von Hardware und Wissen über die Arbeitsweise einer Platte könnten helfen. 37Ms auf eine einzelne Spindel ist doch gar nicht mal so schlecht. Das kann man aber noch ein wenig tunen. Mounte die externe Platte vernünftig, das heisst eher, mounte sie wie ein echter Kamikaze: mount -o noatime,nodiratime,data=writeback,commit=20000,barrier=0 /dev/disk/by-label/extern /extern Schief gehen kann dabei eigentlich nichts, bei einem Stromausfall, der diesen Transfer beeinflussen könnte, hättest Du ein anderes Problem. Dauerhaft sollte man natürlich so nicht arbeiten. Ein wenig Tuning mit hdparm und sdparm schadet vielleicht auch nicht. Wenn das nicht reichen sollte, schreib das Zeug vorher in einen Tarball und pack den auf die externe Platte. Dann schreibt der ein File und muss nicht mit Einzelfiles rumfuddeln. So gesehen war die von Dir erreichte Geschwindigkeit doch noch schnell 😉 - Wenn das alles nicht reicht, solltest Du das Zeug auf eine Transport-SSD passender Größe (letzter Bauart) auslagern. Dann hast Du fast die volle Lesegeschwindigkeit des Raids auch beim Auslasten. Das von Dir beobachtete Phenomen ist übrigens altbekannt. Mehr Spindeln - Mehr Leistung. Lesen können fast alle Platten schnell, Schreiben dauert etwas länger, grad bei vielen kleinen Files. Der muss die Daten wegschreiben, umpositionieren, Belegungen schreiben, umpositionieren ... . Da hat bei mechanisch ein Redundant Array of Ind. Dev. natürlich die Nase vorne.
|
koelner-x
(Themenstarter)
Anmeldungsdatum: 4. August 2008
Beiträge: 15
|
Danke schonmal für die Ideen, aber ich habe inzwischen die SATA-Treiber von ubuntu im Verdacht ... Warum dieses ... Da ich die Systemplatte erst mit WXP und dann erst mit ubuntu bestückt habe, bin ich in der glücklichen Lage, nur durch Neubooten verschiedene Tests mal in WXP und mal in ubuntu durchzuführen. Ich habe also gerade mit h2testw (ewig danke an die c't 😉 die Systemplatte unter WXP getestet, Schreibrate 146 MB/s, Leserate 151 MB/s. Das gleiche unter ubuntu, h2testw läuft dank wine auch hier, Schreibrate 47 MB/s 😲 👿 , Leserate 150 MB/s, das einzige, was jetzt anders ist, sind die SATA-Treiber. Ein ähnliches Bild für die esata-Platte: WXP Schreiben 80 MB/s, Lesen 80 MB/s, > ubuntu Schreiben 47 MB/s 👿 Definitiv bricht mir die Schreibrate auf eine einzelne SATA Platte in ubuntu drastisch ein ... Wie kriegschn das nu wieder wech ... 😉 ??? Gibt es verschiedene SATA Treiber, die man mal ausprobieren könnte ??? Gruss
Andi
|
koelner-x
(Themenstarter)
Anmeldungsdatum: 4. August 2008
Beiträge: 15
|
btw. Leserate fürs RAID dd if=/dev/md0 of=/dev/null bs=1M count=10000 gibt zurück 10000+0 Datensätze ein 10000+0 Datensätze aus 10485760000 Bytes (10 GB) kopiert, 52,945 s, 198 MB/s 👍 👍 👍
|
agaida
Anmeldungsdatum: 24. Februar 2010
Beiträge: 3348
Wohnort: Bielefeld
|
Das Leben kann hart sein, vergleich doch mal als erstes die mount-defaults der beiden Systeme. Und dann erst mal weiter ausschließen, woran es nicht liegt.
|
stfischr
Anmeldungsdatum: 1. März 2007
Beiträge: 19197
|
Hi. Ich würde wetten, deine Externe ist mit 4K Sektoren und du hast sie nicht richtig partitioniert.
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7657
|
Ein Benchmark der unter Wine läuft ist erstmal nicht aussagekräftig - Wine klaut dir hier die Performanz...
|
koelner-x
(Themenstarter)
Anmeldungsdatum: 4. August 2008
Beiträge: 15
|
Hallo an alle 😉 stfischr schrieb: Hi. Ich würde wetten, deine Externe ist mit 4K Sektoren und du hast sie nicht richtig partitioniert.
Es ist eine 1TB Samsung HD103UJ, die gab es nicht mit 4k Sektoren. Aber dieser Idee bin ich grade mal gefolgt und habe die Partitionierung und Formatierung der externen Platte verändert. Lege ich ein EXT4 auf die externe ("automatisch" in der Laufwerksverwaltung), kann ich mit 100MB/s drauf schreiben, bin dann aber nicht mehr kompatibel zu meinen WXP-Rechnern ... ☹ Lege ich ein Fat32 auf die externe, kann ich mit 100MB/s drauf schreiben, bekomme aber die Fehlermeldung, die Dateien sind zu gross, klar Fat32 kann keine Dateien über 4GB, sie sind aber bis zu 15GB gross (HDTV-Aufnahmen) Lege ich ein NTFS auf die externe, was ja auch drauf war, auch wenn ich die Partition mit Gparted anlege und der erste Sektor auf 2048 liegt, bin ich wieder bei Schreibrate 37MB/s 👿 Ich dachte, Linux kann inzwischen besser mit NTFS umgehen ... ☹ Komm ich aus dieser Sackgasse doch noch irgenwie raus ??? Gruss
Andi
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7657
|
Ah, da haben wir ja die Ursache. Schreibperformanz bei NTFS ist einfach so. Sei froh, daß es überhaupt geht und dir dabei nicht mehr alle Dateien zersägt werden. Auch abgesehen von der Schreibperformanz ist es einfach grausam, von Linux aus auf NTFS zu schreiben. Wenn du nachher dann mal unter Windows eine Defragmentierungssoftware anwirfst, darfst du Schachbrettmuster bewundern. Es scheint, der NTFS Treiber unter Linux schreibt Daten so weit wie möglich voneinander entfernt um ja nicht aus Versehen doch anderen Dateien an den Karren zu fahren. 😉 Wenn du NTFS brauchst, musst du dann einfach damit leben. Alternativ kannst du aber ausprobieren, ob existierende ext2/3 Treiber für Windows, dann mit großen Dateien umgehen können.
|
stfischr
Anmeldungsdatum: 1. März 2007
Beiträge: 19197
|
Ok, das könnte wirklich am NTFS-Treiber liegen, der hat Probleme mit sehr großen Dateien, da sollte dann aber auch die CPU-Auslastung bei 100% sein, wenn es so langsam läuft.
|
koelner-x
(Themenstarter)
Anmeldungsdatum: 4. August 2008
Beiträge: 15
|
stfischr schrieb: Ok, das könnte wirklich am NTFS-Treiber liegen, der hat Probleme mit sehr großen Dateien, da sollte dann aber auch die CPU-Auslastung bei 100% sein, wenn es so langsam läuft.
Die CPU-Auslastung liegt nicht wirklich bei 100%, aber gestern nacht las ich in einem debianforum von einem ähnlichen Problem, und die haben Cool&Quiet ausgeschaltet, dann lief es besser ... Hab ich auch grade gemacht, siehe da, Schreibrate bei 67MB/s, der Dual-Core läuft dann die ganze Zeit auf 2,8Ghz ... Zum Glück ist es eine Black Edition, Takt auf 3Ghz hoch gesetzt, Schreibrate bei 70MB/s, Takt auf 2Ghz runter gesetzt, Schreibrate bei 50MB/s ... 🙄 Die CPU-Auslastung ist aber immer bei etwa 60% ... 😲 Fazit: Der wirklich anstehende CPU-Takt bestimmt massgeblich die NTFS Schreibrate, weil der NTFS-Treiber "eine kleine Ressourcen fressende Sau" ist und nicht mit Cool&Quiet umgehen kann ... 👿 Und für die gewünschte Schreibrate von ca 100MB/s brauch ich wohl 'ne 4Ghz CPU ... ☹ Welcher NTFS-Treiber ist denn im Kernel drinne heutzutage, hat jemand Kontakt zu den Entwicklern ??? Gruss
Andi
|
koelner-x
(Themenstarter)
Anmeldungsdatum: 4. August 2008
Beiträge: 15
|
Hello again 😉 das Problem ist zwar erkannt, aber noch nicht gelöst ... wenn jemand weiterlesen möchte, hier ein weitergehender Denkansatz auf english : http://tuxera.com/forum/viewtopic.php?f=2&t=25420&sid=4fdd9344197ef2f22b490e9ecbcd0aa1 sollte noch jemand eine Idee haben, was man noch testen/ausschliessen könnte, immer her damit 😉 Grüsse Andi
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7657
|
Ich habe leider keine Maschine die ihre Taktraten dynamisch anpasst (bei einer die das könnte hab ich das deaktiviert), aber gibts da nicht einiges zum Auswählen sprich verschiedene Performer von denen manche konservativer andere aggressiver entscheiden ob hochgetaktet werden soll oder nicht? Welchen davon hast du ausgewählt? Vielleicht reichts da ja einfach nur auf den aggressiveren umzuschalten, ich meine, wenn die CPU schneller kann, warum soll sie nicht dürfen? Was die dort im ntfs-3g Forum schreiben macht Sinn, nämlich daß ntfs-3g in der Entscheidung wie getaktet werden soll, eigentlich nicht involviert ist. Bei einem Kernel-Dateisystem könnte man da einen Bug vermuten aber der Witz an dem ntfs-3g ist ja gerade daß es im Userspace per fuse läuft und dementsprechend nichtmal ein Kernelmodul (außer fuse) vorhanden ist, daß dem Kernel da groß was diktieren würde. Außer natürlich ntfs-3g geht speziell ans /proc bzw. entsprechende Syscall-Interface dafür aber das ist dann wieder weit hergeholt... warum sollte es das tun.
|
koelner-x
(Themenstarter)
Anmeldungsdatum: 4. August 2008
Beiträge: 15
|
Ich habe weder was ausgewählt noch was zum Einstellen, ich habe eine Standard Ubuntu Installation auf einem Standard AMD System, welches in der Lage ist per Cool&Quiet Strom und Lärm "zu sparen". Das "Problem" mit C&Q führe ich inzwischen darauf zurück, das die angezeigte Auslastung der CPU von 60% noch nicht dazu ausreicht, die Taktrate automatisch zu erhöhen. Jede andere Anwendung, die ich kenne, "nimmt" sich das an CPU-Leistung, was benötigt wird, solange bis 100% CPU Auslastung bei maximaler Taktrate erreicht sind, erst recht dann wenn keine anderen Prozesse laufen ... Eine Priorisierung wie z.B. nice Wert (was auch nix gehilft hat) usw macht ja erst Sinn, wenn sich mehrere Prozesse eine womöglich nicht ausreichende CPU Leistung teilen müssen. Dies ist hier aber nicht der Fall. Hier geht es darum, dass ein Rechner, der gerade nix weiter zu tun hat, Dateien so schnell wie möglich von einem Ort an den anderen kopieren oder verschieben soll. (macht er aber nicht) Da meine Tests ja nun gezeigt haben, das das System ausreichend dimensioniert ist, also beim schreiben auf ext4 die physikalische maximale Schreibrate der externen Platte auch erreicht werden kann, stellt sich die Frage, warum das beim schreiben auf ntfs nicht möglich sein sollte, gerade weil ja die mögliche maximale Auslastung der CPU noch gar nicht erreicht ist. Selbst wenn man dem ntfs-3g Treiber eine deutliche höhere CPU-Last zugesteht (ungefähr das sechsfache !!!), stellt sich die Frage, warum sich dieser Prozess denn nicht mehr Leistung "nimmt", wo sie doch mehr als ausreichend noch zur Verfügung steht ... Wenn der Prozess das tun würde und 100% CPU Last erreicht wären ohne die maximale Schreibrate der externen Platte zu erreichen, wäre ich ja schon längst im Laden gewesen und hätte mehr Taktrate nachgekauft ... Aber wir sind erst bei 60% CPU Last !!! Auch mit ohne C&Q !!! WARUM ??? Könnte es sein, dass dem "Userspace" per default nicht mehr Leistung zugeteilt wird ??? Kann man das irgendwo einstellen ??? Grüsse Andi (Du willst schnell zum Flughafen, darfst auch 250 km/h auf der Autobahn fahren, aber dein Motormanagement hält 40% deiner 280 PS zurück, es könnte ja sein, das noch jemand die Klimaanlage oder das Radio anschalten will ... )
|