2

we use InterBase on a Windows 2003 server, and in random intervals the client connection to the server takes 180 seconds (three minute) longer than usual. The application does not "hang" with the normal Windows warning in the title bar and continues happily after the delay.

Now the rate seems to have increased since some Windows 2008 servers have been added to the network.

As other applications in the network do not have similar "hangs" I suspect the (virtual) machine or the server process itself. We use the same InterBase database client and server software version in a different network without problems, so my first area of interest is the network (TCP/IP) of the machine. For the same reason I do not think it is a DNS problem, or is this a another candidate?

Are there possible technical explanations for such a delay, for example as a consequence of a full network buffer queue, for such a delay?

netstat -s shows unusccessful connection attempts, zero dropped datagrams received.

IPv4-Statistik

  Empfangene Pakete                    = 1267651308
  Empfangene Vorspannfehler            = 0
  Empfangene Adressfehler              = 44827
  Weitergeleitete Datagramme           = 0
  Empfangene unbekannte Protokolle     = 0
  Empfangene verworfene Pakete         = 0
  Empfangene übermittelte Pakete       = 1267651006
  Ausgabeanforderungen                 = 1097296840
  Verworfene Routingpakete             = 0
  Verworfene Ausgabepakete             = 0
  Ausgabepakete ohne Routing           = 0
  Reassemblierung erforderlich         = 14
  Reassemblierung erfolgreich          = 7
  Reassemblierung erfolglos            = 0
  Erfolgreiche Datagrammfragmentierung = 7
  Erfolglose Datagrammfragmentierung   = 0
  Erzeugte Fragmente                   = 14

ICMPv4-Statistik

                            Empfangen Gesendet
  Meldungen                 26579       26678
  Fehler                    0           0
  Ziel nicht erreichbar     0           95
  Zeitüberschreitung        0           0
  Parameterprobleme         0           0
  Quelldrosselung           0           0
  Umleitungen               0           0
  Echos                     60          26523
  Echoantworten             26519       60
  Zeiteinträge              0           0
  Zeiteintragantworten      0           0
  Adressmasken              0           0
  Adressmaskenantworten     0           0

TCP-Statistik für IPv4

  Aktiv geöffnet                      = 69080
  Passiv geöffnet                     = 16751143
  Erfolglose Verbindungsversuche      = 363
  Zurückgesetzte Verbindungen         = 633
  Aktuelle Verbindungen               = 11
  Empfangene Segmente                 = 1265427823
  Gesendete Segmente                  = 1096717835
  Erneut übertragene Segmente         = 570293

UDP-Statistik für IPv4

  Empfangene Datagramme = 2136945
  Keine Anschlüsse      = 98648
  Empfangsfehler        = 2680
  Gesendete Datagramme  = 50088

2 Answers 2

1

One of the things that I always look for when I see a connection hang is reverse DNS lookup failure. Many applications attempt to resolve the DNS name of a connecting client just after the socket accept on the server side. When DNS does not resolve properly you can experience a hang after which things appear to proceed normally without issue. I have seen this with a wide variety of application services. The time delay of 3 minutes you mention does seem a bit long for this scenario. The typical connection delay that I see is less than 1 minute.

0

The problem disappeared when we re-installed the database server.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .