Server lesen/schreiben unterschiedliche Geschwindigkeit

[vollautom]

Hallo,
habe mir einen Debian Server mit einer Samba freigabe eingerichtet.
Wenn ich nun Daten vom Server lese habe ich eine Geschwindigkeit von 8-10 Mbit.
Beim Schreiben aber bekomme ich zwischen 25-30 Mbit.
Ist das Normal? oder woran kann das liegen?

Gruß

 

[Der Netzzwerg]

Naja, deine Schreibraten sind aber auch nicht gerade sehr berauschend .

Das Problem liegt soweit ich mich erinnern kann bei Debian bzw. dem verwendeten Treibermodul für einige Netzwerkkarten (besonders Realtek und andere günstige Anbieter) in Kombination mit Samba. Man hört aber auch manchmal von Problemen mit Intel-NICs. Das Problem betrifft komischerweise nur Samba, andere Protokolle wie z.B. FTP laufen mit "Fullspeed", du kannst das ja mal testen.
Ich habe mich diesbezüglich auch lange Zeit mit Debian rumgeärgert, bis ich dann auf Ubuntu umgestiegen bin. Seitdem hatte ich nie mehr Probleme mit der Samba-Netzwerk-Performance. Schleierhaft ist mir das Ganze aber trotzdem, zumal Ubuntu auf Debian basiert. Ich vermutete früher ja immer, dass die alte Kernel-Version von Debian (stable) dafür verantwortlich war, Debian (testing), das meistens einen ähnlich aktuellen Kernel wie Ubuntu hat, brachte da komischerweise aber auch keine Besserung.

 

[MAFRI]

also ich würde zwar auf die gleiche uhrsache wie mein vorredner schließen - allerdings muss ich hinzufügen - das schreib / leseraten nicht soar nie gleich sind..

im regelfall sollte die lese rate oberhalb der schreibrate liegen..

 

[Der Netzzwerg]

allerdings muss ich hinzufügen - das schreib / leseraten nicht soar nie gleich sind..

im regelfall sollte die lese rate oberhalb der schreibrate liegen..

Naja, bei der Datenübertragung ist es relativ, da eh immer nur so schnell gelesen wird, wie maximal geschrieben werden kann, zumindest direkt von Festplatte zu Festplatte.
In meinem Gigabit-LAN daheim sind die Festplatten der limitierende Faktor, was zusammen mit dem TCP/IP-Overhead in beide Richtungen ~75-80 MB/s ergibt. Du siehst ja, der Ausdruck "beide Richtungen" ist hier irgendwo dämlich, es wird ja immer gelesen und geschrieben (die langsamere Richtung limitiert somit die schnellere), egal in welche Richtung.

Grundsätzlich hast du aber Recht, z.B. wenn ein Programm Daten aus dem Hauptspeicher auf Platte schreibt bzw. von der Platte ausliest, da sind die Leseraten immer flotter.
Die ganzen HDD-Testtools testen ja nur das Szenario Platte - RAM bzw. RAM - Platte, also die theoretisch max. Schreib -und Leseraten der Festplatte, da der RAM hier nicht limitieren kann. Bei Kopiervorgängen von einem Speichermedium zum anderen wird diese Rate ja nur äußerst selten erreicht, außer man verwendet SSDs oder RAID...hier limiitiert dann allerdings schon wieder das Gigabit-LAN .

Der große Unterschied zwischen read/write liegt bei vollautom einzig und allein an der Debian-Samba-Geschichte in Verbindung mit einigen (scheinbar nicht wenigen) Netzwerkkarten.

 

[fdsonne]

Der große Unterschied zwischen read/write liegt bei vollautom einzig und allein an der Debian-Samba-Geschichte in Verbindung mit einigen (scheinbar nicht wenigen) Netzwerkkarten.

Ich kenn jetzt Samba und dessen Zugriff nicht so genau, ebenso wenig wie die Datenverwaltung der Unix Filesysteme...
Aber ich weis zum Beispiel, bei nem sehr belebten Fileserver in ner Windows Umgebung (also wo sehr sehr viel gelesen und auch geschrieben ebenso wie gelöscht wird) fragmentieren die Daten mit der Zeit massiv...

Es kann also durchaus sein, das beim Lesen der Files die "Arme" der HDD wild über die ganze Scheibe wandern müssen um alle Datensegmente aufzusammeln, beim Schreiben aber quasi kontinuierlich hintereinander weg geschrieben wird...
Ein sequenzieller Schreibvorgang wird dabei dann deutlich schneller durchgeführt als der Lesevorgang. (Random Access)

In wie weit Linux/Unix da aber zum Fragmentieren neigt, weis ich nicht genau...

 

[Der Netzzwerg]

Es kann also durchaus sein, das beim Lesen der Files die "Arme" der HDD wild über die ganze Scheibe wandern müssen um alle Datensegmente aufzusammeln, beim Schreiben aber quasi kontinuierlich hintereinander weg geschrieben wird...
Ein sequenzieller Schreibvorgang wird dabei dann deutlich schneller durchgeführt als der Lesevorgang. (Random Access)

Umgekehrt können aber freie Speicherbereiche auch so wild über die Platte verteilt sein, dass beim Schreiben ebenfalls viel rumgewandert werden muss, bis ein freier Platz gefunden wird
Andererseits ist das wieder von der Strategie abhängig, ob einfach gleich geschrieben oder zuerst ein genügend großer Abschnitt gesucht und dann komplett geschrieben wird. Ich vermute eher mal letzteres, passieren kann es aber bei genügend belegtem oder fragmentiertem Speicher trotzdem irgendwann mal.

Man kann es vermutlich am Ende drehen und wenden wie man will, Lesen geschieht in der Regel immer etwas schneller als Schreiben.

Die gängigen Unix/Linux-Dateisysteme fragmentieren schon auch, allerdings lange nicht so stark wie z.B. NTFS oder FAT32. Zudem gibt es bei "normaler" alltäglicher Benutzung kaum Geschwindigkeitseinbußen.
Allerdings muss ich sagen, dass ich auch mit NTFS unter Windows die letzten 1-2 Jahre nicht mehr defragmentiert habe und auch keine großen Performanceeinbrüche zu verzeichnen hatte, das hängt halt immer davon ab, was man auf seiner Kiste mit was für Arten von Daten anstellt.

 

[fdsonne]

Neja ich sag mal so, bei massiver Fragmentierung kommt es häufiger vor, das zu lesende Daten über mehr Fragmente verteilt sind als die Fragmente beim Schreiben...

Aus einem einfachen Grund:
Wärend beim Lesevorgang im Worstcase jede Einheit an einer anderen Stelle der HDD liegt, sprich nach dem Lesen einer Einheit immer der Arm vollständig bewegt werden muss kommt es idR beim Schreiben deutlich häufiger vor, das größere Zusammenhängende freie Bereiche vorgefunden werden, dementsprechend kann auch häufiger sequenziell geschrieben werden, was Performance bringt...

So zumindest meine Erfahrung bei massiv fragmentierten NTFS Filesystemen...
Aber wie gesagt, in wie weit man das auf Linux/Unix übertragen kann --> keine Ahnung.

 

[Der Netzzwerg]

Neja ich sag mal so, bei massiver Fragmentierung kommt es häufiger vor, das zu lesende Daten über mehr Fragmente verteilt sind als die Fragmente beim Schreiben...

Ja natürlich, das bestreite ich auch gar nicht

Ich wollte lediglich ausdrücken, dass das bei Otto-Normal-User/Home-Server eher selten der Fall ist und die Leseraten trotz Fragmentierung in den meisten Fällen höher liegen.
Dein Beispiel mit dem Fileserver ist wohl eher eine Ausnahme bzw. so im Home-Bereich sehr unwahrscheinlich. Man müsste schon sehr sehr viel in der Gegend rumschreiben und löschen, das schafft ein normaler User kaum

Unter Unix/Linux ist dein beschriebenes Verhalten noch sehr viel unwahrscheinlicher, vorallem für den Heimanwender !
Wie gesagt, gängige Unix/Linux-Dateisysteme fragmentieren zwar auch, erstens aber nicht so stark und zweitens bricht die Performance nicht so ein. Das liegt zum einen daran, dass die Allokation von Speicher anders abläuft und zum anderen daran, dass die Fragmentierung mit der Zeit einen gewissen Grad nicht mehr überschreitet. Dieser Grad liegt immer noch deutlich unter dem von beispielsweise NTFS. NTFS dagegen kann immer fröhlich weiterfragmentieren, eine Grenze gibt es da kaum.

So zumindest meine Erfahrung bei massiv fragmentierten NTFS Filesystemen...

Das glaube ich Dir gerne ! Nur stellt sich mir dann die Frage, wieso man (nicht auf Dich bezogen) es erst soweit kommen lässt ?

Was mich interessieren würde:

Du hast ja laut Signatur nen ganzen Haufen Hardware bzw. Speicherplatz. Defragmentierst du regelmäßig oder nur mal so von Zeit zu Zeit bzw. wenn es dir zufällig in den Sinn kommt ?

 

[fdsonne]

Ja schon klar, wollte es halt nur als einen Möglichen Grund erwähnt haben...

 

[Der Netzzwerg]

Ok, dann sind ja alle Klarheiten beseitigt
Kannst du bitte noch auf meine Änderung eingehen, das interessiert mich vorallem für meine Windows-Kiste, die demnächst auch mit weiteren Platten bestückt und als Datenschleuder verwendet wird.
Falls du regelmäßig defragmentierst, machst du das, weil du wirklich nen Unterschied spürst ? Mir persönlich ist ein Performance-Verlust eben noch nie aufgefallen, vermutlich weil mein Nutzungsverhalten ein anderes ist.

 

[fdsonne]

Eins vorweg, ich defragmentiere gar nicht

Aber mir fällt das Teilweise massiv auf...
Ich hab ne INet Kiste rumstehen, kleiner AMD Singlecore S939 mit 1GB Speicher und ner 200GB WD Platte...
Das Teil ist bis auf die HDD unhörbar...

Als das System neu aufgebaut wurde (ca. vor 3 Monaten) wurden alle Files (kleinst Files von unter 1KB bis große Gigabyte Images) händisch auf die HDD geschrieben... Sprich kamen alle auf eine nakte Partition sequenziell drauf.

Da dank dem INet Verkehr recht viel Bewegung in den Files herscht (sprich verschoben, gelöscht, erstellt usw.) fragmentieren die Files zunehmend.

Ich sitze nicht mit der Stoppuhr da und messe jeden Zugriff, aber mir fällt auf, das die HDD bei sequenziellen Zugriffen sogut wie keine Geräusche von sich gibt, hin und wieder mal ein "Zugriffsklackern"
Aber bei fragmentierten Daten, also Files die wild verstreut irgendwo auf der HDD liegen massive Zugriffsgeräusche warzunehmen sind...
Ergo ist es so, das bei sequenziellen Zugriffen durch das quasi fast wegfallen der Zugriffszeit erheblich höhere Performance drin ist, als bei Randon Zugriffen...

Ob das nun am Ende hier mal ein paar Sekunden schneller oder langsamer geht, ist mir persönlich recht egal, aber es fällt halt auf...


Gleiches hab ich das WE auf dem scharfen Fileserver von Arbeit beobachten können...
Es handelt sich um ca. 500GB reine Nutzdaten im kleineren Bereich (sprich wenige KB bis im Schnitt 1-2MB pro File)
Ein sichern auf Fileebene in eine Imagedatei dauerte für alle ca. 1,8Mio Files etwas über einen Tag. (Quell HDDs 6x750GB SATA 7,2k@Raid 5 | Ziel HDDs 3x300GB SAS 15k@Raid 5)
Das Rückspielen in ein neues System (Quell HDDs 3x300GB SAS 15k | Ziel HDDs 4 der 6 SATA HDDs von oben@Raid 5) dauerte nich mal 12h...
Ebenso kopieren auf Dateiebene aber dank des zwischenspeicherns gänzlich ohne Fragmentierung... Bei beiden Kopiervorgängen war keine anderweitige Last auf den Quell/Ziel Platten.

Wobei hier der Fileserver warscheinlich wirklich derart durch das Userverhalten Fragmentiert war, das man dieses Stadium nie als alleiniger Privatuser erreichen würde...
Aber verdeutlicht denke ich ganz gut die Dimensionen...



Wie man es soweit kommen lassen kann?
Ja ganz einfach man brauch nur nen Torrent Client und ne recht große Partition haben und das ganze mal über ein paar Wochen/Monate laufen lassen... gleichzeitig noch die nicht mehr benötigten Quellfiles immer dann löschen, nachdem man sie entpackt hat und auch so recht viel Verkehr mit gepackten Dateien haben...
Da ich durch meine hässliche INet Leistung keine großen Files am Stück ziehen kann, lade ich diverse Linux Distributionen und Co. oft über den TorrentClient. Der kann pausiert werden wenn bedarf besteht und er stückelt das ganze in viele kleine Häppchen.

Da aus Gründen der Dateigröße ja recht viele Files irgendwie gepackt sind, die im Netz so rumgeistern, kommt es da auch bei normaler Nutzung schnell zur Fragmentbildung...
Wenn dann noch aktiv mit Files auf der selben Partition gearbeitet wird, geht das nochmals schneller...