SQL-Skript in VM benötigt viel Zeit für die Ausführung

Question

Ich habe das Paket Execute SQL Script, das das Skript zum Einfügen von etwa 150K Datensätzen enthält.

Das Problem hier ist, wenn ich das Paket in der virtuellen Maschine ausführe, dauert es ca. 25 Minuten und das gleiche Paket in der physischen Maschine dauert 2 Minuten.

Frage 1? Warum dauert es so lange, die gleichen Daten in VM zu laden? Frage 2? Wie lässt sich dieses Leistungsproblem lösen?

Die Konfiguration des physischen Computers hat 4 GB Ram und 250 GB HD + Windows Server 2008 R2 + SQL Server 2008 R2 Standard Edition. Die virtuelle Maschine hat die gleiche Konfiguration

Update: Das Problem ist mit dem SQL Server in der VM.

Frage 1? Warum dauert es so lange, das gleiche Skript in VM auszuführen?

Frage 2? Wie lässt sich dieses Leistungsproblem lösen?

Die Datenbankschemata der physischen Maschine und der VM sind identisch. Andere Datenbanken sind ebenfalls identisch. Für diese Tabellen wurde auf beiden Rechnern keine Indizierung angewendet. Die Datentypen sind gleich. Die Festplatte hat, wie gesagt, die gleiche Konfiguration.

Auf beiden Rechnern wird kein RAID durchgeführt.

Physische Maschine hat die 2.67GHz RAM Quad Core und in der virtuellen Maschine hat die 2.00GHz RAM Quad Core

Version von SQL PM:

Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) Apr 2 2010 15:48:46 Copyright (c) Microsoft Corporation Standard Edition (64-bit) auf Windows NT 6.1 (Build 7601: Service Pack 1)

Version von SQL PM:

Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) Apr 2 2010 15:48:46 Copyright (c) Microsoft Corporation Standard Edition (64-bit) auf Windows NT 6.1 (Build 7601: Service Pack 1) (Hypervisor)

Ich habe das Skript ausgeführt Der Ausführungsplan für beide ist derselbe, da es keinen Unterschied im Plan gibt.

Anbieter ist HP ML350 Machine.

Es gibt fast 20 VMs auf demselben physischen Server, von denen 7 Server aktiv sind.

Answer 1

Es gibt einen Artikel über die richtige Einstellung der SQL-Konfiguration für eine VM-Implementierung hier: Bewährte Praktiken für SQL Server . Im Folgenden finden Sie einen Auszug aus dem Artikel, der jedoch noch weitere Tipps und einen guten Plan für Leistungstests enthält:

Probleme mit der Speicherkonfiguration sind die häufigste Ursache für SQL-Leistungsprobleme. In der Regel entstehen diese Probleme, weil der DBA beim VI-Administrator eine virtuelle Festplatte anfordert und der VI-Administrator das VMDK auf einer LUN platziert, die den Leistungsanforderungen des DBAs entsprechen kann oder auch nicht. Zum Beispiel:

1. VMDK-Dateien von VMs, die auf VMFS-Volumes ohne genügend Spindeln abgelegt sind.
2. Viele VMDK-Dateien auf einem einzigen VMFS-Volume, das mehr Spindeln verwenden könnte.
3. Die Datenbank und die Protokolldateien befinden sich auf derselben LUN, die, Sie ahnen es, mehr Spindeln benötigen könnte.

Dies mag für einige offensichtlich sein, aber dieses Problem tritt immer wieder auf. Der VI-Administrator sollte einige technische Aspekte kennen, die zum Verständnis und zur Vermeidung dieses Problems beitragen können:

1. Basierend auf den IO-Anforderungen der DB-Dateien, wird eine bestimmte Anzahl von Spindeln für diese Datei garantiert werden. Das bedeutet, dass das VMDK auf einem VMFS-Volume platziert werden muss, um die Anforderungen des SQL-Servers Anforderungen des SQL-Servers und allen anderen Anforderungen auf diesem Volume gerecht zu werden.
2. Vermischung von sequentieller Aktivität (z. B. Aktualisierung von Protokolldateien) und zufälliger Aktivität (z. B. Datenbankzugriff) führt zu einem zufälligen Verhalten. Dies bedeutet dass die LUN-Konfiguration in der vorvirtuellen physischen Umgebung für die konsolidierte Umgebung möglicherweise nicht ausreichend ist. Dies wird in Storage Performance erörtert: VMFS und Protokolle.
3. Wenn der Speicher die Anforderungen des SQL-Servers nicht erfüllt, wird die Geräte-Latenzzeit oder die Kernel-Latenz (Warteschlangenzeit) ansteigen. Lesen Sie mehr über diese Zähler in Analyse und Überwachung der Speicherleistung.

Answer 2

Die häufigste Ursache für dieses Problem ist ein Mangel an Arbeitsspeicher. Wenn Sie alles auf einem kleinen Rechner mit 4 GB RAM einrichten, ist das Ihr Problem.

Wenn Sie versuchen, diese 150k Zeilen in den Speicher zu laden (denken Sie daran, dass alles, was in SSIS geschieht, im Speicher stattfindet), werden viele dieser Zeilen von Ihrer Auslagerungsdatei verarbeitet.

Die Auslagerungsdatei auf Ihrer VM ist viel langsamer als die auf Ihrem physischen Rechner.

Um dieses Problem zu lösen, erhöhen Sie den Arbeitsspeicher Ihrer virtuellen Maschine.

Answer 3

Ich habe ein ähnliches Problem.

Zwei Client-Rechner (ein physischer und ein virtueller) führen einen Batch mit SQLCMD aus. Dieser Stapel ruft eine gespeicherte Prozedur auf einem physischen Server auf (es handelt sich also nicht um ein Speicherproblem, da die Ausarbeitung nur auf der Serverseite erfolgt).

Die Ausführung des Stapels auf dem physischen Rechner dauert 20 Minuten. Der von der virtuellen Maschine ausgeführte Batch dauert 1 Stunde und 20 Minuten.

Mit SQL Profiler habe ich festgestellt, dass im Falle einer langsamen Ausführung eine Warteart ASYNC_NETWORK_IO vorhanden ist.

Wahrscheinlich ist die virtualisierte Netzwerkschicht nicht optimiert.

Können Sie einen SQL-Profiler ausführen und prüfen, ob Sie den Wartetyp ASYNC_NETWORK_IO sehen?