Delays von exakt 5s bei Verbindung zu bestimmtem Server

[bitmuncher]

Auf einem meiner DB-Server habe ich momentan ein recht seltsames Problem. Ab und an brauchen Verbindungen zu diesem Server extakt 5s länger als üblich. Dieses Phänomen tritt aber nicht bei jeder Verbindung auf, sondern nur ab und an. Im Durchschnitt alle 30 Verbindungen.

Üblicherweise hängt dieser DB-Server an einem Loadbalancer, der mit einem embedded FreeBSD läuft, so dass ich anfangs davon ausging, dass das NAT des Loadbalancers evtl. Probleme macht. Also hab ich ihn mal testweise mit seinem zweiten Netzwerkinterface an einen Switch angeschlossen und ihm eine IP gegeben, mit der er auch über's Internet errreichbar ist. Aber auch wenn die Verbindung über's Switch geht, treten diese Delays von 5s auf.

Ich denke daher, dass das Problem vom Server selbst kommt, finde momentan aber nichts, wo diese Probleme herkommen könnten. MTU ist für alle Netzwerk-Interfaces auf 1500 gestellt. Da offenbar beide Netzwerk-Interfaces des Servers betroffen sind, schliesse ich einen Hardware-Fehler eigentlich auch aus. Die Last des Servers ist bei 0. Mit ca. 400kb/s ist das Netzwerk auch noch lange nicht ausgelastet und auch RAM sind noch 2GB frei. Am MySQL kann es eigentlich auch nicht liegen, da die Delays auch bei SSH-Verbindungen auftreten.

Hat evtl. jemand eine Idee, woran es noch hängen könnte? Bin langsam ratlos und bin für jeden Hinweis dankbar.

Edit: System auf der Kiste ist Debian Lenny. Es laufen neben den üblichen Diensten wie klogd, syslogd usw. noch eine MySQL 5.1.32-linux-x86_64-glibc23 und der OpenSSH-Server von Lenny.

Edit2: Die Delays treten offenbar nur beim Verbindungsaufbau auf. Eine bestehende SSH-Verbindung zeigt keinerlei Probleme.

 

[@->-]

Edit2: Die Delays treten offenbar nur beim Verbindungsaufbau auf. Eine bestehende SSH-Verbindung zeigt keinerlei Probleme.

Vieleicht ein Problem mit der Namensauflösung? Kannst du das irgendwie testen? Tritt dieser Vörzögerung nur von dir aus auf, oder auch bei Verbindungsversuche vom Server zum Client?

In diesem Sinne

 

[bitmuncher]

Ich baue die Verbindungen zum Server immer über die IP auf. Hab aber auch mal testweise in meiner /etc/hosts einen Namen drauf gesetzt und auch darüber gibt es das Problem. Bei Verbindungen vom Server zum Client kann ich keine Delays feststellen.

 

[bb83]

Mal nen einfachen traceroute gemacht, bzw mit wireshark geschaut was da so durch die Leitung läuft ?

 

[bitmuncher]

traceroute bringt keine ungewöhnlichen Ergebnisse. Die Hops sind alle schnell nur nach dem letzten Hop braucht er ab und an exakt 5s bis traceroute sich beendet. Einzelne Pakete mit tcpdump ausfiltern ist auch schwierig, da vom Client zum Server durchschnittlich 140 Verbindungen pro Sekunde gehen. Vom Netz nehmen ist momentan schwierig, da ich schreibende Verbindungen nicht mal so auf die Schnelle auf den Slave leiten kann ohne nachher stundenlang die Replikation wieder synchronisieren zu müssen.

 

[aspire_5652]

verrät dmesg was? (link up/link down)

was sagt

iostat -t -x -k -d 5

vllt auch ein IP-Adress Konflikt?

 

[bitmuncher]

In den Kernel-Logs hatte ich natürlich zuerst nachgeschaut. Da findet sich nichts. Ein IP-Konflikt kann ausgeschlossen werden. Was iostat bringen soll, ist mir ehrlich gesagt unklar. Auf der Kiste ist ständig etwas Durchsatz auf den Platten, allerdings nicht soviel, dass es ausgelastet wäre.

Momentan bin ich dabei mal das RAID zu prüfen, wie es mir unter http://bitmuncher.blog.de/2009/06/29/seltsame-server-probleme-6422849/ geraten wurde. Bisher konnte ich da aber auch nichts auffälliges feststellen.

Edit: Hab jetzt mal ein 'show diag' für den 3ware RAID-Controller durchlaufen lassen. Auffällig ist, dass da immer wieder die folgende Meldung auftritt:

BBU comm error 0x241 while writing packet : I2C transaction aborted

Leider findet sich im Netz dazu nicht sonderlich viel. Hab jetzt mal beim Server-Hersteller angefragt, ob die eine Erklärung dafür haben. Mal schauen, was da raus kommt und ob das evtl. die Ursache für das Problem sein könnte.

Edit2: Um das Netzwerk als Ursache auszuschliessen, da es ja den Anschein hatte, dass der Handshake so lange dauerte, hab ich jetzt mal einen SSH-Tunnel zum Client gelegt, so dass nicht jedes Mal ein Handshake notwendig ist. Auch über diesen treten die 5s-Delays auf, so dass ich das Netzwerk mittlerweile als Ursache ausschliesse. Zurück zum RAID.

 

[bitmuncher]

Das Problem scheint gelöst zu sein. Offenbar stellte es ein Problem dar, dass die LAN-IP des Client-Rechners nicht vom MySQL-Server aufgelöst werden konnte. Seitdem ich die IP in der /etc/hosts auf einen Namen gemappt habe, ist das Delay nicht mehr aufgetreten.

 

[keks]

Hi Bitmuncher

Das Problem scheint gelöst zu sein. Offenbar stellte es ein Problem dar, dass die LAN-IP des Client-Rechners nicht vom MySQL-Server aufgelöst werden konnte. Seitdem ich die IP in der /etc/hosts auf einen Namen gemappt habe, ist das Delay nicht mehr aufgetreten.

Verstehe ich nicht, was soll denn dort "aufgelöst" werden?
MAC Adressen in IP-Adressen? Wieso sollte das so lange dauern?

Du benutzt doch eh kein dns?!

Grüße
Verwirrter Keks

 

[HeadCrash]

Hi keks,

diverse Serverdienste (unter anderem MySQL, SSH) versuchen ein Reverselookup der Client-IP-Adresse.

Und genau der nicht verwendete oder unvollständige gepflegte DNS verursacht solche Verzögerungen, da die DNS-Abfrage in ein Timeout läuft.

mfg
HeadCrash

 

[bitmuncher]

Näheres dazu kann man auch unter http://dev.mysql.com/doc/refman/5.0/en/dns.html nachlesen.

 

[keks]

diverse Serverdienste (unter anderem MySQL, SSH) versuchen ein Reverselookup der Client-IP-Adresse.

Logisch daran hab ich garnicht gedacht...
Danke für die Belehrung!

Grüße
Keks