5
SQL Server 2008 R2 Query auf mehrere kerne verteilen
Hallo, habe ein performance Problem auf einem MS SQL Server 2008 R2
Hallo,
Wie schon in Vorwort gesagt ich habe ein performance Problem auf einem MS SQL Server 2008 R2.
Ich muss eine relativ grosse Query absetzen die eine View erzeugt und per insert befehl die Daten in eine Tabelle schreibt und dabei noch einige String Operationen ausführt.
Die Query läuft dabei bis zu 13h - ich sollte das aber in ca 1h schaffen. Als Hardware kommt ein i5 mit 4 cores und 2,9GH und 8GB RAM zum Einsatz - wir hatten aber auch schon grössere Server im Einsatz ohne nennenswerten performance Erfolg. Die Query lastet nämlich immer nur 1 der 4 Cores aus, obwohl dem SQL Server alle Kerne zugewiesen sind. Das lässt den Schluss zu, dass der SQL Server nicht parallelisiert, bzw. nicht auf 4 Kerne verteilt. Könnt ihr mir sagen wie/wo ich nachschauen kann ob er die Query wirklich nicht verteilt wird und mir einen Lösungsansatz verraten wie ich ihn dazu bringe das ganze zu parallelisieren - bzw. auf alle 4 Kerne zu verteilen.
Die Installation ist komplett Standard ohne Modifikationen bisher.
Danke schon mal für eure Antworten,
Gruss, Marcel
Hallo,
Wie schon in Vorwort gesagt ich habe ein performance Problem auf einem MS SQL Server 2008 R2.
Ich muss eine relativ grosse Query absetzen die eine View erzeugt und per insert befehl die Daten in eine Tabelle schreibt und dabei noch einige String Operationen ausführt.
Die Query läuft dabei bis zu 13h - ich sollte das aber in ca 1h schaffen. Als Hardware kommt ein i5 mit 4 cores und 2,9GH und 8GB RAM zum Einsatz - wir hatten aber auch schon grössere Server im Einsatz ohne nennenswerten performance Erfolg. Die Query lastet nämlich immer nur 1 der 4 Cores aus, obwohl dem SQL Server alle Kerne zugewiesen sind. Das lässt den Schluss zu, dass der SQL Server nicht parallelisiert, bzw. nicht auf 4 Kerne verteilt. Könnt ihr mir sagen wie/wo ich nachschauen kann ob er die Query wirklich nicht verteilt wird und mir einen Lösungsansatz verraten wie ich ihn dazu bringe das ganze zu parallelisieren - bzw. auf alle 4 Kerne zu verteilen.
Die Installation ist komplett Standard ohne Modifikationen bisher.
Danke schon mal für eure Antworten,
Gruss, Marcel
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 164727
Url: https://administrator.de/contentid/164727
Ausgedruckt am: 22.11.2024 um 09:11 Uhr
5 Kommentare
Neuester Kommentar
Moin Marcel,
bisschen dünne Angaben für eine zielführende Antwort, meinst du nicht?
Sind denn alle Voraussetzungen erfüllt bzw. gegeben, dass diese Abfrage parallelisiert abgekaspert werden kann?
Ist der TEMP-Tablespace auch auf 4 (also Anzahl Prozessoren) data files aufgeteilt?
Wie gross ist die "sort area"?
Wo verbrennt denn die Query die Zeit - beim Sort, beim Seitenladen oder wo?
Was sagen EXPLAINs, was sagen Optimizer?
Werden die richtigen Zugriffspfade gefunden oder wenigstens erzwungen?
Bei den 13h - wieviel davon ist CPU-Zeit, wieviel ist IO-Geswappe?
Ein SQL zu tunen mit schnellerem Prozessor oder mehreren davon... mag sich gut anhören.
Aber eine Query, die 13h läuft... das ist absolut indiskutabel.
Das hört sich für mich mit Verlaub gesagt eher wie ein Designfehler an.
Grüße
Biber
bisschen dünne Angaben für eine zielführende Antwort, meinst du nicht?
Sind denn alle Voraussetzungen erfüllt bzw. gegeben, dass diese Abfrage parallelisiert abgekaspert werden kann?
Ist der TEMP-Tablespace auch auf 4 (also Anzahl Prozessoren) data files aufgeteilt?
Wie gross ist die "sort area"?
Wo verbrennt denn die Query die Zeit - beim Sort, beim Seitenladen oder wo?
Was sagen EXPLAINs, was sagen Optimizer?
Werden die richtigen Zugriffspfade gefunden oder wenigstens erzwungen?
Bei den 13h - wieviel davon ist CPU-Zeit, wieviel ist IO-Geswappe?
Ein SQL zu tunen mit schnellerem Prozessor oder mehreren davon... mag sich gut anhören.
Aber eine Query, die 13h läuft... das ist absolut indiskutabel.
Das hört sich für mich mit Verlaub gesagt eher wie ein Designfehler an.
Grüße
Biber
Hallo Biber,
Danke für deine Antworten. Ich habe das Problem jetzt ein wenig genauer Analysiert und bin auf ein interessantes Phänomen gestossen.
Im Zuge der Query die mehere SQL Statements abschickt baue ich eine View in 4 Tranchen auf. Dazu Teile ich eine Tabelle in 4 Teile und lasse die 4 Teile nacheinander durch das gleiche SQL Statement laufen. Beim 1. Durchlauf dauert das ganze ca 25 Minuten, bei den Tranchen 2-4 ca 3.5 Stunden. Der Fehler kann nicht in den Daten liegen, da es egal ist welche Tranche ich als Erste laufen lasse - also zB die 3. Tranche als erste - diese ist immer so schnell. Ein RAM Problem habe ich auch ausgeschlossen, ich weise dem SQL Server 32GB zu, von denen er sich aber nur 17GB nimmt.
Hast du vielleicht eine Idee an was diese komische Laufzeitvergrösserung liegen könnte?
Danke & Gruss
Danke für deine Antworten. Ich habe das Problem jetzt ein wenig genauer Analysiert und bin auf ein interessantes Phänomen gestossen.
Im Zuge der Query die mehere SQL Statements abschickt baue ich eine View in 4 Tranchen auf. Dazu Teile ich eine Tabelle in 4 Teile und lasse die 4 Teile nacheinander durch das gleiche SQL Statement laufen. Beim 1. Durchlauf dauert das ganze ca 25 Minuten, bei den Tranchen 2-4 ca 3.5 Stunden. Der Fehler kann nicht in den Daten liegen, da es egal ist welche Tranche ich als Erste laufen lasse - also zB die 3. Tranche als erste - diese ist immer so schnell. Ein RAM Problem habe ich auch ausgeschlossen, ich weise dem SQL Server 32GB zu, von denen er sich aber nur 17GB nimmt.
Hast du vielleicht eine Idee an was diese komische Laufzeitvergrösserung liegen könnte?
Danke & Gruss
Moin Marcelg,
aus dem Bauch heraus ist für mich folgende Erklärung die naheliegendste:
Beim ersten Durchlauf "lernt" der Optimizer, was und welches für ihn die günstigsten Zugriffspfade sind. Also ob ein Index genutzt wird oder ein Full-Table-Scan "effizienter" ist, welche Tabelle bei einem Join der Master und welche Child ist etc.
Möglicherweise schreibt er dazu auch Statistiken, um seine Zugriffe beim nächsten Mal aufgrund dieser "Erfahrungen" zu entscheiden.
Wären keine Statistiken, keine Erfahrungswerte da, dann würde er auch wie beim allerersten Mal die DEFAULT-Werte nehmen, also nur aufgrund der Datengröße/Datensatzanzahl pauschalieren.
Vermutlich sind die vier Viertel, in die du deine View-Befüllung unterteilt hast, eben inhaltlich NICHT sehr, sehr ähnlich.
Das heisst, die Statistiken, die für das erste (oder ein beliebiges) Viertel berechnet werden für den optimalen Zugriffspfad sind nicht auf ein anderes Viertel übertragbar.
--> dann müsstest du dem Datenbankblech sagen, dass die Daten volatile sind -->ist neudeutsch für "jedesmal anders, immer wieder zufällig"
So etwas kann sein, wenn die INPUT-Tabellen für den View z.b stark im Volumen oder der Kardinalität schwanken, z.B. öfters geleert/neu erzeugt werden.
Aber ist alles Spekulation ->da müsstest du schon mal selber versuchen, den Hintergrund dieser Tabellen-in-View-Drück-Mimik zu beschreiben.
Grüße
Biber
aus dem Bauch heraus ist für mich folgende Erklärung die naheliegendste:
Beim ersten Durchlauf "lernt" der Optimizer, was und welches für ihn die günstigsten Zugriffspfade sind. Also ob ein Index genutzt wird oder ein Full-Table-Scan "effizienter" ist, welche Tabelle bei einem Join der Master und welche Child ist etc.
Möglicherweise schreibt er dazu auch Statistiken, um seine Zugriffe beim nächsten Mal aufgrund dieser "Erfahrungen" zu entscheiden.
Wären keine Statistiken, keine Erfahrungswerte da, dann würde er auch wie beim allerersten Mal die DEFAULT-Werte nehmen, also nur aufgrund der Datengröße/Datensatzanzahl pauschalieren.
Vermutlich sind die vier Viertel, in die du deine View-Befüllung unterteilt hast, eben inhaltlich NICHT sehr, sehr ähnlich.
Das heisst, die Statistiken, die für das erste (oder ein beliebiges) Viertel berechnet werden für den optimalen Zugriffspfad sind nicht auf ein anderes Viertel übertragbar.
--> dann müsstest du dem Datenbankblech sagen, dass die Daten volatile sind -->ist neudeutsch für "jedesmal anders, immer wieder zufällig"
So etwas kann sein, wenn die INPUT-Tabellen für den View z.b stark im Volumen oder der Kardinalität schwanken, z.B. öfters geleert/neu erzeugt werden.
Aber ist alles Spekulation ->da müsstest du schon mal selber versuchen, den Hintergrund dieser Tabellen-in-View-Drück-Mimik zu beschreiben.
Grüße
Biber
Hallo Biber,
Das klingt für mich nach einer vernünftigen Erklärung. Ich würde dies gerne Ausprobieren - kannst du mir sagen wo ich die Einstellungen finde mit dem ich dem SQL Server 2008 R2 sagen kann dass die Daten volatil sind?
Danke schon mal & Grüsse
Das klingt für mich nach einer vernünftigen Erklärung. Ich würde dies gerne Ausprobieren - kannst du mir sagen wo ich die Einstellungen finde mit dem ich dem SQL Server 2008 R2 sagen kann dass die Daten volatil sind?
Danke schon mal & Grüsse
Moin Marcelg,
der SQLServer ist nicht mein Fachgebiet.
Über eine beliebte Suchmaschine konnte ich mir eben zumindest zusammenreimen, dass beim M$SQLServer das Wort "volatile" (fast?) immer nur gebraucht wird als Synonym für (global) temporary tables.
Die sind zwar auch volatil (es werden keine Statistiken gepflegt, weil unsinnig), aber die meinte ich nicht.
Ich kann dich nur auf den beschwerlichen Weg der Suchmaschinenbefragung lenken, Suchbegriffe "Optimizer Hints" ,"(view) Query Optimization" plus "mssqlserver".
Bitte auch nicht ganz vernachlässigen, dass ich viel, viel weiter oben auch schon locker angefragt habe, inwieweit das Tuning/die eXplains zu der Query erfolgt sind.
Bei Querys ist es immer ein bisschen unkalkulierbar, versuchsweise an verschiedenen Rädchen zu drehen ohne begründete Indizien.
Grüße
Biber
der SQLServer ist nicht mein Fachgebiet.
Über eine beliebte Suchmaschine konnte ich mir eben zumindest zusammenreimen, dass beim M$SQLServer das Wort "volatile" (fast?) immer nur gebraucht wird als Synonym für (global) temporary tables.
Die sind zwar auch volatil (es werden keine Statistiken gepflegt, weil unsinnig), aber die meinte ich nicht.
Ich kann dich nur auf den beschwerlichen Weg der Suchmaschinenbefragung lenken, Suchbegriffe "Optimizer Hints" ,"(view) Query Optimization" plus "mssqlserver".
Bitte auch nicht ganz vernachlässigen, dass ich viel, viel weiter oben auch schon locker angefragt habe, inwieweit das Tuning/die eXplains zu der Query erfolgt sind.
Bei Querys ist es immer ein bisschen unkalkulierbar, versuchsweise an verschiedenen Rädchen zu drehen ohne begründete Indizien.
Grüße
Biber
