PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Linux Socketproblem bei bestimmten Paketgrößen, Windows hat dieses Problem nicht



Martinator
20.09.08, 14:55
Hallo,

vielleicht gibt es zufällig einen Linux Socketexperten hier der mir helfen kann :)

Ich weiß nicht ob ich in diesem Unterforum richtig bin, ich hoffe es zumindest.

Ich habe ein Java Programm, welches über TCP-Sockets mit einem externen Programm (Java Programm und externes Programm liegen auf der selben Maschine) kommuniziert.

Unter Windows funktioniert das alles wunderbar, unter Linux funktioniert es ab und zu und wenn es funktioniert ist Linux schneller als Windows.

Aber leider funktioniert es unter Linux ganz schlecht, wenn die Pakete eine Größe von ca. 1 KB bis 17 KB haben. Sind die Pakete größer oder kleiner, dann ist Linux schneller als unter Windows, liegt die Paketgröße aber in diesem Fenster, dann sackt die Kommunikations-Geschwindigkeit enorm ab.

Dabei rede ich von einem Abfall dieser Größenordnung:

366000 Nanosekunden pro Kommunikation unterhalb des problematischen Fensters
0,366 Millisekunden

39857000 Nanosekunden im problematischen Fenster
39,857 Millisekunden

1811000 Nanosekunden oberhalb des problematischen Fensters (natürlich mehr als unterhalb des problematischen Fensters, da die Paketgröße 17 mal größer ist, aber 1,8 Millisekunden sind völlig ok)
1,811 Millisekunden

Nun kann man bei Linux sehr viel an Sockets einstellen, weiß jemand Rat dieses Problem zu beheben?

Vielen lieben Dank!

Martin

derRichard
20.09.08, 15:50
hi!

wenn du das in java machst, dann musst eigentlich an den sockets nicht einstellen.
was ist für dich ein paket?

ohne vdetailinformation wird dir keiner helfen können.

//richard

Martinator
20.09.08, 17:28
Hallo,

was für Detailinformationen fehlen denn?

Also ich habe es lokal mit einer 32 Bit openSuse 10.X Version getestet und auf einem 64 Bit Server mit Debian 2.6.15er Kernel (oder so ähnlich). Der Entwickler des externen Programms und Java Interfaces (eclipse Prolog) hat auch Tests durchgeführt und kam zu ähnlichen Ergebnissen wie wir (Projekt Gruppe).

Mit Paketen meine ich TCP-Pakete, da wie gesagt TCP Sockets benutzt werden.

Wir hatten auch erst in Erwägung gezogen es könnte an der JVM liegen, aber ich habe alle 3 Garbage Collectoren ausprobiert und mit xmx, xms und xmn JVM Optionen rumgespielt (hatten erst eine andere Vermutung), was keine Besserung brachte.


Da es ein und der selbe Javacode (zu mal es ja eigentlich Plattformunabhängig sein soll^^) ist und es nur mit Paketen dieser Größe Probleme gibt, kann es eigentlich nur an den Einstellungen der Linux Sockets liegen. Da sind wir uns ziemlich sicher. Wir haben auch schon ein paar Socket Optionen verändert, leider ohne Erfolg. Es sieht also leider so aus, dass man schon sehr tief in der Linux Socket Materie drinstecken muss, um es zu beheben, leider :(

Wer ein Linux und Java bei sich drauf hat, dem kann ich natürlich gerne ein Test-Programm von uns geben, womit er den Effekt messen kann.

Weiterhin vielen Dank für jede Hilfe!

derRichard
20.09.08, 19:17
hi!

baust du im java selber die pakete oder wie?
das ist ja eigentlich der job von tcp...
du musst ja nur einen stream rausjagen.

//richard

Miliano
20.09.08, 20:50
Hi, ich gehöre zu Martinator und der Gruppe mit dem Problem. Nun verfolge ich das Thema und ich geb mal in Vertretung für Martinator eine Antwort auf den letzten post.

Die Pakete werden nicht von uns selbst gebaut. Es wird der normale Socketmechanismus von Java genutzt(Socket s = new Socket(...)).
Die Datengrößen die Martinator angegeben hat sind die Größen des String die wir über den Stream jagen.

Wir würden uns wirklich freuen, wenn wir das hier hinbekommen. Wir sind etwas verzweifelt. Schon mal vielen Dank!

Max

derRichard
22.09.08, 12:52
hi!

hmm, ich behaupte jetzt einfach mal, dass es am programm selbst liegt.
habt ihr mal im tcpdump oder wireshark nachgesehen wie groß die pakete wirklich sind?

//richard

Martinator
22.09.08, 21:25
Hallo,

wir werden versuchen die Pakete direkt anzuschauen.

Ich habe noch einmal ein exaktes Test-Programm geschrieben und es auf meinem Laptop unter openSuse 10.X laufen lassen und auf dem 64 Bit Debian Server und bei beiden kam exakt das selbe Ergebnis heraus:

Konstante Rückgabegröße und steigende Anfragegröße:

1002 bis 17384 Bytes (Fenstergröße von 16382 Bytes) sind komplett
langsam, wirklich jedes Byte dazwischen. Davor und danach war alles
wieder super.

Fast konstante Anfragegröße und steigende Rückgabegröße:

1000 bis 17382 Bytes (Fenstergröße von 16382 Bytes) sind komplett
langsam, wirklich jedes Byte dazwischen. Davor und danach ist alles
wieder super.
Also nur um 2 Bytes verschoben.

Und wenn man jetzt folgendes macht und sich die Bytes anschaut wo es keine Probleme gibt:

1001 und 17385 sowie 999 und 17383 dann sind das je 16384 Bytes was
EXAKT 16 KB sind.

Das schreit doch nach einer doofen Einstellung irgendwo :)

foolish
23.09.08, 15:23
hi,

vllt. hilfreich ;

http://www.ibm.com/developerworks/linux/library/l-hisock.html?ca=dgr-lnxw01BoostSocket#table1

Miliano
23.09.08, 18:34
Wir sind dem Problem auf der Spur. Der lo Adapter weißt eine MTU von 16kb auf. Setzen wir diesen unter den Startwert des Problemfensters(MTU=1000byte), verschwindet das Problemfenster. Nun wissen wir, mit welcher Einstellung wir einen Einfluss haben. Nur was machen wir auf Rechnern, auf denen wir keine root Rechte besitzen um den MTU Wert zu verändern. Vielleicht fällt jemandem ja ein, was genau nun die hohen Responsezeiten verursacht.
@foolish: Diese Seite ist uns schon bekannt. Wir haben die meisten Einstellungen bereits durchprobiert.
lg Maximilian

foolish
23.09.08, 19:08
hi,

nicht das ich experte wäre, aber habt Ihr mal mit den ;


/proc/sys/net/ipv4/tcp_rmem
/proc/sys/net/ipv4/tcp_wmem

Einstellungen rumprobiert ? bspw. bei mir :

tcp_rmem:4096 87380 174760
tcp_wmem:4096 16384 131072

die 4096 in 2048 umgeändert ?

MiGo
23.09.08, 21:40
Vielleicht fällt jemandem ja ein, was genau nun die hohen Responsezeiten verursacht.
Habe ich das richtig verstanden? Server und Client laufen immer auf der selben Maschine - einmal beide unter Windows, einmal beide unter Linux?
Habt ihr euch mal mit z.b. Wireshark die Pakete angesehen (Stichwort dont-fragment-flag)?
Insbesondere im "Problemfenster" wäre ein Wireshark-Mitschnitt glaube ich ziemlich interessant.

Miliano
24.09.08, 00:41
Ja, Server und Client jeweils immer auf dem gleichen Rechner und Betriebssystem. Was gibt es unter dem Stichwort Don`t fragment bit zu beachten? Ich hab mir die Pakete mit Wireshark angeschaut und dieses Don`t Fragment bit iss mir sofort ins Auge gefallen, auch bevor du es erwähntest. Habe meinen Kollegen auch schon gesagt, dass es keinen Sinn macht, dass dieses Bit gesetzt ist, gerade bei den Strings, die 10kb groß sind. Gerade da sollen doch die Pakete gesplittet werden?
Kannst du da noch mal was zu sagen/erklären?(dont fragment bit)

MiGo
24.09.08, 14:15
Kannst du da noch mal was zu sagen/erklären?(dont fragment bit)
http://de.wikipedia.org/wiki/IP-Fragmentierung
Netzwerkgeräte haben eine bestimmte maximale Paketgröße (MTU). Wenn jetzt ein Paket kommt, dass größer als die MTU ist, muss das Paket in kleinere unterteilt werden (fragmentiert). Das ist nicht immer gewünscht, daher gibt's das "don't fragment"-Flag im IP-Header, der aussagt, dass man das Paket eben nicht in kleinere unterteilen darf. Ein solches Paket wird dann verworfen statt fragementiert zu werden und es wird eine passende Fehlermeldung zurückgeschickt.