☰

Случайная трехминутная задержка при подключении к серверу базы данных

tag-icon • tag-icon windows networking tcpip
Случайная трехминутная задержка при подключении к серверу базы данных

мы используем InterBase на сервере Windows 2003, и в случайные интервалы времени клиентское соединение с сервером занимает на 180 секунд (три минуты) больше обычного. Приложение не «зависает» с обычным предупреждением Windows в строке заголовка и успешно продолжает работу после задержки.

Сейчас эта скорость, похоже, возросла, поскольку к сети были добавлены несколько серверов Windows 2008.

Поскольку другие приложения в сети не имеют подобных "зависаний", я подозреваю, что это (виртуальная) машина или сам процесс сервера. Мы используем одну и ту же версию клиентского и серверного ПО базы данных InterBase в другой сети без проблем, поэтому моя первая область интереса - это сеть (TCP/IP) машины. По той же причине я не думаю, что это проблема DNS, или это другой кандидат?

Существуют ли возможные технические объяснения такой задержки, например, как следствие полной очереди сетевого буфера?

netstat -s показывает неуспешные попытки подключения, ноль потерянных датаграмм.

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

решение1

Одна из вещей, на которую я всегда обращаю внимание, когда вижу зависание соединения, — это ошибка обратного поиска DNS. Многие приложения пытаются разрешить DNS-имя подключающегося клиента сразу после принятия сокета на стороне сервера. Когда DNS не разрешается должным образом, вы можете столкнуться с зависанием, после которого все, как кажется, идет нормально без проблем. Я видел это с большим количеством служб приложений. Упомянутая вами задержка в 3 минуты кажется немного долгой для этого сценария. Типичная задержка соединения, которую я вижу, составляет менее 1 минуты.

решение2

Проблема исчезла, когда мы переустановили сервер базы данных.

Связанный контент