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

11

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?

FranticRock
quelle
Übrigens haben wir versucht, die Datei gleicher Größe (4 MB) zwischen dem DB-Server und einer anderen Box zu kopieren, und das dauerte eine Sekunde. Es scheint also kein Netzwerkproblem zu sein.
FranticRock
Was ist die Client-Anwendung? SSMS auf den Endbenutzer-Workstations?
Thomas Stringer
Ja Microsoft SQL Server Management Studio 10.50.1600.1. 2008 R2
FranticRock
Dieses Problem trat auf, seit wir Rechenzentren verschoben und der gesamte Computer neu installiert wurden (alles einschließlich SQL). Wir sind mit einem sehr angesehenen Hosting-Anbieter.
FranticRock

Antworten:

4

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.

alexei
quelle
7

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.

FranticRock
quelle
3

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.

jgardner04
quelle
Nachdem ich diese Statistiken in Perfmon überwacht hatte, bemerkte ich einige Dinge. Die Gesamtanzahl der Bytes / Sek. Steigt auf keiner der Netzwerkkarten über 700 KB / s. Selbst wenn ich eine Abfrage ausführe, die Megabyte an Daten anfordert, bleibt diese Zahl bei etwa 500 KB / s. Unsere Bandbreite beträgt 100 MBPS, und wir werden nicht einmal 1% davon nutzen. Ich denke, irgendwo sollte ein Limit konfiguriert sein, das die Größe der Pakete verringert oder die Übertragungsrate begrenzt. Die Hardware-Interrupts / Sek. Liegen bei 700-2000. Die Ausgabewarteschlange ist leer. Die maximale Auslastung der Netzwerkkarten liegt bei etwa 4%.
FranticRock
2
Möglicherweise besteht eine Nichtübereinstimmung zwischen der Geschwindigkeit der Netzwerkkarte und dem Switch-Port. Haben Sie Ihr Netzwerkteam beauftragt, es von der Switch-Seite aus zu betrachten?
jgardner04
2

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

alexei
quelle
Vielen Dank für die Info. Meine Antworten unten. 1. Richtig. Client-Tools wurden ebenfalls auf prod installiert, und dieselbe Abfrage, die ich erwähnt habe, benötigt 2 Sekunden, um alle 30.000 Datensätze (insgesamt 4 MB Größe) zurückzugeben. Die von mir verwendete Abfrage ist übrigens nur ein Beispiel. Es ist keine echte Geschäftsabfrage. Es ist nur ein Mittel, um 4 MB Daten aus einer Tabelle zu erhalten. Wir haben derzeit ein Leistungsproblem beim Lesen mehrerer Megabyte Daten aus einer Tabelle mit einer aktuellen Abfrage.
FranticRock
2. Die Verbrauchszeit war knapp, wenn nicht dieselbe wie die der gleichen Abfrage, die lokal über die PROD-Box ausgeführt wurde. (IE 2 Sekunden) 3. Richtig 1 Minute 8 Sekunden ist die Ausführungszeit. Diese Zeit variiert zwischen verschiedenen Client-Computern. Von unserer Entwicklungsmaschine (viel weiter entfernt als die Bühnenmaschine) habe ich diese Abfrage 8 Mal hintereinander ausgeführt, und die Zeit lag zwischen 11 Sekunden und 22 Sekunden. (Durchschnitt 18 Sek.)
FranticRock
aus unserer dev box tracert Prod_IP_Address 1 53 ms 52 ms 53 ms SQL2008 Von der Bühnenmaschine beträgt die Zeit konstant über 1 Minute. tracert Prod_IP_Address tracert: 1 1 ms <1 ms <1 ms SQL2008 Vom Produktionswebserver: Die Ausführungszeit beträgt 53 Sekunden. Tracert: 1 1 ms <1 ms <1 ms SQL2008
FranticRock
4. Die obere Spalte "Client-Ausführungszeit" ist nur die Ortszeit des Computers (IE: 15:30:00). 5. Das Problem tritt auf jedem Computer auf, der auf den Produktions-DB-Server trifft, einschließlich auf unserem Produktions-Webserver. 6. Die Ping-Verzögerung von der Stage-Box zur Prod-SQL-Box beträgt <1 MS. 7. Siehe oben. 8. Leider existiert das alte Netzwerk nicht mehr.
FranticRock
Es ist wirklich interessant, dass DEV zwar 53 MS pingt, die Ausführung der Abfrage jedoch nur 11 bis 22 Sekunden dauert. Während Stage 1 MS anpingt, dauert es mehr als 1 Minute, um die Daten zurückzugeben. Dev ist auch geografisch viel weiter entfernt. Und die Bühne ist direkt neben der Prod-Box und dauert doch viel länger.
FranticRock