Performance Analyse mit MSSQL 2s005

[kockiren]

Hallo liebe Leute,

ich habe derzeit nen Problem mit der Performanceanalyse unseres Servers. Wir haben in der letzten Zeit enorme Lastspitzen, also habe ich mal nen bissel geguckt und über die Leistungsanzeige festgestellt das die Last durch SQL Transactions normal ist, im durchschnitt 30 bis 50 und mal kleine Spitzen, was aber heftig ist, ist der Ausschlag durch die LokalerDatenträger\Übertragungen/s Annzeige, da geht es immer an der obergrenze zur sache, sind im durchschnitt, 400 übertragungen pro sekunde. Also habe ich den Filemon ausgepackt und nachgeschaut,wird alles von dem SQLServer in die datenbank datei verursacht, da kommen nach nen paar minuten 80.000 Einträge zu stande.

Wie kann ich denn nun feststellen welche Querys diese Zugriffe verursachen.

Welche Serverparameter braucht ihr um mir zu helfen?

8 cores, 16GB speicher, MSSQl 2005 und win2003. Noch mehr?

VG
rené

[kockiren]

Hallo und guten Morgen,

also ich habe nun folgendes gemacht, ich habe den Wiederherstellungsmodus auf einfach gestelle und das transaktionsprtotokoll mit DUMP TRANSACTION <db_name> WITH NO_LOG das transaktionsprotokoll gelöscht, danach sind zumindest die I/O Spitzen abgefallen und ich habe beiweiten nicht mehr so viele Spitzen drin. Dennoch würd ich gern herrausfinden wie ich an die verursacher komme. Also wie kann ich in einer MSSQL DB herrausfinden wer welche I/O Spitzen verursacht. Oder verstehe ich den Counter: Logischer Datenträger\Übertragungen /s falsch?

Ausserdem habe ich noch eine unklarheit mit dem Unterschied zwischen SQLServer:Transaktionen\Transaktionen und SQLServeratenbank\Transaktionen pro sek. bei den Transaktionen befinde ich mich bei ca. 25 im durchschnitt und bei den Datenbank Transaktionen bei ca. 170 mit max bei 1000.

Mein DB Server krallt sich 75% der 16GB Hauptspeicher, was ja so weit ich das weiß auch richtig ist, da er sich ja cachet bis der Speicher bis x% voll ist.

Hat irgendjemand nen Tipp wie ich das weiter eingrenzen kann, welche Abfrage diese I/O Spitzen ziehen und wie man den Speicher nen bissel runter bekommt.

VG
René

[O. Helper]

Hallo René,

wenn hohe "LokalerDatenträger\Übertragungen/s" vorliegen, scheint der Sql Server häufig auf die Datenbankdateien zugreifen zu müssen und kann die Transaktionen nicht aus dem Cache bedienen.

Es gibt mehrere Ansätze, das zu ergründen.
Profiler: Du kannst über den "SQL Profiler" mitloggen lassen, welche Statements etc. von den Clients an den Server gesendet werden. Den Profiler kannst Du zum einen auf die Ereignisse filtern wie TSQL-SQL:BatchCompleted sowie auf die Wert, zum Beispiel auf "Duration" in Millisekunden; darüber kannst Du auf langlaufende Statements filtern.
Der Trace des Profiler verursacht aber wieder Last auf dem Server, also sinnig einsetzen.

Dann gibt es im Sql Server eingige Statistiken in dem DMV (Dynamic Management Views), die die Ausführungszeiten etc. unterstützt, ich werde da noch ein paar Statements zusammenstellen.

Wenn Du aktuell mal einen Fall von Last bemerkst, kannst Du den Übeltäter mit dem Script ermitteln.
IO und CPU Auslastung durch einzelne Prozesse

[kockiren]

Hallo und vielen Dank für deinen Tipp,

ich konnte es schaffe die I/O Last etwas runter zu bekommen, ich habe den Widerherstellungsmodus auf einfach gesetzt und das Transaktionsprotokoll abgeschaltet. Nun ist die I/O Last auf nem ordentlichen Level und dafür schlägt nun der "SQLSERVERatenbank\Transaktionen/ sek" Counter ordentlich aus, aber das ist ja erstmal nicht schlimm, heißt ja nur das nun alle Abfragen durch kommen.

Mit dem Profiler ist das ja echt ne super Sache, dann kann man in Verbindung mit dem PerformanceCountern und dem Processexplorer schon schön auf spurensuche gehen :-)

Vielen lieben Dank nochmal.

Gruß
René

[kockiren]

Hallo nochmal,

ich würde den Thread gern noch mal aufwärmen :-) Nach meinen letzten Anpassung lief die DB kurzzeitig ganz gut und der RAM Verbrauch ist auf 8GB runter.

Ich habe aber in den letzten Tagen beobachtet das der RAM verbrauch wieder hochging und die CPU Auslastung auch wieder steigt. Ich hab gleich wieder den SQL Profiler angeschmissen und mir nach CPU und READS > 1000 gesucht und stoße immer wieder auf folgende 2 Ereignisse, ungefähr 500 pro Minute "Audit Logout" und ein exe Aufruf für unsere Anwendung. Das mit unserer Anwendung seh ich mir mal im Detail an, aber ich komm mit diesen Audit Logouts nicht weiter. Eigentlich ist es ja nix anderes als das die Verbindung immer wieder aufgebaut und geschlossen wird. Also ist doch anzunehmen das es sich um einen Fehler in der Anwendung handelt. Ich bin nun schon so weit das ich weiß das bei einer Anfrage an die DB über ASP ein Pool angelegt wird, dieser wird nach einem close() jedoch nicht geschlossen sondern bleibt bestehen, wenn man diesen nach einer gewissen Zeit nicht nutzt dann baut er sich ab.

Wo finde ich den nun Informationen wie ich diese Pools richtig und DB Leistungsoptimiert nutzen kann?

Hat jemand irgendeinen Tipp?

Gruß
René

[O. Helper]

Hallo René,

beobachtet das der RAM verbrauch wieder hochging

Das ist völlig normal, der Sql Server allociert den Speicher, den er braucht und gerade frei ist; freiwillig gibt er erst mal nichts wieder frei. Das erfolgt erst, wenn andere Apps Speicher anfordern.
Viele "Audit Login/Logout" sind durchaus auch normal bei "modernen" Applikationen, die nicht permanent eine Connection offen halten; das sind vor allem "Zustandlose Applikationen", wie WebApps/-Sites. Diese Events sind noch kein Hinweis darauf, das die Connection aus den Pool entfernt wurden.

Welche genaue Probleme gibt es aktuell den noch?

Wie Dir jeder Arzt sagen wird, sind Fern-Diagnosen schwierig und deswegen macht es kein Meduziner.

Lange Laufzeiten und der daraus resultierenden Last können fehlende Indizes sein.
Aus Erfahrung ist das häufiges Problem schlicht weg schlechte Programmierung; wie Server-Round-Trips und ähnlich unkluge Dinge.
Wie gesagt, ist nicht ganz einfach, den auf die Spur zu kommen; man muss alles von links bis rechts beleuchten.