it-swarm.com.de

Verbindungszeitlimit ohne offensichtliches Netzwerkproblem abgelaufen

Wir haben einen bestimmten SQL Server, der beim Akzeptieren von Verbindungen zeitweise eine Zeitüberschreitung aufweist. Das Problem ist den ganzen Tag über konsistent, tritt jedoch nur sehr selten auf. Wie kann ich weiterhin Fehler beheben?

Verbindungszeitlimit abgelaufen. Die Zeitüberschreitung beim Versuch, die Handshake-Bestätigung vor der Anmeldung zu nutzen. Dies kann daran liegen, dass der Handshake vor der Anmeldung fehlgeschlagen ist oder der Server nicht rechtzeitig antworten konnte. Die Dauer beim Versuch, eine Verbindung zu diesem Server herzustellen, betrug: [Pre-Login] -Initialisierung = 0; Handschlag = 15002; (Microsoft SQL Server, Fehler: -2)

Serverkonfiguration:

  • SQL Server 2016 SP1 CU5 Enterprise (Problem trat auch vor SP1 auf)
  • Windows Server 2012 R2 auf Server und Client
  • VMware ESXi, 6.5.0 unter HP ProLiant DL360 Gen9
  • VM hat 8 vCPU, 64 GiB des Speichers (vollständig reserviert)

Testskript (einmal pro Sekunde ausgeführt):

$failed = $false;
$loginDuration = (Measure-Command {
    $ncon = New-Object System.Data.SqlClient.SqlConnection `
        @( 'Data Source=1.2.3.4,16143;Database=Test;User=Test;Password=****;Pooling=false;' );
    try 
    {
        $ncon.Open();

        $cmd = New-Object System.Data.SqlClient.SqlCommand `
            @( 'SELECT @@VERSION', $ncon );
        $cmd.ExecuteNonQuery();

        $ncon.Dispose();
    }
    catch
    {
        $failed = $true;
    }
}).TotalMilliseconds;
Write-Metric -metric 'itp.dbserver.logintime' -unit 'milliseconds' `
    -value (&{if ($failed) { 120000 } else { $loginDuration }});

Beobachtungen:

  • Das Problem trat auf, nachdem Betriebssystemaktualisierungen, SQL Server-Aktualisierungen, San-Verschiebungen und Verschiebungen von Hyper-V zu VMWare aufgetreten waren
  • Die meisten Verbindungen sind erfolgreich (4 Fehler von 1.440 Versuchen)
  • Fehler werden in "[Pre-Login] initialization = 0;" immer mit einer niedrigen Zahl aufgelistet. und eine hohe Zahl in "Handshake = 15002". Wir erhalten keine Fehler wie "Nicht gefunden" oder "Kein solcher Host ist bekannt", sondern nur "Verbindungs-Timeout".
  • Für den Listener ist keine Verschlüsselung aktiviert
  • Pings zeigen über einen längeren Zeitraum keinen Verlust (0 von 96.045 gesendeten verloren)
  • Alle Firewalls sind deaktiviert
  • Verbindungen, bei denen versucht wurde, IPv6- und IPv4-Adressen zu verwenden, schlagen mit derselben Rate fehl
  • Die CPU ist schwach (<40%)
  • Die Anzahl der aktiven Sitzungen beträgt dauerhaft rund 400
  • Ballonfahrer ist deaktiviert
  • Einmal hergestellte Verbindungen sind stabil, keine unerwarteten Fehler beim Ausführen von Abfragen, keine ungeraden Unterbrechungen.
  • Mehrere Clients haben Probleme beim Verbinden - sowohl ODBC als auch ADO von mehreren Computern)

Update: Ich habe endlich eine clientseitige Wireshark-Spur einer fehlgeschlagenen Verbindung erhalten. Es ist kein Paketverlust erkennbar. Der Client empfängt TCP ACKs in Echtzeit (<10 ms)). Der Client hat zum Zeitpunkt des Fehlers den DNS-Namen verwendet, der Fehler tritt jedoch mithilfe der IPv4-Adresse in der Verbindungszeichenfolge auf .

(Wireshark conversation graph showing server not responding for >15 seconds

Habe ich Recht, wenn ich denke, dass die Tatsache, dass ich sofort TCP ACKs zu den vor der Anmeldung gesendeten Anforderungspaketen bekomme), das Problem auf dem Betriebssystem oder SQL Server lokalisieren würde?

6
Mitch
3
Mitch