[gelöst] MSSQL, Navision, VMWARE, Performance

23. Juli 2007 15:15

Hallo,

wir setzten NAV 4.03 mit MSSQL 2005 ein.

Der MSSQL-Server läuft unter W3k als VMWARE Guest mit 1024 GB RAM.
Das VMHOST-System (ESX) läuft auf einem HP DL380 mit 2x Xeon 2800 Prozessoren.

Active User max 10.

Im Lohnbereich haben wir vorher die gleiche Nav Version, allerdings auf C/Side eingesetzt. Auf der Localen C/Side Datenbank benötigt eine Probelohnabrechnung ca. 2min ( 200 Mitarbeiter )

Auf dem MSSQL-Server ca. 60 min !

Ist nur die Hardware des MSSQL-Server für die Performance ausschlaggebend oder muss ich für NAV Einstellungen am SQL-Server vornehmen ?

Vielen Dank für Eure Hilfe
Jörg
Zuletzt geändert von Jörg Nissen am 25. Juli 2007 14:45, insgesamt 1-mal geändert.

Re: MSSQL, Navision, VMWARE, Performance

23. Juli 2007 20:47

Jörg Nissen hat geschrieben:Der MSSQL-Server läuft unter W3k als VMWARE Guest mit 1024 GB RAM.
Das VMHOST-System (ESX) läuft auf einem HP DL380 mit 2x Xeon 2800 Prozessoren.


Ähh ... bevor ich jetzt lange bei MS nachschaue, ein paar - doofe? - Fragen ...
Was ist W3k? Ist damit Windows Server 2003 gemeint?
1024 GB RAM - also ein Terrabyte - kann ich das glauben? Win2003 kann aber nur bis 4GB in der Standard Edition, 64GB mit Enterprise und 128GB mit DataCenter ... oder reden wir hier über 'ne 64bit Kiste?

Ich weiß zwar nicht was VMWARE so alles kann, aber ich unterstelle mal, der SQL Server läuft mit 1 GB RAM - und das ist definitiv zu wenig! Mit SQL Server 2005 sollte man unter 4GB gar nicht erst antreten ...

Die HP DL380 habe ab Werk Hyperthreading aktiviert, das funktioniert aber mit SQL Server nicht wirklich - sollte deaktiviert werden.

Und - last but not least - von einer Virtualisierung eines Datenbankservers sollte man lieber absehen, lediglich wenn die zu Grunde liegende Hardware entsprechend "Fleisch auf dem Nacken" hat, kann man damit Erfolge erzielen (z.B. 64bit, 32GB RAM, 4 x DualCore, etc. und vor allem ein effizientes Storage System).
Ich habe mal 'ne Studie/Benchmark zum Thema Virtualisierung von SQL Server (allerdings mit Axapta) von 'ner holländischen IT-Unternehmensberatung gesehen, das Ergebis ist erschütternd: "bloss nicht!"

24. Juli 2007 07:57

Hallo ,
danke für deine Antwort.

Du unterstellst das Richtige !. Natürlich 1 GB mit Windows 2003 Server.

Deine Antwort überrascht mich nicht. Ab Herbst bekommt der SQL-Server eine eigene Maschine ( DL380 G3, mit 4 GB RAM ).

Angeschlossen wird das ganze an ein SAN.

Ich habe deine Konfigrationsempfehlung hier im Forum vom letzten Jahr gelesen. An diese werden wir uns halten.

Da wir nicht die Riesigen Datenmengen haben, werden allerdings alle Raids Raid 1 sein ( HP 72,8 GB Festplatten ).

Wie wichtig ist ein eigenens Raid für die TEMPDB und die System Datenbanken ?

Daten und Logfiles auf ein eigenes ist verständlich.

Vieleicht bist du so nett, und gibts mir dazu ein Statement.

Vielen Dank
Jörg

24. Juli 2007 09:18

Ab Herbst bekommt der SQL-Server eine eigene Maschine ( DL380 G3, mit 4 GB RAM ).
Angeschlossen wird das ganze an ein SAN.
Ich habe deine Konfigrationsempfehlung hier im Forum vom letzten Jahr gelesen. An diese werden wir uns halten.

Da sich die Technologien weiterentwickeln, ist nicht gesagt das eine Emofehlung vom letzten Jahr noch "state-of-the-art" ist. Da insbesondere 64bit Systeme sowie Multi-Core CPU stark im Kommen sind, oder aktuell auch die ersten Hybrid-Festplatten auf den Markt kommen, sollte das Setup aktuell eruiert werden.
Natürlich gebe ich auch gerne meinen "Senf" dazu :lol:

Da wir nicht die Riesigen Datenmengen haben, werden allerdings alle Raids Raid 1 sein ( HP 72,8 GB Festplatten ).
Wie wichtig ist ein eigenens Raid für die TEMPDB und die System Datenbanken ?

Nun, ausschlaggebend ist das Transaktionsvolumen, also die Anzahl der Belege/Datensätze die erstellt oder geändert werden. Je höher dieses Volumen ist, desto wichtiger ist es, die Systemdatenbanken zu isolieren, damit sie SQL Server entsprechend schnell "erreichen" kann. Dies gilt im Wesentlichen für master und tempdb. Da mit NAV die tempdb recht intensiv genutzt wird, sollte diese mit höherer Priorität isoliert werden als master.
Man könnte u.U. ja sparsam beginnen, und alles Sys-DB (master, model, msdb, tempdb) auf ein gemeinsames RAID1 legen und nur im Problemfall die tempdb nachträglich isolieren.

Gruß,
Jörg

24. Juli 2007 09:50

Hallo,

der Rechner ist ja auch nicht mehr State-of-the-Art, aber wir haben Ihn dann halt über, und so schlecht ist er ja auch nicht.

Gibt es eigentlich Tools um die Performance zu "Messen". Oder ist die Leistungserfassung in Navision rein Subjectiv ( gefühlte Geschwindigkeit :-) )

Wir haben ca. 150000 Buchungen im Jahr. Ist das Viel, mittel oder wenig ?.

Allerdings setzten wir zur Zeit nur Lohn und Gehalt ( 200 Mitarbeiter ) und die Fibu ein. Vertrieb und Marketing folgen später.


Anzahl der SQL Transaktionen, keine Ahnung


mfg
Jörg

24. Juli 2007 10:14

Gibt es eigentlich Tools um die Performance zu "Messen". Oder ist die Leistungserfassung in Navision rein Subjectiv


Also, ich doziere: "Performance" ist (vereinfacht) das Verhältnis von "Datendurchsatz" zu "Antwortzeit".
Selbstverständlich gibt es Methoden zur objektiven Erfassung dieser Daten!

Hier mal die Wichtigsten:

+ Windows Performance Monitor (!!!)
+ SQL Profiler (!!!)
+ NAV Client Monitor
+ SQL Server (diverse Prozeduren und Views)

und natürlich diverse "3rd party" Tools (z.B. Diagnostic Manager, etc.)

Was man alles so messen kann - und sollte! - findest Du z.B. hier: http://www.stryk.info/Performance Checklists 1.02.pdf

25. Juli 2007 14:45

Hallo Jörg,
danke für deine Antwort. Hat mir weitergeholfen.

Jörg