SQL Performance

Hallo zusammen,

ich brauche eure Erfahrungstips bezüglich SQL.

In der letzten Zeit leidet meine SQL-Datenbankserver so sehr wie ihr auf das Bild sehen konnt.

SQLPerformance.jpg

SQLPerformance2.jpg

Wenn ihr die Bilder sieht, was würdet ihr denn sagen und welche Massnahmen würdet ihr nehmen?

Danke im voraus.

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Zuletzt geändert von navsyst am 12. März 2012 17:34, insgesamt 1-mal geändert.

Aus den Bildern allein wird man nicht schlau. Wichtig wäre jetzt eher zu nennen, wie die Hardware aufgebaut ist und wie viele aktive Nutzer ihr habt. Habt ihr schon mal über einen längeren Zeitraum Monitoring betrieben?

Interessant wäre zusätzlich was da soviel CPU frisst, der SQL-Server scheint ja lediglich 2% zu benötigen.
Liegt das jetzt lediglich an dem Zeitpunkt des Screenshots oder ist da evtl eine andere Anwedung die die ganze Maschine ausbremst?

@Sebastian: Die Hardware für SQL-Database:
1 virtuelle CPU 2.4 GHz Intel Xeon 5140
4 GB Arbeitsspeicher
C: 16 GB OS Partition
D: 400 GB DB Partition

Aktive Nutzer jeden Tag zwischen 70 bis 86.

Wie würdest du Monitoring betreiben?

@Danjo: ja. Aus mein Screenshot kannst du sehen wie die Performance ganze Zeit stark schwanken. Das würde ich auch gern wissen welche Anwendung die ganze Maschine ausbremst. Ich denke dass ich einen Server-Spezialist zu uns holen soll.

Einen Spezialisten dazu holen ist nie verkehrt.
Was ich sehe, aber nichts sagen muss ist die Tatsache das ihr virtualisiert.
Je nach Virtualisierungslösung kann es daran liegen. Das SQl-Server virtuell nie die selbe Leistung erzielen wie ein hardwaretechnisch "identischer" nicht virtueller Server ist ja hinreichend getestet worden, aber das du so Schwankungen in der Auslastungsanzeige hast kommt denke ich nicht daher.

@Sebastian: Die Hardware für SQL-Database:
1 virtuelle CPU 2.4 GHz Intel Xeon 5140
4 GB Arbeitsspeicher
C: 16 GB OS Partition
D: 400 GB DB Partition

Aktive Nutzer jeden Tag zwischen 70 bis 86.

Ich persönlich würde bei der Anzahl Nutzer den RAM vervierfachen.

Grundsätzlich sollte der SQL Server nicht virtualisiert werden. Und wenn dann bitte etwas mehr Leistung zuweisen.

Hi,

Lass Dir doch mal als erstes die Prozesse aller User anzeigen. Außerdem Was ist FSM32 und FSMA32?

Volker

@vsnase: was meinst du mit Prozesse? Habe ich doch Bilder angehängt?
fsma32 ist Virenscanner software. FSecure. Habe ich heute erstmal für eine Woche deaktivieren lassen um zu schauen wie die Auslastung ist.

Hi,

Lass Dir doch mal als erstes die Prozesse aller User anzeigen. Außerdem Was ist FSM32 und FSMA32?

Volker

Das müssten die DIenste des Virenscanner sein.
Dieser dursucht hoffentlich nicht die Datenbankdateien nach Viren.

edit: Jupp, Virenscanner :)
Was er meint ist die kleine Checkbox unten im Taskmanager

Was er meint ist die kleine Checkbox unten im Taskmanager

AHA... ist mir nie aufgefallen :)

Ok... habe ich den Checkbox gesetzt... und dann? Sehe ich keine Unterschied...

[McClane]

Grundsätzlich sollte der SQL Server nicht virtualisiert werden. Und wenn dann bitte etwas mehr Leistung zuweisen.

Ich habe vor zweite CPU reinzubauen. Wird es helfen?

Zuletzt geändert von McClane am 8. März 2012 09:38, insgesamt 1-mal geändert.
Grund: Quote-Bereich korrigiert

Virenscanner habe ich ja schon fast befürchtet. Wenn der dann die Log-Dateien vom SQL überwacht, wundert mich nix.

Aber mir fällt noch was auf:
- Wenn man schon den SQL Virtualisiert, dann kann man den Log-Dateien doch eine eigene Partition spendieren.
- sind die HDD des virtuelln SQL echte Platten oder virtuelle Platten? Falls virtuell, stehen die auf dynamisch vergrößern?

Volker

Virenscanner habe ich ja schon fast befürchtet. Wenn der dann die Log-Dateien vom SQL überwacht, wundert mich nix.

Aber mir fällt noch was auf:
- Wenn man schon den SQL Virtualisiert, dann kann man den Log-Dateien doch eine eigene Partition spendieren.
- sind die HDD des virtuelln SQL echte Platten oder virtuelle Platten? Falls virtuell, stehen die auf dynamisch vergrößern?

Volker

OK. Virenscanner habe ich ausgeschaltet. Werde ich weiterhin beobachten.
Zu Log-Dateien: Ich weiss nicht ob ich entscheidende Fehler gemacht habe oder nicht. Der Datenbank und Log-Dateien habe ich in gleichem Verzeichnis abgelegt. Ist das schlimm? Was ist der Vorteil mit eigene Partition? Kann ich jetzt noch ändern?
Die Platten ist auch virtuell. die stehen auf dynamisch. Allerdings fällt mir jetzt was auf:
NavProd_Data: Initial Size 50 GB. By 10 percent, unrestricted growth
NavProd_Log: Initial Size 22 GB. By 10 percent, restricted growth to 2097152 MB ---> was passiert wenn 2097152 MB erreicht wird? Aktuelle Größe ist 21,4 GB.
Wird es ständig vergrößert?

Was ich dir noch nahe legen kann:
http://www.stryk.info/performance_check.html

Dir ist klar, dass die virtuellen Platten dauernd vergrößerte werden? Das das Rechenleistung und solche Zacken verursacht ist doch bestimmt auch einleuchtend.

SQL-Logs gehören eigentlich auf eine eigene Platte(!). Logs werden nur (fortlaufend) geschrieben und dann muss der Lese/Schreibkopf der Platte nicht dauernd neu positionieren.

Die Vergrößerung von SQL Daten und Log sollte in fester Größe und nicht prozentual erfolgen und so dimensioniert sein, dass nict jede Woche eine neue Vergrößerung notwendig ist. Das führt sonst zu fragmentieren Dateien und behindert die Abfrage-Performance des SQL-Server.

Volker

Hallo,
also wir setzen unser Dynamics NAV auf einen virtuellen SQL Server ein, dieser hat aber 4 CPUs und 8GB RAM, bei im Moment noch ca 20 User (Endausbau 80-100). Wir haben keinerlei Probleme mit dem virtuellen Server, alle unsere Server sind virtuell, allerdings haben wir auch ein vCenter 5 auf einer großen ESX Server (32 CPU Kerne und 128 GB RAM) mit einem SAS.
Ich weiß nur, das es keinerlei Probleme mit einem virtuellen SQL Server gibt, hauptsache die CPU Kerne und RAM ist genügend da. Der MS SQL Server verteilt seine Arbeit auf die CPU Kerne und Puffert sehr viel im RAM (tempory tables etc) wenn er kann. Sonst muss er, wie das Betriebsystem auch, auf die Festplatte speichern und das ist ja immer ein Flaschenhals.
MfG
Ralf

Also der RAM und die Kerne sind schon sehr dürftig ... bei der Ausstattung könnte mein privater Rechner vermutlich mithalten.

Wie schon hier gefragt wurde: Wie sind die Platten angebunden?

Monitoring kann man unter anderem mit Perfmon (WMI) durchführen. Natürlich muss man die Werte auch interpretieren können.

Die Platten ist auch virtuell. die stehen auf dynamisch. Allerdings fällt mir jetzt was auf:
NavProd_Data: Initial Size 50 GB. By 10 percent, unrestricted growth
NavProd_Log: Initial Size 22 GB. By 10 percent, restricted growth to 2097152 MB ---> was passiert wenn 2097152 MB erreicht wird? Aktuelle Größe ist 21,4 GB.
Wird es ständig vergrößert?

Wie groß ist den deine Datenbank z.Zt. d.h. in Fin 'Datei/Datenbank/Informationen/Datenbank belegt'

Optimal ist beim SQL-Server eine für SQL verfügbare Arbeitsspeichergröße nahe an der Datenbankgröße.

Wie sind denn die Platten angebunden?

Ich vermute mal Ihr quält euch schon etwas länger mit der Performance des Systems herum!?

Gruß, fiddi

Zunächst erstmal Danke für alle Rückmeldungen. Sieht echt übel aus.

Wie groß ist den deine Datenbank z.Zt. d.h. in Fin 'Datei/Datenbank/Informationen/Datenbank belegt'

19787904 KB (39%) von 51200000 KB
Objekt Cache 32000 KB

Optimal ist beim SQL-Server eine für SQL verfügbare Arbeitsspeichergröße nahe an der Datenbankgröße.

Arbeitsspeichergröße nahe an der Datenbankgröße ???? Wie verstehe ich das? Arbeitspeicher?

Wie sind denn die Platten angebunden?

Ich warte noch auf Antwort von unsere IT-Abteilung

Ich vermute mal Ihr quält euch schon etwas länger mit der Performance des Systems herum!?

So ist es.. das Problem ist dass wir der einzige Unternehmen von diesen Konzern, die Navision einführt. Der Konzern hat SAP :) Unsere IT-Abteilung hat keine Ahnung von Navision. Von unsere Nav-Partner ist die Unterstützung bezüglich Hardware und Installation auch sehr bedürftig.

Dir ist klar, dass die virtuellen Platten dauernd vergrößerte werden? Das das Rechenleistung und solche Zacken verursacht ist doch bestimmt auch einleuchtend.

SQL-Logs gehören eigentlich auf eine eigene Platte(!). Logs werden nur (fortlaufend) geschrieben und dann muss der Lese/Schreibkopf der Platte nicht dauernd neu positionieren.

Die Vergrößerung von SQL Daten und Log sollte in fester Größe und nicht prozentual erfolgen und so dimensioniert sein, dass nict jede Woche eine neue Vergrößerung notwendig ist. Das führt sonst zu fragmentieren Dateien und behindert die Abfrage-Performance des SQL-Server.

Volker

Hallo Volker,
was kann oder soll ich ändern bei dieser Einstellung:
NavProd_Data: Initial Size 50 GB. By 10 percent, unrestricted growth, Path: D:\DB\NavProd
NavProd_Log: Initial Size 22 GB. By 10 percent, restricted growth to 2097152 MB, Path: D:\DB\NavProd

Danke im voraus.

was kann oder soll ich ändern bei dieser Einstellung:
NavProd_Data: Initial Size 50 GB. By 10 percent, unrestricted growth, Path: D:\DB\NavProd
NavProd_Log: Initial Size 22 GB. By 10 percent, restricted growth to 2097152 MB, Path: D:\DB\NavProd

Leider das Betriebssystem!!! und die Hardware!???.

Mit der Maschine wirst du keine Performance- Steigerung mehr hin bekommen. Wenn jemand eine Rechnung bucht steht der Laden wahrscheinlich, und es dauert gefühlte Ewigkeiten bis das erledigt ist.

Die DB- Vergrößerung sollte, wie Volker schon sagte, in fester Größer erfolgen, und zwar in ausreichend großen Schritten, die für einen längeren Betrieb (mehrere Monate) ohne DB- Vergrößerung ausreichen.

Arbeitsspeichergröße nahe an der Datenbankgröße ???? Wie verstehe ich das? Arbeitspeicher?

Bei eurer jetzigen DB- Größe von ca. 20GB wäre ein für den SQL-Server- Dienst verfügbarer Arbeitsspeicher von 20 GB und mehr optimal.

D.h. in eurem Fall ein 64Bit Betriebssystem Windows 2008 mit SQL- Server 2008. Wobei der Server mindestens 24 GB Arbeitsspeicher haben sollte (sofern er nur SQL macht, wenn es ein SBS mit Exchange und ähnlichem ist, natürlich mehr)

Optimal wäre natürlich ein dedizierter Server, bei dem sich die Hardware nicht auch noch mit anderen Dingen herumschlagen muss.

Die Hardware haben wir hier schon mehrfach besprochen mein Standard System sieht z.Zt. etwa so aus:

Server mit W2K8 64Bit und SQL-Server 2008 Standard, Arbeitsspeicher >=16GB, Festplatten 3x RAID1 SAS (System >146 GB {das System benötigt allein für die Auslagerungsdatei mindestens die Größe des Arbeitsspeichers, eher mehr}, Datenbank >=76GB, Log >=76GB) optional für zusätzliche Daten zusätzliche RAID1 Festplatten nach Bedarf. + Datensicherung LTOx nach Bedarf (keine USB- Platte, die meisten Server haben noch kein USB3, USB2- Platten wären bei dem Datenvolumen zeitlich überfordert)

Wie gesagt, das ist ein Basissystem. Wenn der SQL-Server mehrere SQL- DBs verarbeiten muss (Test, Entwicklung,Echsystem) müssen die Parameter natürlich noch nach oben hin angepasst werden. Die Festplatten sollten nie zu mehr als 80% ausgelastet werden, da sonst NTFS- Performance- Probleme bekommt. Die für Log und SQL- DB getrennte Platte ist auch aus Sicherheitsgründen sinnvoll, da so ein Hardwareausfall oder auch Dateisystemschaden abgefangen werden kann.

In einer virtuellen Umgebung mit evtl. angeschlossener Storage gilt ähnliches. Wichtig ist, das der SQL-Server möglichst ohne Behinderung, durch andere Programme oder Systeme (VMs) auf seine Daten zugreifen kann.

Wenn es um eine Auswahl geeigneter Systeme geht, sollten eure SAP- Leute dir evtl. weiterhelfen können, wenn Sie auch MS-SQL/Windows als Basis-System haben (die benutzen so etwas wie euren Server wahrscheinlich nicht mal mehr als Taschenrechner ).

Gruß, Fiddi

Ich würde als erstes zwei neue Platte erstellen lassen und diese mit je 50-100 GB feste Größe (keine dynmische Vergrößerung) anlegen und darauf die SQL-Logs und SQL-Daten verschieben. So wie ich das sehe muss euer viertueller Server dauert die Partion mit der DB und den Logs vergrößern.

Die Vergrößerung der SQL-Data und SQL-Log würde ich auf xxx MB festlegen, wobei xxx in etwa dem Zuwachs eines Jahres entspricht.

Ansonsten tut ein bischen mehr RAM bestimmt gut. Was mich allerdings wundert ist die Angabe Deiner Hardware und der Screenshot dazu. XEON 5140 läuft lt. Intel mit 2.33 und nicht mit 2.4. Außerdem hat der 2 Cores und Dein Screenshot zeigt nur einen. Ist das bewußt so eingestellt?

Volker

Ich würde als erstes zwei neue Platte erstellen lassen und diese mit je 50-100 GB feste Größe (keine dynmische Vergrößerung) anlegen und darauf die SQL-Logs und SQL-Daten verschieben. So wie ich das sehe muss euer viertueller Server dauert die Partion mit der DB und den Logs vergrößern.

Der benutzt z.Zt. 20 GB von seiner 50GB- Datenbank, der hat noch nicht, und muss auch noch nicht vergrößern. Wenn er sein Log immer korrekt gesichert hat, ist das LOG auch fast leer, also auch kein Problem.

Sein Problem ist sein Windows 2003- Server (scheint ja immerhin schon 64bit zu sein) mit nur 4GB Arbeitsspeicher, die kleine C:- Partition, die DB und LOG auf dem gleichen Laufwerk, und der VM-Server mit dem darunter liegenden Plattensystem und den ebenfalls noch laufenden VMs.

Gruß, Fiddi

Hi Fiddi,

Das glaub ich nicht. Da läuft ja nicht nur der Sql drauf, sondern offensichtlich noch weitere Programme (Virenscanner, Zeiterfassung, und weis der Geier was sonst noch). Von Sicherung hat er bis jetzt auch nix erzählt und in einem andern Thread fragt er nach SQL-Agent (mit mehreren NAV-Servern). Insgesamt glaube ich aber auch, dass der Rechner unterdimensioniert ist.

Volker

Das glaub ich nicht.

navsyst schreibt an anderer Stelle:

NavProd_Data: Initial Size 50 GB. By 10 percent, unrestricted growth
NavProd_Log: Initial Size 22 GB. By 10 percent, restricted growth to 2097152 MB ---> was passiert wenn 2097152 MB erreicht wird? Aktuelle Größe ist 21,4 GB.

Danach sind das für mich zwar nicht die Platten (er hat ja nur C: und D:), aber die Datenbankdateien.

und zum Thema Datenbankauslastung:

19787904 KB (39%) von 51200000 KB

Nach Adam Riese wurden die DBs mit 50 GB für Data (initial Size) und 22 GB für Log angelegt. Da die Datenbank z.Zt. 19,8 GB davon belegt, gehe ich davon aus, dass die DB noch nie vergrößert wurde, somit das auch noch kein Problem sein konnte.

Von Sicherung hat er bis jetzt auch nix erzählt und in einem andern Thread fragt er nach SQL-Agent (mit mehreren NAV-Servern)

Für die Sicherung muss man den SQL-Agenten nicht unbedingt einsetzen. Storages haben oft eigene Clients um die SQL- DB zu sichern.
Gruß, Fiddi