Performanceprobleme bei Planungsläufen

[Knorkator 12]

Hallo,

 

vorab: Ich bin bei uns nicht für den SQL Server oder die ERP Software zuständig, jedoch für die Hardware, AD und Exchange.

Ich bitte also um etwas Nachsicht bzgl. fehlendem SQL Wissens.

 

Wir haben hier einen Server 2008R2 mit MS SQL 2008R2 im Einsatz auf dem eine ca. 45GB ERP DB (MS NAV) große DB läuft.

 

Hardware:

Fujitsu TX300 S5 mit:

2x Xeon X5560

24GB RAM

2x 512MB Raid Controller

Controller 1 mit versch. Raid für OS und SQL Logfiles

Controller 2mit  4x Raid-1 mit je 2x 74GB 15K

Die Produktionsdatenbank liegt auf den 4 Raid-1 "Platten" von Controller 2.

 

Nun ist es so, dass unsere Arbeitsvorbereitung mehrfach pro Woche sog. Planungsläufe durchführt.

Die Durchlaufzeiten dieser Planungsläufe dauern so zwischen 5 und 10 Minuten und belasten das System recht stark (CPU Auslastung bei ca. 50-60%)

 

 

In den letzten Tagen haben die Mitarbeiter der AV mehrfach Probleme gemeldet, das System würde während des Planungslaufes "hängen" oder nicht reagieren.

 

Ich habe mir mal die Warteschlangenlänge während eines Planungslaufes angeschaut.

Maximaler Wert auf Laufwerk F: betrug 14, auf den anderen Laufwerken nur 1-2.

 

Mir ist bei vorherigen "Analysen" bereits aufgefallen, das die Datenbank scheinbar ungünstig verteilt ist.

f:\ produktion1_data.ndf mit 24,5GB

g:\produktion2_data.ndf mit 4,9GB

h:\produktion3_data.ndf mit 6,3GB

i:\produktion4_data.ndf mit 8,3GB

 

Weiterhin ist mir aufgefallen, dass die sqlserver.exe knapp 22GB der verfügbaren 24GB einnimmt und lt. Ressourcenmonitor nur 22MB frei hat - sofern der Wert "Freigabe möglich" dies korrekt wiedergibt.

Hat jemand einen Tipp, mit welchem Leistungsindikator ich testen kann, ob eine Speicheraufrüstung sinnvoll ist?

 

Ist es möglich, die Datenbank gleichmäßig auf die 4 Plattensysteme zu verteilen?

 

Mir ist klar dass es verschiedene Ursachen für die Performanceprobleme geben kann, der Aufbau der DB oder der Prozess des Planungslaufes.

Ich möchte zumindest die Dinge abklären, die in meinen Aufgabenbereich fallen.

 

 

Bin für jeden Tipp dankbar

Danke im voraus!

 

 

 

 

 

[Dukel 454]

Zu den Datenfiles:

https://blogs.technet.com/technet_blog_images/b/sql_server_sizing_ha_and_performance_hints/archive/2012/02/09/sql-server-2008-trace-flag-t-1117.aspx

[Knorkator 12]

Hallo Dukel,

 

danke für den Link.

Liest sich plausibel und wird mit in die Planung aufgenommen.

 

Hast Du noch einen Tipp, wie man die bestehenden DB gleichmäßig verteilen kann?

 

Danke

[Dukel 454]

Es kommt drauf an, wie die Datenbank intern aufgeteilt ist.

Wenn es eine Filegroup gibt mit allen 4 Dateien drin hilft mein Link.

Wenn es unterschiedliche Filegroups gibt und Tabellen in unterschiedlichen FG's gespeichert sind kann man nicht viel machen.

[Daniel -MSFT- 129]

Der Hauptspeicherverbrauch ist auch normal. Der SQL-Server nimmt, was da ist. Warum sollte auch Speicher nicht genutzt werden? Wenn Du 32GB einbaust, dann würden die auch genutzt werden.

 

Die Geschwindigkeit erhöhen könntest Du mit RAID10 statt RAID1. Das gilt vor allem für die Transaktionslogs.

 

Ansonsten würde ich einen NAV-SQL-Spezialisten konsultieren, der schauen kann, ob man am SQL-Server oder der Datenbank Optimierungen vornehmen kann.

[Knorkator 12]

Hallo,

 

die 4 Dateien sind in einer Filegroup.

 

Das Transaktionsprotokoll ist ein Raid-10 aus 8x 74GB Platten und ist an Controller 1 angeschlossen.

 

Das sich der SQL alles nimmt, was er kriegen kann wusste ich. Das ist ja auch in Ordnung so.

Würde nur gerne herausfinden, ob es derzeit vielleicht zu wenig ist.

 

Werde die Informationen so an unseren NAV SQL zuständigen weiterleiten.

 

Hatte nur gehofft, dass ich selbst einiges mit den Indikatoren herausfinden kann.

Unser NAV Dienstleister hat nicht so den besten Ruf bei uns und wechseln kann man da ja auch nicht so einfach...

Insofern würde ich gerne schauen, welche Optimierungen wir ggf. selbst vornehmen können bzw. es so gut wie möglich analysieren und dann unserem Dienstleister vorlegen.

 

Danke für Eure Beiträge

 

 

 

 

[Doso 77]

Klar kann man das optimieren. nur muss man dazu Ahnung von der erp software oder/und sql server haben. erp software zu langsam ist ein ganz klassisches Thema für SQL Admins, das muss euer Dienstleister können.

[Knorkator 12]

Hallo,

 

ich habe eine 4h Leistungsüberwachung mit den Werten dieses Blogs durchgeführt.

 

http://blog.fumus.de/sql-server/2010/02/sql-server-monitoring-messen-der-leistung-mit-systemmonitor-wichtige-leistungsindikatoren/

 

Über 4 Stunden fällt auf, dass Laufwerk f: wesentlich mehr zu schaufeln hat als die anderen.

Max. Wert der Warteschlange von Laufwerk beträgt 9, der anderen Laufwerke nur 0.3

Der Durchschnitt liegt auch weit auseinander.

0,137 zu 0,012/0,006/0,005

 

Ich glaube nicht, dass man da jetzt riesige Schritte macht, wenn man das per 1117 verteilt, es sollte aber trotzdem gemacht werden.

 

Interessant ist der Wert SQLServer:Buffer Manager:Page Life Expentancy, dieser soll lt. Blog nicht unter 300 liegen.

Im 4h Test liegt dieser im Schnitt bei 11.344.

 

Wenn ich den Wert in der Leistungsüberwachung mitlaufen lasse, liegt dieser momentan bei 41... Tendenz langsam steigend.

?

 

Thx im voraus

 

 

[NeMiX 76]

Hi,

 

hast du schon mal dran gedacht auf SSDs zu updaten (und ggf. mehr Ram, da der günstig ist).

 

Wir haben letztens für eine kleine SAP Installation testweise mal einen Server mit 2x Raid1 SSDs für DB und Logs und 128GB Ram zur Verfügung gestellt. Der Testkreis war sehr begeistert, da vor allem Monatsabrechnung sehr schnell durchliefen. (TestDB ist ein Clone der Prod DB für Lohn/Reisekosten mit ca 70GB DB Size).

Ansonsten nehme ich mal an das Ihr auf SQL Seite alles sauber habt und auch die Indizes sauber aufgebaut sind?

[Knorkator 12]

Hallo,

SSD Upgrade haben wir noch nicht geprüft. Ich kann mir auch nicht vorstellen, dass das noch schneller (theoretisch) läuft als der Verbund aus 4x2 Platten mit 15k.

Theoretisch.. denn sonst würde es diesen Thread ja nicht geben.

:)

 

Indizes muss unser SQL Mensch noch prüfen. Potential haben die Indizes wohl immer.

Wie erwähnt, ich möchte die Hardwareseite optimieren und sicherstellen, dass da keine Komponente bremst.

[Daniel -MSFT- 129]

Vergleich mal die möglichen IOPs von einer SSD mit einer HDD. Das ist wie Rennwagen vs. Pferdekutsche: https://calypsotesters.com/summary-performance-comparison-hdd-sshd-ssd/

[NeMiX 76]

Hallo,

SSD Upgrade haben wir noch nicht geprüft. Ich kann mir auch nicht vorstellen, dass das noch schneller (theoretisch) läuft als der Verbund aus 4x2 Platten mit 15k.

 

Da würd ich mal spontan gegenhalten, siehe IOPS Werte von Daniel. Optimimum ist DB liegt komplett im RAM für lesend Zugriff und schreibend auf SSDs ruft mir mein SQL Kollege zu ;).

 

Evtl. kann euer Controller auch Cachedisks? Dann würde eine SSD pro Controller reichen um mehr rauszuholen für den Anfang falls du nicht komplett umstellen möchtest. Die Enterprise SSDs kosten auch nicht gerade wenig. Am Ram solltest du aber nicht sparen und versuchen auf 48GB hochzugehen.

[Knorkator 12]

Oh, ich seh grade, dass meine Antwort wohl nicht gepostet wurde.

Die Iops Werte sind ja schon beeindruckend!

Die Preise für die Platten allerdings auch!

:)

[NeMiX 76]

Naja was für HDDs hast du dir angeschaut? Neuere LSI Controller haben die möglichkeit eine Consumer SSD als Cache anzuschließen, dadurch gewinnt man auch sehr gute Leseperformance.

[Knorkator 12]

Ich habe nur mal Blick auf die Enterprise HDDs geworfen. Da wir noch einen Wartungsvertrag mit Fujitsu haben  (2J 4h), möchte ich auch ungerne Consumerplatten etc. einbauen.