Niedriger Datendurchsatz mit GigaBit Ethernet

[pascalts]

Hallo!
Ich habe ein Debian 8 mit 3.16.0-4-amd64. Die Netzwerkkarte ist

Code: Alles auswählen

01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 02)

Meine Netzwerkconfig sieht so aus:

Code: Alles auswählen

eth0      Link encap:Ethernet  Hardware Adresse 00:1c:c0:d0:17:61
          inet Adresse:192.168.178.37  Bcast:192.168.178.255  Maske:255.255.255.0
          inet6-Adresse: [b]ZENSUR[/b]/64 Gültigkeitsbereich:Global
          inet6-Adresse: [b]ZENSUR[/b]/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:2798020 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6475696 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:1272224980 (1.1 GiB)  TX bytes:9223797459 (8.5 GiB)

lo        Link encap:Lokale Schleife
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:65536  Metrik:1
          RX packets:50 errors:0 dropped:0 overruns:0 frame:0
          TX packets:50 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0
          RX bytes:6317 (6.1 KiB)  TX bytes:6317 (6.1 KiB)

Mein Problem ist, dass ich in jeglichem Netzwerkverkehr durch mein GigaBit Netzwerk (das sonst mit wesentlich höheren Raten arbeitet) nur maximal mit 65MByte/s erreiche (in dem Fall NFS-Zugriff von SSD zu einer SSD, haben intern so 200 bis 300MByte/s per hdparm -tT --direct /dev/sdX). Das Samba nicht so schnell ist war mir klar. Aber sonst erreiche ich in dem Netzwerk bis höhere Datenraten.

Kann mir jemand einen Tipp geben, wie ich das System schneller bekomme?

Code tags eingefügt --wanne

[NAB]

firmware-realtek
iperf

[pascalts]

firmware-realtek
iperf

Firmware-realtek ist installiert und aktuell - hat aber keine Verbesserung gebracht. iperf habe ich mal probiert zum Messen... damit komme ich auf maximal 67MByte/s. Also wie bei NFS in etwa.

[MSfree]

Code: Alles auswählen

ip link set eth0 mtu 9000

[Lord_Carlos]

Das Samba nicht so schnell ist war mir klar.

Samba ha kein problem mit GigaBit, ich erreiche damit seit Jahren ~110MByte/s

[r4pt0r]

Samba ist kein benchmark. Zudem ist der Overhead nicht gerade gering und der Netzwerkstack der involvierten Windowskiste ist auch alles andere als Gigabit-Optimiert (egal welches Windows...)

Welcher Switch wird genutzt? Billigswitches oder gar Fritzboxen/Plastikrouter können nichtmal ansatzweise einen einzelnen GBit-Link sättigen, geschweige denn mehrere.
Realtek-NICs sind auch nicht gerade für ihre hohe Qualität und Leistung berühmt (naja, immerhin besser als Broadcom...). Wenn dann auch noch cat5e zum Einsatz kommt, das idealerweise noch parallel zu Netzleitungen verlegt ist, dann ist der erzielte Durchsatz sowieso schon gut.

Infos zur verwendeten Hardware wären also noch hilfreich... Und richtige benchmarks - iperf wurde ja schon genannt, ansonsten gibts auch noch netperf.

[MSfree]

Samba ha kein problem mit GigaBit, ich erreiche damit seit Jahren ~110MByte/s

Stimmt, das kann ich bestätigen. Selbst mit einem Debian 5.0 auf einem 8 Jahre alte System mit mit entsprechend altem Samba und einem 16-Platten RAID bekommen wir 110-112MB/s via smb.

Allerdings schächelt bei uns NFS ein wenig hinterher undd erreicht nur rund 95MB/s.

[MSfree]

Samba ist kein benchmark. Zudem ist der Overhead nicht gerade gering und der Netzwerkstack der involvierten Windowskiste ist auch alles andere als Gigabit-Optimiert (egal welches Windows...)

Woher kommen diese unsinnigen Legenden?

SMB ist sogar effezienter und schneller als NFS, egal ob WIndows zu Windows, Linux zu Linux oder Windows zu Linux.

Billigswitches oder gar Fritzboxen/Plastikrouter können nichtmal ansatzweise einen einzelnen GBit-Link sättigen, geschweige denn mehrere.

Zur Fritzbox kann ich nichts sagen. Billige GBit-Switches schaffen aber durchaus volle Leistung.

Realtek-NICs sind auch nicht gerade für ihre hohe Qualität und Leistung berühmt.

Doch, sind sie.

Wenn dann auch noch cat5e zum Einsatz kommt, das idealerweise noch parallel zu Netzleitungen verlegt ist, dann ist der erzielte Durchsatz sowieso schon gut.

Hauptsache, die ziehst genug Orakel an den Haaren herbei.

Hier liegen im Fußboden teilweise 40 Cat5e Stränge nebeneinander, zusammen mit 8-10 Strängen 230V-Leitung und Distanzen bis 110m.

Durchsatz 112MB/s.

[dufty2]

Billigswitches oder gar Fritzboxen/Plastikrouter können nichtmal ansatzweise einen einzelnen GBit-Link sättigen, geschweige denn mehrere.

Zur Fritzbox kann ich nichts sagen. Billige GBit-Switches schaffen aber durchaus volle Leistung.

Lt. https://wiki.openwrt.org/doc/hardware/performance hat ein tp-link Wr1043ND (46 € bei amazon.de) 117,6 Mb/s bei "LAN <=> LAN", also gleiches (V)LAN, kein NAT, kein Routing, kein ...
Die 117,6 sind ganz knapp am theoretischen Maximum

[Colttt]

Ohne deine Aussagen zu bezweifeln, kannst du bitte mal die Ausgabe von iperf schicken!?

[r4pt0r]

Zur Fritzbox kann ich nichts sagen. Billige GBit-Switches schaffen aber durchaus volle Leistung.

Wechsel von nem NetGear ProSafe switch auf cisco SG 300 in einer Niederlassung brachte ohne sonstige Änderungen eine Steigerung von 870MBit auf 990MBit (beides mit JumboFrames) zwischen gateway (FreeBSD) und file- (debian) oder backupserver (Freebsd).
Die Fritzbox (6390 IIRC) bei mir zu hause war schon bei ca 650-700MBit am limit, stark schwankend und mit zusätzlicher last über WLAN ging sie deutlich in die Knie. Der "alte" Dell PowerConnect 5424 maxt auch ohne probleme 4 trunks mit je 2 links aus - begrenzend sind hier die Clients/NICs. Intel i350, und e1000/pro1000 bei knapp unter spezifiziertem Durchsatz, Realtek (2 verschiedene 811x getestet) schon deutlich darunter mit ca 850MBit @ einzelnem link mit jumbo frames.
Bei Realtek wird vieles (fast alles?) im Treiber erledigt, nicht im Chipsatz - CPU-Last ist entsprechend höher. Wenn dann auch noch das System eher langsam oder ziemlich ausgelastet ist, leidet die Performance.

Hauptsache, die ziehst genug Orakel an den Haaren herbei.

Hier liegen im Fußboden teilweise 40 Cat5e Stränge nebeneinander, zusammen mit 8-10 Strängen 230V-Leitung und Distanzen bis 110m.

Durchsatz 112MB/s.

Hier lagen Cat5e parallel zu 230V und Drehstromleitungen die u.a. Hebebühnen und Werkstattmaschinen versorgen. Manche links (auch weit unter 100m) wurden regelmäßig auf 100Mbit reduziert, was direkt auf die aktuelle Last auf den daneben liegenden Leitungen zurückzuführen war. Seit die Verkabelung vollständig auf cat7 erneuert wurde gibts keine Probleme mehr - selbst der 220m lange backup-link zwischen den Gebäuden läuft erstaunlich performant: "nur" ca 100MBit langsamer als der LWL-Uplink wenn dieser auf 1GBit reduziert wird.

Als Cat5e wurde auch noch haufenweise ungeschirmtes Zeug als Verlegekabel verkauft - wenn sowas neben Stromleitungen liegt hat man sowieso keine Chance auf brauchbaren Durchsatz zu kommen. Aber ohne wirkliche Details zur vorhandenen Hardware brauchen wir sowieso nicht weiter ins Blaue raten...

[pascalts]

Ohne deine Aussagen zu bezweifeln, kannst du bitte mal die Ausgabe von iperf schicken!?

Ja kann ich. Mein letzter Messwert per iperf war Mist, dieser Wert wurde durch Wiederholung bestätigt.

[ 4] local 192.168.178.37 port 5001 connected with 192.168.178.26 port 38106
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 1.09 GBytes 933 Mbits/sec

Gestern sah das anders aus. Es lag aber auch ein Reboot dazwischen. Doch: Trotz dieses nun stark verbessertem Ergebnisses per iperf ist der Datendurchsatz bei NFS (ca 60MB/s) / SMB (ca 40MB/s) noch immer im Keller.

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

Nach dem Ergebnis kann ich nun Treiber-Probleme ausschließen, da die Verbindung zwischen den Systemen ja schnell genug ist. Es muss also bei NFS oder SMB haken, oder? Die "üblichen" Tuning-Tricks habe ich schon ausprobiert, einige führten gar zur Verlangsamung bei Samba, andere hatten schlicht keine Wirkung.

Code: Alles auswählen

ip link set eth0 mtu 9000

Bevor ich etwas ausprobiere - ohne Erklärung oder Weg, wie ich es rückgängig machen kann - was ist das???

[Colttt]

Soo wenn die Leitung stimmt dann mal gucken was die Platten schaffen.. hab auch schon SSD's gesehen das sie wenig schaffen weil grade am Sterben.. wenn das auch ok ist, dann mal per scp, besser ftp (da nichts verschlüsselt werden muss) etwas übertragen und gucken flink das geht.. wenn das auch ok ist gucken wir weiter..


@R4pt0r: zwischen den switchen liegen ja auch Welten! Cisco ist obere Liga und Netgear eher so nen Mittelding.. persönlich Favorisiere ich im Unternehmen Brocade Switche (machen im Gegensatz zu Cisco alles in Hardware, Cisco macht noch vieles in Software, daher hat man da schonmal geschwindigkeitseinbußen wenn man auf nem 10G port allerhand einschaltet)

[MSfree]

Code: Alles auswählen

ip link set eth0 mtu 9000

Bevor ich etwas ausprobiere - ohne Erklärung oder Weg, wie ich es rückgängig machen kann - was ist das???

Rückgängig:

Code: Alles auswählen

ip link set eth0 mtu 1500

Das ist die Datenpaketgröße, mit der das Netz arbeitet. Überlich war bis 100MBit/s Fast-Ethernet, 1500Byte pro Frame zu nutzen. Das ist für GBit aber ziemlich uneffizient, so daß man GBit normalerweise mit sogenannten Jumboframes fährt. Diese Jumboframes schaltet man mit o.g. Befehl an.

[pascalts]

Soo wenn die Leitung stimmt dann mal gucken was die Platten schaffen.. hab auch schon SSD's gesehen das sie wenig schaffen weil grade am Sterben.. wenn das auch ok ist, dann mal per scp, besser ftp (da nichts verschlüsselt werden muss) etwas übertragen und gucken flink das geht.. wenn das auch ok ist gucken wir weiter..

Ok. Das Datengrab:
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

Die SSD zum testen:
hdparm -tT --direct /dev/sdd
/dev/sdd:
Timing O_DIRECT cached reads: 458 MB in 2.00 seconds = 228.62 MB/sec
Timing O_DIRECT disk reads: 536 MB in 3.00 seconds = 178.54 MB/sec

Beides keine Spitzenwerte. Ich weis. Aber alle mal schneller als 60MB/s. Ich würde mich friedenden geben, wenn ich lesend die 80MB/s schaffen würde. Von FTP halte ich mich eigentlich gern fern - ich befürchte es nicht korrekt konfigurieren zu können und damit die Sciherheit zu verringern.

Jumboframes gehen "nur" bis 4000 zu aktivieren. Bringt ca +4MB/s

[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.