Niedriger Datendurchsatz mit GigaBit Ethernet

[MSfree]

Als Cat5e wurde auch noch haufenweise ungeschirmtes Zeug als Verlegekabel verkauft.

Das ist aber ein böser Fehler, den ein entsprechend ausgebildeter Techniker nicht machen sollte. Ungeschirmt nimmt man eigentlich nur zwischen Rechner und RJ45-Steckdose und am Patchfeld und selbst da gibt es geschrimte Kabel, die kaum teurer sind als ungeschirmte.

Wand- und Bodenleitungen sind bei uns bisher immer geschirmt verlegt worden und dann reicht Cat5e für GBit problemlos. Klar, was heute neu verkabelt wird, macht man nicht mehr mit Cat5, es lohnt sich nicht, wegen ein paar Cent pro Meter das billigere Kabel zu verwenden.

[pascalts]

Als Cat5e wurde auch noch haufenweise ungeschirmtes Zeug als Verlegekabel verkauft.

Das ist aber ein böser Fehler, den ein entsprechend ausgebildeter Techniker nicht machen sollte. Ungeschirmt nimmt man eigentlich nur zwischen Rechner und RJ45-Steckdose und am Patchfeld und selbst da gibt es geschrimte Kabel, die kaum teurer sind als ungeschirmte.

Wand- und Bodenleitungen sind bei uns bisher immer geschirmt verlegt worden und dann reicht Cat5e für GBit problemlos. Klar, was heute neu verkabelt wird, macht man nicht mehr mit Cat5, es lohnt sich nicht, wegen ein paar Cent pro Meter das billigere Kabel zu verwenden.

Back to Topic bitte. Das hilft exakt nichts bei meinem Problem - wie per iperf gezeigt wurde ist die Netzwerkperformance in Ordnung.

[ThorstenS]

Probier doch mal spaßeshalber die Datei local.conf anzulegen und diese Einstellungen über den angegebenen sysctl Aufruf zu aktivieren. Danach testest du nochmal und gibst feedback.

Code: Alles auswählen

# cat /etc/sysctl.d/local.conf 

net.core.rmem_max=1677721600
net.core.rmem_default=167772160
net.core.wmem_max=1677721600
net.core.wmem_default=167772160
net.core.optmem_max= 2048000
net.ipv4.tcp_rmem= 1024000 8738000 1677721600
net.ipv4.tcp_wmem= 1024000 8738000 1677721600
net.ipv4.tcp_mem= 1024000 8738000 1677721600
net.ipv4.udp_mem= 1024000 8738000 1677721600

# sysctl -p /etc/sysctl.d/local.conf

[NAB]

hdparm -tT --direct /dev/sdb
/dev/sdb:
Timing O_DIRECT cached reads: 160 MB in 2.02 seconds = 79.29 MB/sec
Timing O_DIRECT disk reads: 264 MB in 3.00 seconds = 87.87 MB/sec

Ja, was ist das denn? Das Lesen aus dem Cache ist langsamer als das Lesen direkt von der Platte? Das sollte eigentlich anders herum sein.

Ich würd mir erst mal die Performance des "Datengrabes" bei echten Dateioperationen angucken. 65 MB/s ist ja nun nicht so weit von 80 MB/s entfernt.

[schwedenmann]

Hallo

@pascalts

933Mbit/s sollten ja ca 125 MByte/s sein - das ist um Welten entfernt von 60MB/s.

Das ist doch blos der max. theoretische wert sein, den erreichst du mit nfs und/oder smb doch eh nie


@pascalts

Back to Topic bitte. Das hilft exakt nichts bei meinem Problem - wie per iperf gezeigt wurde ist die Netzwerkperformance in Ordnung.

Theoretisch, vllt. Dann verrat uns doch mal von welchem Gerät (mit welchen phys. Daten incl. Dateisystem) du verschiedene Dateien von A nach B schickst.Ich habe hier auch einen Rechner, per gigabyte angeschlossen (IntelPro1000) und bei rsync+ssh erreicht die Datenrate max. 12MB/s


mfg
schwedenmann

[pascalts]

hdparm -tT --direct /dev/sdb
/dev/sdb:
Timing O_DIRECT cached reads: 160 MB in 2.02 seconds = 79.29 MB/sec
Timing O_DIRECT disk reads: 264 MB in 3.00 seconds = 87.87 MB/sec

Ja, was ist das denn? Das Lesen aus dem Cache ist langsamer als das Lesen direkt von der Platte? Das sollte eigentlich anders herum sein.

Ich würd mir erst mal die Performance des "Datengrabes" bei echten Dateioperationen angucken. 65 MB/s ist ja nun nicht so weit von 80 MB/s entfernt.

Habe doch den Parameter "--direct" angegeben... Da wird der Cahce umgangen.

[NAB]

Du hast den Parameter "-T" angegeben ... da wird aus dem Cache gelesen.

[pascalts]

Du hast den Parameter "-T" angegeben ... da wird aus dem Cache gelesen.

Japp - war von mir etwas ungünstug formuliert. ich zitiere mal aus dem Ubuntu Wiki:

Test 2 ohne Cache
Der zweite Test nutzt ebenfalls die beiden Optionen -t und -T, setzt dazu aber noch die Option --direct („Use O_DIRECT to bypass page cache for timings“), was zum direkten Lesen unter Umgehung des Page Caches führt. In der Regel nutzt man den zweiten Test, da dieser nur den Datenfluss misst, den die SSD erreicht, um bestimmte Daten in zwei respektive drei Sekunden zu lesen. Der Befehl in einem Terminal [1] mit Root-Rechten [2] dazu lautet:

sudo hdparm -tT --direct /dev/sda

Quelle: https://wiki.ubuntuusers.de/Festplatten ... ohne-Cache

[pascalts]

Probier doch mal spaßeshalber die Datei local.conf anzulegen und diese Einstellungen über den angegebenen sysctl Aufruf zu aktivieren. Danach testest du nochmal und gibst feedback.

Code: Alles auswählen

# cat /etc/sysctl.d/local.conf 

net.core.rmem_max=1677721600
net.core.rmem_default=167772160
net.core.wmem_max=1677721600
net.core.wmem_default=167772160
net.core.optmem_max= 2048000
net.ipv4.tcp_rmem= 1024000 8738000 1677721600
net.ipv4.tcp_wmem= 1024000 8738000 1677721600
net.ipv4.tcp_mem= 1024000 8738000 1677721600
net.ipv4.udp_mem= 1024000 8738000 1677721600

# sysctl -p /etc/sysctl.d/local.conf

hab grad ausprobiert... bringt exakt... Nix. Im Gegenteil. Jetzt sind es nur noch 39MB/S Wie nehme ich den Eintrag raus? Einfach Datei löschen?

[r4pt0r]

Verrate uns doch mal die groben Eckdaten des Systems (CPU, RAM). Wenn das ne alte singlecore-Möhre mit 2GB RAM, PCIe 1.0 und SATA1 ist, wird man damit niemals nen GBit-Link auslasten können.

So langsam scheint es nämlich als würden hier mehrere Probleme zusammenzutreffen. Wenn diese Werte tatsächlich von ner SSD sein sollen und das System halbwegs aktuell/performant ist (RAM!!!), ist da auch noch ganz gewaltig am Storagesystem was faul - Controller, Kabel, Platte...

Hier mal Werte von ner billigen Intel 535:

Code: Alles auswählen

# hdparm -tT --direct /dev/sde

/dev/sde:
 Timing O_DIRECT cached reads:   970 MB in  2.00 seconds = 484.22 MB/sec
 Timing O_DIRECT disk reads: 1362 MB in  3.00 seconds = 453.86 MB/sec

Selbst die langsame WD green 5400rpm Platte packt noch mehr als die Platte in deinem datengrab:

Code: Alles auswählen

# hdparm -tT --direct /dev/sdd

/dev/sdd:
 Timing O_DIRECT cached reads:   500 MB in  2.00 seconds = 249.67 MB/sec
 Timing O_DIRECT disk reads: 322 MB in  3.00 seconds = 107.32 MB/sec

Verursacht was anderes noch hohe IOPS oder Bandbreite an den Platten? Swapt das system vll ständig?
iotop kann vll schon ein paar Hinweise geben.
Kommt LVM zum Einsatz? Evtl ein etwas älterer Pool, am besten schon mit mehreren ersetzten/hinzugefügten PVs? LVM fragmentiert leider über die Zeit ziemlich extrem. Nach ein Paar jahren ist ein Pool hoffnungslos lahm. Ein trace mit perf (block:block_rq_insert) kann hier aufschluss geben, wenn der lvm-scheduler nicht sowieso in iotop schon negativ auffällt.
Solange der Storage (oder das gesamtsystem?) nicht vernünftig flott läuft, kann man die Netzwerkperformance erstmal ausser acht lassen.

[wanne]

Kann definitiv sagen dass ich mehrfach ähnliche Probleme hatte und die beiden Protokolle seither einfach meide.
sshfs ist zwar verschlüsselt (Kann man aber auch abschalten oder auf RC4 setzen.) aber liefert bei mir zuverlässig deutlich mehr Durchsatz.
FTP ist zum konfigurieren teilweise recht unangenehm aber für öffentliche Daten und kompliziertere Setups immer noch mein Favorit. (Mangels alternative.)
Sonst kannst du dir mal die Cluster Dateisysteme angucken. Sind eigentlich für etwas anderes gedacht, lassen sich aber als NFS Ersatz missbrauchen und sind so ziemlich an der Spitze, was Performance angeht.

[pascalts]

Okay, hier kommt vllt tatsächlich der Knackpunkt. Das System ist gelinde gesagt, alt.

• Mainboard: Intel D945GCLF2
• CPU: Atom 330 mit 2x1,6GHz + Hyperthreading
• RAM: 4GB DDR2 667 MHz (ist noch nie halb voll gewesen...)
• SATA 2 (SSD, aber eigentlich nur fürs booten und das System, SWAP)
• Per PCI-Erweiterungskarte für SATA 2 hängt die Datenschleuder dran: Toshiba X300

Ich verstehe aber ehrlich gesagt immer noch nicht, warum ich, wenn ich von SSD zu SSD kopiere, die schneller als die Gbit-Verbindung sind (170MS/s > 1 Gbit/s), nicht die Gbit erreiche, obwohl ich den Gbit per iperf erreiche! CPU langweilt sich bei Sambazugriffen bei ca 20% (EINES Kerns) - RAM stört das auch nicht... Wo ist also der Flaschenhals!?

Laut iotop macht das System vorher und hinterher exakt: nix.

Kein LVM

[NAB]

Japp - war von mir etwas ungünstug formuliert. ich zitiere mal aus dem Ubuntu Wiki:

Stimmt, du hast Recht ... ich hab nur in die man-page geguckt, und da liest es sich so, dass sich "--direct" nur auf "-t" auswirkt und nicht auf "-T". Aber ich hab's grad mal bei mir ausprobiert, und die Kombination aus "-T" und "--direct" liefert miserable Werte, warum auch immer.

Trotzdem sind 87 MB/s rohe Lesegeschwindigkeit nicht gerade berauschend ... aktuelle HDDs kommen auf über 100. Und wenn da noch der Dateisystem-Overhead dazukommt und gar noch andere parallele Zugriffe, dann kann die Geschwindigkeit locker auf 40 MB/s fallen und du stehst mit deinen 67 MB/s noch ganz gut da.

Wobei mir die Werte auch bei mir komisch vorkommen:

Code: Alles auswählen

# hdparm --direct -tT /dev/sda

/dev/sda:
 Timing O_DIRECT cached reads:   380 MB in  2.01 seconds = 189.44 MB/sec
 Timing O_DIRECT disk reads: 296 MB in  3.33 seconds =  88.94 MB/sec
# hdparm --direct -tT /dev/sda1

/dev/sda1:
 Timing O_DIRECT cached reads:   396 MB in  2.01 seconds = 197.00 MB/sec
 Timing O_DIRECT disk reads: 190 MB in  0.38 seconds = 498.48 MB/sec
# hdparm --direct -tT /dev/sda

/dev/sda:
 Timing O_DIRECT cached reads:   386 MB in  2.00 seconds = 192.98 MB/sec
 Timing O_DIRECT disk reads: 340 MB in  3.07 seconds = 110.88 MB/sec

# hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   19120 MB in  2.00 seconds = 9566.89 MB/sec
 Timing buffered disk reads: 388 MB in  3.00 seconds = 129.22 MB/sec
# hdparm -tT /dev/sda1

/dev/sda1:
 Timing cached reads:   20308 MB in  2.00 seconds = 10161.80 MB/sec
 Timing buffered disk reads: 190 MB in  0.38 seconds = 505.66 MB/sec
# hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   16750 MB in  2.00 seconds = 8380.37 MB/sec
 Timing buffered disk reads: 468 MB in  3.01 seconds = 155.60 MB/sec

Welch ein Durcheinander (direkt nacheinander ausgeführt auf ner SSD)

Du solltest echte Tests auf dem echten Dateisystem durchführen.

Nebenbei ... Atom und Sata3? Hat der überhaupt die nötig schnellen PCIe-Lanes, um das zu versorgen? Ich würd mir den Sata3-Controller und die X300 mal näher angucken. Deine SSD scheint auch eher auf Sata1 zu laufen.

[pascalts]

Okay, wir kommen der Sache näher: Meine (neu gekaufte) SATA Karte ist nicht das, was der Verkäufer angab. Beworben wurde ein SiI 3124 Chipsatz. Laut lspci habe ich aber einen SiI 3114 Chipsatz. Das ist SATA I

Ob der Atom genug PCI Lanes hat weiß ich nicht - da steck ich nicht drin. Was ich aber sagen kann, ist das alles nur per SATA I genutzt wird:

Code: Alles auswählen

 grep -i SATA /var/log/messages | grep 'link up'
Jun 23 17:44:43 datenschleuder kernel: [    1.524068] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Jun 23 17:44:43 datenschleuder kernel: [    2.180080] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Jun 23 17:44:43 datenschleuder kernel: [    3.228069] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 310)

Das ist ganz ehrlich frustrierend. Ich werde die Karte reklamieren.

Bleibt noch die SSD. Die taucht hier glaube gar nicht auf... ata3, ata5 und ata6 sind jene, die an der PCI-Karte sind. --- denke ich . kann man nachvollziehen, welches ataX welches /dev/sdX ist?

Unabhängig davon: SATA I sollte 1,2Gbit/s sein. Ich hab Ethernet mit 1GB/s - warum ist SATA I dann der Flaschenhals?

Okay... Jetzt kommt es:

Code: Alles auswählen

 lspci | grep SATA
00:1f.2 IDE interface: Intel Corporation NM10/ICH7 Family SATA Controller [IDE mode] (rev 01)
04:00.0 RAID bus controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02)

Das klingt danach, dass meine SSD im IDE-Modus angesprochen wird Im BIOS steht aber SATA oder Legacy und ich hab mich für SATA entschieden... Was da los?

[NAB]

Upps? Ist das noch eine alte PCI-Karte?

PCI macht bei gutem Wetter und Rückenwind brutto so 266MB/s:
https://de.wikipedia.org/wiki/Periphera ... terconnect
Das reicht dann, um einen Sata1-Anschluss zu bedienen. Du hast vier ... mit drei HDDs dran.

Mit der Karte bist du eigentlich gut bedient ... mehr ist da nicht rauszuholen.

Das Problem mit dem ICH7 sehe ich auch zum ersten mal, aber der scheint in der Tat kein AHCI zu können:
https://forum.ubuntuusers.de/topic/ich7 ... r-ignorie/

Ich vermute mal, dass es DEN Flaschenhals nicht gibt, aber insgesamt ist das System nicht gerade auf Hochleistung ausgelegt. Das fängt ja schon bei recht lauen Übertragungsraten der HDDs an.

Ich weiß noch, wie ich mir ne SSD in meinen Atom geschraubt habe, ihn eingeschaltet habe und gebannt auf ungeahnte Geschwindigkeitsräusche gewartet habe ... gewartet habe ich in der Tat, das Ding war kaum schneller als vorher ...

[pascalts]

Also...

Ich habe die wichtige Festplatte, welche hohen Datendurchsatz braucht jetzt an einen der internen SATA (II) Ports geklemmt. Nun erreiche ich ca 200MB/s per hdparm. Das ist ok. Die Datenrate per SAMBA hat sich dadurch auf ca 57MB/s erhöht. Besser also. Macht aber immer noch eine Differenz von ca 68MB/s zu 1Gb/s die für mich unerklärlich ist, da die 1Gb/s ja anliegen (nachgewisener Weise) und die HDD schneller ist (nachgewisener Weise). NFS hat kanpp 70MB/s.

Ich werde das System jetzt so lassen, da meine meisten Datenstreams nur so 20 bis 25 MB/s haben, die Verbindung somit ausreicht. Cool wäre eine Verbesserung trotzdem, da meine (gezippten) Backups so schneller vonstatten gehen würden (Backup: Host baut eine ZIP-Datei und schmeißt diese On-The-Fly per SSH auf den Server).

[NAB]

Greift noch irgendwas parallel auf die HDD zu? Und welches Dateisystem verwendest du denn?

Die Geschwindigkeit von Samba hängt auch von der anderen Seite ab ... der Dateimanager von KDE halbiert mir z.B. die Übertragungsrate auf 50MB/s, während Windows locker 100 hinlegt.

Und du könntest mal versuchen, was über die Verschaltung deines Mainboards herauszubekommen ... wenn ich mich recht entsinne, waren die alten Atoms ausgesprochen knapp an PCIe-Leitungen ... und wenn an einer Leitung USB, Soundkarte, LAN und Sata-Controller hängen, dann könnte es etwas eng werden.

[DeletedUserReAsG]

Wieviel RAM steht denn zur Verfügung, und um welche Datenmengen geht es? Wenn viel RAM und nicht soo viel Daten, könnte man vielleicht was Nettes mit tmpfs als Cache basteln, so dass die Daten erstmal fix rübergeschoben werden, und dann in Ruhe weggeschrieben werden können. Ist natürlich ungeschickt, wenn Strom ausfällt während noch nicht alles weggeschrieben wurde. Aber auch den Punkt kann man ja testen und bei Bedarf den Transfer nochmal anschubsen.

[pascalts]

Also laut iotop nutzt nix die Platte (außer Samba). Alles frei für Samba/NFS.



Habe 4GB RAM... aber da meine Daten meist so 20 bis 30 GB groß (eine Große Datei, nicht viele kleine) sind wird ein tmpf nix bringen, oder?

KDE? Wer nutzt denn schon eine GUI? Nein im Ernst, ich habe auf meinem Datenserver keine grafische Oberfläche installiert. Oder meinst du auf dem "client"? Da rennt ein Arch Linux (jaaaaa, kein Debian, aber man Probiert sich halt aus) mit KDE 5. Aber da die Datenrate unter Windows gleich ist... Kann es daran nicht liegen, denke ich.

Das mit dem Mainboard kann ich machen. Audio brauch ich eh nicht. USB auch nicht. Test folgt.

[reox]

Nun erreiche ich ca 200MB/s per hdparm. Das ist ok. Die Datenrate per SAMBA hat sich dadurch auf ca 57MB/s erhöht. Besser also. Macht aber immer noch eine Differenz von ca 68MB/s zu 1Gb/s die für mich unerklärlich ist

Schneller wirds vermutlich nicht gehen. Siehe zb auch hier: viewtopic.php?f=30&t=159991&start=15

Samba ist ziemlich langsam, im Vergleich dazu kannst du mal probieren dateien direkt mit netcat auszutauschen. Zwischen zwei Thinkpads mit SSD und Gigabit kam ich mal so auf 110MB/s. Also 60MB/s bei Samba halte ich für einen guten wert.
Wenn du es schaffst die smb.conf so zu tweaken, dass es schneller wird: her damit!

[Lord_Carlos]

Warum schaffen dann andere seit jahren 110MB/s mit samba?

[reox]

Warum schaffen dann andere seit jahren 110MB/s mit samba?

Kannst du mal links zu config und Hardware Posten?
Meine platten schaffen das locker nur samba bekommen ich deshalb auch nicht schneller...

[Lord_Carlos]

Warum schaffen dann andere seit jahren 110MB/s mit samba?

Kannst du mal links zu config und Hardware Posten?
Meine platten schaffen das locker nur samba bekommen ich deshalb auch nicht schneller...

Ich habe nichts and er Config geaendert, auser Freigaben hinzugefuegt.
Server ist mein ~6 Jahre alter Rechner.*

Gerade nochmal getestet, bekomme ~93MB/s:


Ich vermute das die Festplatte (Raid 5 mit alten platten) da schlapp macht. Wenn ich die gleich datei nochmal lade geht es flotter:



Frueher, so vor ~4 Jahren ging auch direkt 110 MB/s auf dem gleichen Rechner. Vielleicht macht das Raid langsam schlapp.


Edit:
Ah ja, wenn ich etwas von /dev/shm kopiere geht es von Anfang an durchgehend mit ~113 MB/s
Das Protokoll nutzt also die volle Bandbreite von Gigabit Ethernet aus.


Der server:
OS: Debian stable
CPU: AMD Phenom(tm) 9950 Quad-Core Processor (4x 2.6Ghz)
Ram: 8GB
HDD: 5x 1.5TB zum Raid 5, verschluesselt.

[wanne]

Kumpel von mier schafft das definitiv. Der hat aber glaube ich auch ne weile dran rumgetuned. (Kann mal fragen, was er so gemacht hat.)
Das Ding ist aber eigentlich auch auf 10G ausgelegt. Nur kann der Laptop halt nur 1G.

[reox]

mhh also ich versteh das nicht: Ich hab jetzt ein LVM auf 5 PV's verteilt erstellt, damit bekomme ich 190MB/s lesen und 166MB/s schreiben hin. Über Samba bekomme ich trotzdem nur 45MB/s lesend (Schreibrate grad mal 800kB/s oO). Ich verwende dafür gvfs am client.
Der Samba server kommt auf 50% CPU auslastung beim smbd (AMD Turion(tm) II Neo N54L).
Wenn ich die config auf debian default setze komm ich auf 56MB/s lesend (komisch, sonst wars immer anders herum), der smbd nur noch auf 30% CPU

Im Vergleich dazu mit NFS: 111MB/s lesen und 69MB/s schreiben.

Vielleicht liegts an gvfs, aber schneller als 60MB/s gehts bei mir einfach nicht...