Analyse, Mr. Spock. Bevor experimentiell umkonfiguriert wird, Bösewicht finden;-) Falls möglich, würde ich mal versuchen, festzustellen, ob's am System, der Applikation oder dem Netzwerk liegt. Ich nehme da immer wieder gerne iperf, das ist ein client-server basiertes Testtool. Gibt's fuer Windows, Linux, OS X etc. Man kann Port, Datenmenge, MTU, Protokoll (UDP/TCP), unidirektional und bidirektional einstellen und vordefinieren, welche Datenmenge über welchen Zeitraum übertragen werden sollen. Einfach mal nach iperf googlen. Wenn der TCP-Durchsatz dort stimmt, wär's dann warscheinlich der Apache, der Probleme macht. Wobei es nicht auszuschließen ist, dass evtl irgendwelche transparenten Proxies zwischendrin dein Problem verursachen. Kann man aber auch antesten: apache stoppen und iperf auf port 80 tcp laufen lassen...
Viele Grüße, Patrick Am 30. November 2009 19:08 schrieb Silvério Santos <[email protected]>: > Martin Schmitt schrieb: > > Silvério Santos schrieb: >> >> >> >>> kann ich nicht beurteilen. Wie läßt sich die Vermutung bestätigen oder >>> widerlegen? >>> Oder besser: was kann ich auf Serverseite ändern, um das Problem zu >>> lösen? >>> >>> >> >> Ich hätte ja gehofft, daß sich hier irgendwann mal der Christian >> einschaltet, denn ich kann das MTU-Thema zwar erkennen, aber mir fehlt >> das tiefere Verständnis dafür. ;-) >> >> Du hast uns zumindest nicht verraten, ob die Netzwerkverbindung in >> beiden Testfällen die selbe ist. Wenn es nicht die selbe ist, würde das >> die MTU-These stützen. >> >> > Nachvollziehbar ist das immer per VPN-Tunnel durch ein Nortel Contivity und > auch im LAN sind die Probleme selten gesichtet worden. > > Das beschriebene System läuft auf physischer Hardware. Dort habe ich > übrigens den Kernel von 2.6.26 auf .30 aktualisiert, ohne Erfolg. > > Heute morgen habe ich auf KVM/Qemu ein frisches Minimal-Debian Lenny mit > einem original konfigurierten Apache aufgesetzt, die Dateien vom > funktionierenden SuSE (nicht Ubuntu, wie zuerst geschrieben) kopiert und die > Rechte angepasst, mehr nicht; Resultat: gleiches Problem. Ein Komprimieren > der exe zu einem tgz, um irgendwelche filternde, transparente Proxies als > Problemquelle zu umgehen, hat's auch nicht gebracht. Höchstens könnte ein > solches Teil die tgz entpacken, um mit mir Schabernack zu treiben. Ein > Ticket diesbezüglich hat auch das nicht bestätigt. > > Ein Vergleich des Downloads per LAN bringt übrigens folgende Unterschiede > zur VPN-Verbindung zu Tage: > - es werden mehrere Pakete vor einem ACK versandt, beim VPN immer eines pro > ACK > - es gibt Dup-ACK-Orgien mit einer oder zwei Retransmissions und danach > normales Verhalten anstelle von endlosen Retransmission-Orgien in immer > längeren Abständen > - der Download wird vervollständigt (!) > > Ich habe sogar ein paar Einstellungen unter /proc/sys/net/ipv4 mit dem > funktionierenden System verglichen, z.B. tcp_sack oder tcp_window_scaling. > Die Stichproben waren gleich. > > Hat jemand irgend einen Tip, was ich noch machen kann? Google ist zum > zweiten Tag nicht hilfreich. > > Gruß > Silvério > > > -- > > ---------------------------------------------------------------------------- > PUG - Penguin User Group Wiesbaden - http://www.pug.org > -- Patrick Glanz Schulstraße 1 67808 Mörsfeld
-- ---------------------------------------------------------------------------- PUG - Penguin User Group Wiesbaden - http://www.pug.org
