Frage, Netz-Auslastung testen und lanzeit Prüfung

D

Domi

Member
Hallöchen liebe Gemeinde,

ich habe mal eine kleine Frage an Euch wegen der Netz-Anbindung zu einem oder zwei dedizierten Servern. Heute Vormittag hatte ich das Phänomen, dass eine meiner Internetseiten (z.B. fremdenverkehrsbuero.info) sehr sehr lange brauchte, bis diese komplett aufgebaut war. Geprüft hatte ich das mit dem Addon Firebug im Firefox, hier Zuhause mit einer 16Mbit DSL Leitung.

Der Firebug hatte mir dann gesagt dass das eine oder andere Image oder auch JS Datei mal eben 20 Sekunden geladen hatte. Jetzt eben hat es nur 1 - 2 Sekunden gedauert und ein wenig später dann 6 Sekunden.

Ein Kumpel von mir hatte dann via POP3 einmal seine Mails vom gleichen Server abgerufen und hatte auch mal ein "Timeout, Zeitüberschreitung" als Rückmeldung.

Ich habe nun via 'htop' einmal geschaut ob etwas besonders hoch ausgelastet ist, aber da ist alles im grünen Bereich und meine Backups, wo große Pakete über die Leitung fließen, werden in der Nacht verschoben.

Wo setze ich denn am besten an, oder wie kann ich denn am besten erforschen, wo es hierbei harkt? Denn das Problem oder Phänomen hatte ich noch nicht.

Gruß, Domi

p.s. Auf meinem privaten Server kommt es im TeamSpeak auch ab und an zu Ruckler. Vielleicht ist das ja etwas ähnliches. Beide Server stehen bei Hetzner aber in unterschiedlichen Rechenzentren (RZ10 und RZ13).
 
Hallo Domi,

wenn dein Server nicht das Problem ist, könnte die Verbindung zum Server eingeschränkt sein. Dies kannst du unter Windows mit Hilfe des Befehls tracert herausfinden.

Der Befehl tracert zeigt dir zeilenweise an, wie lange die Anfrage bis zu deinem Server dauert.
Ist nur ein Server in der Kette, der deine Anfrage nicht schnell genug weiter zu deinem Server weiterreicht, kann dein Server dementsprechend nicht schnell genug antworten.

Das folgende Beispiel zu deiner genannten Domain zeigt, wie es aussehen kann, wenn man ein trece zum Zielserver abschickt.

Beispiel:
Code: 
tracert fremdenverkehrsbuero.info

Routenverfolgung zu fremdenverkehrsbuero.info [188.40.141.5] über maximal 30 Abschnitte:

  1     1 ms    <1 ms    <1 ms  Eigener-DSL-Rooter [IP-Adresse]
  2     5 ms     3 ms     3 ms  Gateway-des-eigenen-Providers [IP-Adresse]
  3    20 ms    10 ms    10 ms  decix2-gw.hetzner.de [80.81.193.164]
  4   110 ms   190 ms   100 ms  core4.hetzner.de [213.239.245.2]
  5    18 ms    17 ms    15 ms  core21.hetzner.de [213.239.245.13]
  6    18 ms    19 ms    16 ms  juniper1.rz10.hetzner.de [213.239.245.42]
  7   270 ms   280 ms   260 ms  hos-tr2.ex3k13.rz10.hetzner.de [213.239.227.174]
  8    15 ms    15 ms    17 ms  rsrv03.i-m-h.net [188.40.141.5]

An Hand des Beispiels siehst du, dass die beiden Server in der Zeile 4 und 7 deine Anfrage zum Zielserver verzögern und dein Problem in diesem Beispiel die Netzanbindung ist.

Gruss
andreas0
 
Moin andreas0, auf den tracert bin ich so noch gar nicht gekommen. Ich hatte erst überlegt, das Problem am Server selbst anstatt über den tracert zu suchen.

Ich vermute mal das ist ein Router der sich "juniper1.rz10.hetzner.de" nennt, denn dieser ist bei meiner Anfrage gerade der Flaschenhals. Ich werde dies mal im Auge behalten.

Wenn es noch einen anderen Tipp gibt, probiere ich das natürlich gerne mal aus. Aber mit 'tracert' habe ich schon mal einen Ansatz um zu schauen, wo es harken könnte.

Gruß, Domi
 
traceroute liefert diesbezüglich keine verlässlichen Informationen - Du weißt weder, welche Weg das "auffällige" Paket genommen hat noch ob (und viele Router tun dies) das entsprechende Paket nicht einfach mit niedriger Pio beantwortet wurde.

... sieht man ja schon daran, daß das Paket, welches einen Hop mehr gemacht hat schon wieder flott unterwegs ist.

Grundlegende Routingunschönheiten könntest Du erkennen, über die Performance der jeweiligen Hops sagt es aber nichts aus.
 
marce said:
... sieht man ja schon daran, daß das Paket, welches einen Hop mehr gemacht hat schon wieder flott unterwegs ist.

Grundlegende Routingunschönheiten könntest Du erkennen, über die Performance der jeweiligen Hops sagt es aber nichts aus.
Click to expand...

Für solche Routingtests nehme ich gern WinMTR. Bei entsprechend großer Paketanzahl (>1000) kann man zumindest erkennen, ob es irgendwo unterwegs Engpässe gibt.
 
andreas0 said:
An Hand des Beispiels siehst du, dass die beiden Server in der Zeile 4 und 7 deine Anfrage zum Zielserver verzögern und dein Problem in diesem Beispiel die Netzanbindung ist.
Click to expand...
Ein Router, der mittendrin etwas länger zum Antworten braucht ist kein Indiz für irgendetwas ;)
Das sind Router und keine ICMP-Generator-Maschinen. Üblicherweise konfiguriert man die Dinger so, dass sie ICMP-Pakete nur in bestimmten Zeitintervallen generieren, so dass du immer teilweise über 500ms Antwortzeit bekommen kannst. Das sagt weder etwas über die Anbindung oder die Auslastung des Routers aus, das ist einfach eine sinnvolle Konfiguration.
Das ganze firmiert unter dem Titel "Scheduling":
http://de.wikipedia.org/wiki/Scheduling

Wenn alle Hops (Ziel eingeschlossen) hinter diesem Router ebenfalls ähnlich hohe Latenzzeiten haben ist das ein Hinweis darauf, dass die Anbindung zwischen dem fraglichen Hop und dem davor ausgelastet sein könnte - oder schlicht und ergreifend eine erstaunlich lange Strecke (z.B. per Satellit) zurückgelegt wird.

Für genaue Ausagen muss man zwingend von beiden Seiten aus Traceroutes fahren, denn wie marce schon sagte: Du weißt nur, welchen Weg das Paket von dir zum Server genommen hat. Der Rückweg vom Server zu dir zurück kann vollkommen anders aussehen!


@Domi:
Solche Ladezeiten zusammen mit Zeitüberschreitungen können ein Hinweis auf aufgetretenen Packetloss sein. Sobald Datenpakete verloren gehen müssen diese Nachgefordert werden, was aber erst nach bestimmten Timeouts passiert. Gehen regelmäßig Pakete verloren, summieren sich die Timeouts und die Seite lädt entsprechend langsam.

Wenn das jetzt einmal für einen kurzen Zeitraum aufgetreten ist: Tragisch, aber es kann halt nunmal zu kurzen Störungen kommen.
Sollte das regelmäßig passieren, einfach mal den MTR laufen lassen und gucken, ob die Latenzzeiten wackeln oder Pakete verloren gehen.
Packetloss gehört in den neuen Hetzner'schen Rechenzentren leider seit einiger Zeit zunehmend zum Nutzungserlebnis und würde auch deine Ruckler auf dem Teamspeak-Server erklären.
 
Last edited by a moderator:
Hi Lord Gurke, danke für die Information mit den Packetloss.. Ich werde das mal im Auge behalten. Sollte das öfters vorkommen, müsste ich doch überlegen ob ich mir vielleicht einen Server eines anderen Anbieters zulege.

Ich habe alternativ noch einen VPS bei OVH in Kanada stehen. Da ist zwar teilweise die Anbindung auch etwas langsam, aber das könnte daran liegen das es ein VPS ist und auch die Strecke.

Das behalte ich jetzt mal im Auge und wenn es vermehrt vorkommt, werde ich mal mit dem WinMTR prüfen und genaueres berichten ;)

Aber schon mal vielen Dank für die Informationen.
Gruß, Domi
 
Es könnten ebenso gut DNS Probleme sein, die gern mal für Verzögerungen bei Diensten (client- als auch Serverseitig) sorgen.
Es muss auch nicht immer der Hoster dran schuld sein. Da liegen meist noch einige andere Provider dazwischen. Dein eigener ISP könnte ebenfalls schuld sein. Oder du hast schlicht ein Problem auf deiner Workstation.
Irgendwelche Traceroutes oder MTRs sind nur ein mögliches Indiz.

Wir sind in der IT. Es gibt tausend Ursachen für dieses Phänomen.
Die Hohe Kunst des Admins ist es, die richtige heraus zu picken. ;)
 
You must log in or register to reply here.
Back
Top