Langsame Remote-SELECT-Anweisung aufgrund langer „Client-Verarbeitungszeit“, aber lokal schnell

Diese SELECT-Anweisung ist mit unserem Produktionsserver verbunden (SQL Server 2008, sehr leistungsfähiger Computer) und dauert 2 Sekunden . Dabei werden alle Felder zurückgespuckt (insgesamt 4 MB Daten).

SELECT TOP (30000) *
FROM person
WITH(NOLOCK);

Von jedem anderen Feld im selben Netzwerk (Verbindung über SQL-Authentifizierung oder Windows-Authentifizierung) dauert dieselbe Abfrage 1 Minute und 8 Sekunden .

Ich teste mit dieser sehr einfachen Aussage, um zu veranschaulichen, dass es sich nicht um ein Indizierungsproblem oder ein abfragebezogenes Problem handelt. (Wir haben momentan Leistungsprobleme bei allen Abfragen ...)

Die Reihen kommen in Stücken und nicht alle auf einmal. Ich erhalte sofort meine ersten Zeilen und warte dann über 1 Minute, bis die Reihenstapel eingehen.

Hier sind die Client-Statistiken der Abfrage, wenn sie von der Remote-Box ausgeführt wird:

Query Profile Statistics
  Number of INSERT, DELETE and UPDATE statements 0
  Rows affected by INSERT, DELETE, or UPDATE statements 0
  Number of SELECT statements  2
  Rows returned by SELECT statements 30001
  Number of transactions 0

Network Statistics
  Number of server roundtrips 3
  TDS packets sent from client        3
  TDS packets received from server 1216
  Bytes sent from client         266
  Bytes received from server 4019800

Time Statistics
  Client processing time 72441 ms (72 seconds)
  Total execution time   72441 ms
  Wait time on server replies 0

Wir können sehen, dass die "Client-Verarbeitungszeit" gleich der Gesamtausführungszeit ist.

Weiß jemand, welche Schritte ich unternehmen kann, um zu diagnostizieren, warum die Übertragung der tatsächlichen Daten lange dauert?

Gibt es einen SQL-Konfigurationsparameter, der die Datenübertragungsgeschwindigkeit zwischen Computern einschränkt oder begrenzt?

Ihr Problem hängt definitiv mit dem Netzwerk zusammen, basierend auf Ihren Informationen. Als solches muss es mit Netzwerkprofis behandelt werden (ich bin nicht derjenige).

Dinge, die helfen könnten:

• Schnellere NIC-Karten (auf SQL Server).
• Hinzufügen einer zugewiesenen / spezifischen NIC-Karte / eines Subnetzes zwischen den Servern (Webserver und SQL Server).

Befindet sich der Webserver im selben Subnetz wie der SQL Server?

Gibt es Router / Bridges usw. zwischen ihnen?

Nicht viele mögliche Änderungen auf SQL Server:

• Ausgabedaten werden von SQL Server mit dem proprietären MS "TDS-Protokoll" gesendet.
• Die Standardgröße des TDS-Puffers beträgt 4 KB. Siehe in MSDB: "Option für Netzwerkpaketgröße"
• Das Komprimieren der Daten (mit SQL Server oder einer externen Anwendung) - hängt von der Art der Daten ab.

Sie verwenden eine Standardgröße: Siehe Ihre Statistiken: "Vom Server 1216 empfangene TDS-Pakete" (4 MB / 1 KB = 4 KB). Ja, die Größe des TDS-Puffers kann geändert werden: siehe in Google: "Stapelgröße des TDS-Protokolls"

Gute Diskussion zum Thema: "Bestimmt die Netzwerkpaketgröße von SQL wirklich den Roundtrip-Verkehr?"

Eine Änderung der TDS-Packungsgröße hat jedoch (unvermeidlich) unvorhersehbare Auswirkungen und sollte nur in Ausnahmefällen in der Produktion verwendet werden.

Eine Änderung der Architektur oder die Einführung des Zwischenspeicherns von Daten auf mittlerer Ebene würde ebenfalls helfen.

Dieses Problem ist jetzt behoben.

Es war ein Netzwerkproblem, und die SQL-Box verwendete eine 100-MB / s- NIC-Karte anstelle einer 10-GB / s- NIC-Karte ...

Eine Änderung der Netzwerkkonfiguration zur Verwendung der richtigen Netzwerkkarte hat das Problem behoben. Jetzt erhalten wir eine ähnliche Leistung für alle Abfragen aus der Production SQL-Box und aus anderen Boxen im Netzwerk.

Vielen Dank an alle für Ihre Hilfe.

Beim ersten Lesen scheint es, als hätten Sie Probleme mit der Netzwerklatenz. Haben Sie sich einige der Network Perfmon-Zähler angesehen? Diese können Ihnen einen Hinweis darauf geben, was mit dem Netzwerk los ist.

Zitat aus Welche Perfmon-Zähler soll ich überwachen und was bedeuten sie jeweils?

NETZWERK IO

Zum Messen der Netzwerk-E / A können Sie die folgenden Zähler verwenden:

NetzwerkschnittstelleBytes Gesamt / Sek

Schwellenwert: Anhaltende Werte von mehr als 80 Prozent der Netzwerkbandbreite.

Bedeutung: Dieser Zähler gibt die Rate an, mit der Bytes über jeden Netzwerkadapter gesendet und empfangen werden. Mit diesem Zähler können Sie feststellen, ob der Datenverkehr auf Ihrem Netzwerkadapter überlastet ist und ob Sie einen weiteren Netzwerkadapter hinzufügen müssen. Wie schnell Sie ein Problem erkennen können, hängt von der Art Ihres Netzwerks ab und davon, ob Sie die Bandbreite mit anderen Anwendungen teilen.

Network InterfaceBytes Received / Sek

Dieser Zähler gibt die Rate an, mit der Bytes über jeden Netzwerkadapter empfangen werden. Sie können die Rate eingehender Daten als Teil der Gesamtbandbreite berechnen. Auf diese Weise wissen Sie, dass Sie die vom Client eingehenden Daten optimieren oder einen weiteren Netzwerkadapter hinzufügen müssen, um den eingehenden Datenverkehr zu verarbeiten.

NetzwerkschnittstelleBytes Gesendet / Sek

Dieser Zähler gibt die Rate an, mit der Bytes über jeden Netzwerkadapter gesendet werden. Sie können die Rate eingehender Daten als Teil der Gesamtbandbreite berechnen. Auf diese Weise wissen Sie, dass Sie die an den Client gesendeten Daten optimieren oder einen weiteren Netzwerkadapter hinzufügen müssen, um den ausgehenden Datenverkehr zu verarbeiten.

ServerBytes Gesamt / Sek

Dieser Wert sollte nicht mehr als 50 Prozent der Netzwerkkapazität betragen.

Dieser Zähler gibt die Anzahl der über das Netzwerk gesendeten und empfangenen Bytes an. Höhere Werte geben die Netzwerkbandbreite als Engpass an. Wenn die Summe der Bytes insgesamt / s für alle Server ungefähr der maximalen Übertragungsrate Ihres Netzwerks entspricht, müssen Sie möglicherweise das Netzwerk segmentieren.

Prozessor% Unterbrechungszeit

Dieser Zähler gibt den Prozentsatz der Zeit an, die der Prozessor damit verbringt, Hardware-Interrupts zu empfangen und zu warten. Dieser Wert ist ein indirekter Indikator für die Aktivität von Geräten, die Interrupts erzeugen, z. B. Netzwerkadapter.

Länge der Ausgabewarteschlange der Netzwerkschnittstelle (*)

Dieser Zähler überprüft, wie viele Threads auf den Netzwerkadapter warten. Wenn auf dem Netzwerkadapter viele Threads warten, sättigt das System die Netzwerk-E / A höchstwahrscheinlich aufgrund der Netzwerklatenz oder der Netzwerkbandbreite.

Länge der Ausgabewarteschlange ist die Länge der Ausgabepaketwarteschlange (in Paketen). Wenn dies länger als zwei ist, gibt es Verzögerungen und der Engpass sollte gefunden und wenn möglich beseitigt werden. Da die Anforderungen in dieser Implementierung von der Network Driver Interface Specification (NDIS) in die Warteschlange gestellt werden, ist dies immer 0.

Einige vorläufige Fragen: 1) Der Server hat einen SQL-Client auf Prod. Server-Maschine eingerichtet, richtig? Wenn Sie also dieselbe Abfrage vom Client auf demselben Computer ausführen, ist sie in 2 Sekunden abgeschlossen. Hast du versucht das zu tun? Ist es wirklich 2 Sekunden? 2) Sie haben erwähnt, dass die Konfiguration Ihrer Produktionsumgebung geändert wurde (oder der Produktionsserver in ein anderes Netzwerk verschoben wurde / der gesamte Server neu erstellt wurde), richtig? Was war die Abfrageverbrauchszeit in einer alten Produktionsumgebung?

Von jeder anderen Box im selben Netzwerk ... dauert dieselbe Abfrage 1 Minute und 8 Sekunden. 3) Sie sagen, dass die Abfrage in etwa 70 Sekunden vom Client zurückgegeben und vom Client auf einem beliebigen Computer im angegebenen Netzwerk (mit Ausnahme Ihres spezifischen Computers) verarbeitet wird? Ich habe es richtig verstanden? 3.1 Was ist übrigens der Zeitpunkt für den Verbrauch dieser Abfrage, der vom Unternehmen akzeptiert wird? 4) Sie geben jedoch an, dass für einen bestimmten Clientcomputer, den Sie verwenden, die Verbrauchszeit für die Abfrageausgabe Folgendes beträgt: Clientausführungszeit 15:30: 48 15 Minuten? (und diesmal ist das eindeutig nicht akzeptabel)? Richtig? 5) Ist das Problem also auf einen einzelnen Client-Computer beschränkt? Oder auf JEDEN Client / Mid-Tier-Computer usw. (in einer neuen Umgebung)? 6) Wie hoch ist die Verzögerung, die durch Ping angezeigt wird? vom Client-Computer zum Server? 7) Sie (oder der Netzwerkadministrator) haben Tracert in beide Richtungen ausgeführt (von Client zu Server, von Server zu Client)? Wie viele Hopfen? Was ist die kombinierte Zeit? 8) Lebt das alte Produktionsnetzwerk? Können Sie die Verwendung von Ping und Traceroute vergleichen - wie spät war es dort und zwischen Client und Server?

Aus Neugier: Dies ist ein Beispiel für die Abfrage? oder genauer Wortlaut der Anfrage? Die Abfrage enthält wirklich KEINE WHERE-Klausel? Stimmen Sie mir zu, dass dies sehr ungewöhnlich ist. Die Tabelle hat einen Clustered-Index oder ist ein Heap? Die Tabelle enthält insgesamt wie viele Zeilen? Der Tisch ist stark fragmentiert? Aus Neugier: Warum TOP NNN AUSWÄHLEN? Warum nicht ROWCOUNT NNN SETZEN - dann SELECT *? Diese Abfrage wird wie oft vom Client pro Tag ausgegeben? 1? 100? 1MLN? Die zugrunde liegenden Daten sind statisch oder dynamisch und werden stark verändert? Wie viel (0,01 Prozent pro Tag? 1 Prozent pro Tag? 10 Prozent pro Tag?) Die Abfrageausgabe wird programmgesteuert verarbeitet? (nicht von einem Benutzer?) Warum wird es nicht zwischengespeichert / nicht auf der mittleren Ebene gespeichert? Danke, Alexei