SQL Performance

Hi Fiddi,

ich habe jetzt das selbst noch mal auf meinem Arbeitsrechner getestet:
VMWare-Server 2.0.2
virtueller Win2003 mit SQL2008
virtuelle Plattengröße 30 GB, dynamich vergrößert

Vor Test:
File-Größe virtuelle Disk 18 GB
File-Größe SQL-Data 150 MB (automatische Vergrößerung um 1000 MB)
EDIT: Belegter Speicher im virtuellen Win2003 18GB

Nach Test
File-Größe virtuelle Disk 18 GB
File-Größe SQL-Data 1150 MB
EDIT: Belegter Speicher im virtuellen Win2003 19GB

Darüber hinaus spiet bei 20 GB Daten und 70 Usern die Temp-DB bestimmt auch eine Rolle und die liegt ja wohl auch auf dem virtuellen SQL in der gleichen Partition - und wird bei jedem Neustart des SQL-Servers neu angelegt. Nichts desto trotz glaube ich, dass an Investition in Hardware kein Weg vorbei führt.

Volker

Nichts desto trotz glaube ich, dass an Investition in Hardware kein Weg vorbei führt.

Und vor allem führt kein Weg an Investition in NAV/SQL-Kompetenz vorbei. Keiner hat im Unternehmen eine genaue Ahnung was man für Hardware braucht, aber man installiert alles alleine. Ich möchte nicht wissen, wie die Konfiguration der SQL-Server-Instanz aussieht.

Und vor allem führt kein Weg an Investition in NAV/SQL-Kompetenz vorbei. Keiner hat im Unternehmen eine genaue Ahnung was man für Hardware braucht, aber man installiert alles alleine. Ich möchte nicht wissen, wie die Konfiguration der SQL-Server-Instanz aussieht.

Wo auch immer du das jetzt rausgelesen hast.

Wo auch immer du das jetzt rausgelesen hast.

Erstens ergibt es sich aus der installierten Konfiguration. Dass der Threadersteller keine Ahnung davon hat, hat er aber auch schon selbst geäußert und auch dass die IT-Abteilung davon nichts wissen will. Darüberhinaus lassen auch die zur Verfügung gestellten Informationen, sowie die Fragestellungen darauf schließen. Nicht zuletzt hat der Threadersteller schon selbst erkannt, dass es gut wäre einen SQL-Spezialisten zu befragen.

Die einzige Unterstellung meinerseits, die nicht dem Thread direkt zu entnehmen ist: es wurde bei der Installation auch kein SQL-Spezialist zu Rate gezogen. Sonst sollte meiner Meinung nach die Konfiguration des Servers anders aussehen. Denkbar wäre aber natürlich auch, dass sich die Grundvoraussetzungen so dramatisch geändert haben und diese Entwicklung nicht mitgeteilt bzw. berücksichtigt wurde.

Aber wenn du den Eindruck gewonnen hast, dass sich dort sehr kompetente Leute mit der NAV-/SQL-Installation auseinandersetzen, möchte ich dagegen nichts sagen. Ich habe eben einen anderen Eindruck gewonnen und weiß auch aus Erfahrung, dass Spezialisten meist erst gefragt werden, wenn das Problem bereits besteht. Durch meine Aussage wollte ich nur mal wieder darauf hinweisen: NAV/SQL-Installationen sind so individuell wie die Personen, die damit arbeiten, so dass es aus meiner Sicht nicht möglich ist guten Gewissens einen Tipp wie "mehr RAM" zu geben. Das wird wahrscheinlich ein bißchen helfen, aber ist es wirklich die Ursache für die Performance-Probleme?

Man kann nur immer wieder darauf hinweisen (und das war die Intention meines vorigen Posts): "Fragen Sie doch jemanden der sich damit auskennt" und zwar am besten schon zur Installation, aber spätestens wenn die ersten Performance-Probleme im Live-Betrieb entstehen und nicht erst, wenn keiner mehr vernünftig arbeiten kann.

Hi zusammen,

öhm, hier geht's ja quasi um mein "Steckenpferd", aber ich fürchte ich bin etwas spät dran hier mitzumischen
Ich hab' den Thread nur kurz überflogen, und vieles schein ja auch schon erörtert worden zu sein - sorry, falls ich das eine oder andere wiederhole.

Grundsätzlich:
Die normale CPU Auslaszung liegt bei einem ausreichend dimensionierten Server bei 15-25% im Durchschnitt. Alles darüber ist schlecht, die Gründe dafür vielfältig ...
Die Kernel-Zeiten müssen unter 10% liegen.

Bei VMWare muss die CPU Zuordnung auf "fix" gesetzt sein, niemals "dynamisch". 4 CPU tun's für max. 50 bis 80 User, darüber hinaus kann es bei Power-Usern schon Probleme geben.
4GB RAM ist quasi gar nix für SQL Server - netto sind das max. 2,6 GB. Unter 8GB braucht man IMHO nemals antreten, besser 16GB und aufwärts. Zuwenig RAM erhöht den Druck auf die Platten und damit auch auf die CPU.
Bei Platten reden wir nur von physikalischen Laufwerken, niemals Partitionen oder virtuellen Laufwerken. LUN bei SAN Systemen sind OK, wenn das SAN richtig dimensioniert und konfiguriert ist. Eine physikailsche Trennung von Daten und Log ist bei physilkalischen Laufwerken ein "must have".

Um den Druck auf die CPU zu verringern muss also die VMWare Konfig stimmen. Mehr RAM schadet nicht, auch muss das Disk-Subsystem einwandfrei sein.
Im SQL Server sollte man den "MAx. Degree of Parallelism" auf 1 setzen (NAV <= 4.0 SP3|5.0) oder die Hälfte der CPU (hier also 2) bei NAV >= 5.0 SP1

Wie schon angesprochen muss sicher gestellt sein, dass keine anderen Anwendungen/Prozesse die CPU belasten; Klassiker wären hier:
Virenscanner, Backup Tools, HP Insight Manager o.ä., Remote Tools (VNC etc.) usw.

Auch die NAV Applikation selbst kann Grund für die hohe CPU Last sein, wenn z.B. viele intensive Index Scans durchgeführt werden - hier hilft Profiling, Indexing und C/AL Code Optimierung.

Tja, dann kann es noch eine Million andere Gründe geben ...

LIebe Grüße,
Jörg

Kleiner Hinweis in eigener Sache:
Wer mehr über das Thema "Keys & Indexe - Verstehen, Verwenden, Optimieren" erfahren möchte, der sollte sich zu unserer ersten MSDynamics.de Konferenz am 09.05.2012 in Kassel anmelden.
Die Teilnahme ist kostenlos, aber ganz bestimmt nicht umsonst

Hallo zusammen,

vielen Dank für die zahlreiche Rückmeldungen. Hat mir sehr viel geholfen.
Jetzt wird kräftig aufgerüstet.

Also, Umstieg aus Native Classic 3.10 auf RTC R2 ist richtig eine Herausforderung.
Unsere User können im Moment zwar arbeiten aber ist halt dann ab und zu sehr unangenehm.

@Timo: Danke für die Info zu MSDynamics.de Konferenz. Habe ich total übersehen. Werde ich mal überlegen....

Mal am Rande: sind die Hardware-Anforderungen für Nav RTC noch an der Grenze oder schon sehr "überdimensioniert"? Wie ist der Vergleich mit SAP?

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

sind die Hardware-Anforderungen für Nav RTC noch an der Grenze oder schon sehr "überdimensioniert"

Aus welcher Quelle hast du die Hardwareanforderungen übernommen? Also die offiziellen Anforderungen von MS dürften mit 1GB- Speicher eher unter dimensioniert sein. Bei 70 Usern (hängt natürlich immer davon ab, was die tun. Mit 30 Usern im Telefonverkauf gelten andere Anforderungen als beim Thekenverkauf, wo alle halbe Stunde mal ein Kunde kommt) würde ich dir mindestens 2 besser 3 NSTs empfehlen, die jeweils auch ein bisschen mehr Speicher als 2Gb zur Verfügung haben dürfen. Ob die dann alle auf unterschiedlichen Maschinen laufen müssen, musst du ausprobieren.
Die nächste Version vom ServiceTier (NST) könnte evtl auch nur noch auf 64 Bit Systemen laufen, deshalb plane auch hierfür lieber einen W2k8 Server mit ein bisschen mehr freien Speicher ein.

Gruß, Fiddi

Zum Vergleich mit SAP kann ich dir leider wenig sagen.

Also, Umstieg aus Native Classic 3.10 auf RTC R2 ist eine richtige Herausforderung.
Unsere User können arbeiten aber ist halt dann ab und zu sehr unangenehm.

Ein 6er Golf mit dem 60PS Aggregat ausm 3er fährt auch aber ist halt dann ab und zu sehr unangenehm.

...Also, Umstieg aus Native Classic 3.10 auf RTC R2 ist eine richtige Herausforderung.
Unsere User können arbeiten aber ist halt dann ab und zu sehr unangenehm.
...

Also ich bin jetzt ein bischen verwirrt. Was läuft bei Dir jetzt in welcher Version und wo?

Ich bin mir jetzt auch nicht mehr sicher, aber gab es nicht irgendwelche Problemchen mit älteren NAV-Versionen und Windows 64-bit?

Volker

Also ich bin jetzt ein bischen verwirrt. Was läuft bei Dir jetzt in welcher Version und wo?

Ich bin mir jetzt auch nicht mehr sicher, aber gab es nicht irgendwelche Problemchen mit älteren NAV-Versionen und Windows 64-bit?

Volker

Wir haben seit Februar Nav 2009 R2 mit RTC im Einsatz.
Vorher war Nav 3.10 Native Datenbank mit technische Update 4.0, kein VM, Win2003 32 bit.

Ein 6er Golf mit dem 60PS Aggregat ausm 3er fährt auch aber ist halt dann ab und zu sehr unangenehm.

Deshalb wird jetzt richtig aufgerüstet.

Von unserem Partner kam damals keine vernünftige Information zu der Server-Leistung ausser: "Dem VMWare Server müssen natürlich genügend Ressourcen breit gestellt sein".
Antwort auf die Frage was genau die "genügend Ressource" sind : "ich schlage vor das wir dieses Thema an den Vertrieb geben um von MS hier eine Aussage oder Empfehlung zu bekommen." Mehr nicht

Von unserem Partner kam damals keine vernünftige Information zu der Server-Leistung ausser: "Dem VMWare Server müssen natürlich genügend Ressourcen breit gestellt sein".
Antwort auf die Frage was genau die "genügend Ressource" sind : "ich schlage vor das wir dieses Thema an den Vertrieb geben um von MS hier eine Aussage oder Empfehlung zu bekommen." Mehr nicht

Also dieses Thema ist hier im Forum schon so oft durchgekaut worden, das Jörg und andere sich hier schon Textbausteine bauen, um die immer wieder gleichen Fragen zu beantworten. Die Hardwareanforderungen die MS für seine Systeme abgibt, sind meistens die untere Grenze, damit es überhaupt funktioniert. Das eine Datenbank mit 20GB und 70 Usern nicht mehr mit den empfohlenen Speicher für SQL- 2008 (4GB) auskommt, sollte jedem Anbieter ohne große Überlegung klar sein.

Im zweifel kann er es selbst hier und hier (Partnersource Zugang erforfderlich) nachlesen


Gruß, Fiddi

Im zweifel kann er es selbst hier nachlesen

Hallo Fiddi,
dieses Dokument habe ich auch gefunden und danach habe ich auch eingerichtet.
Anhand der Dokumentation kann ich keinen Fehler aus meinerseits finden :)
Aber dort steht leider keinerlei Informationen zu Systemsanforderung für VM Ware und SQL-Server.

hier (Partnersource Zugang erforfderlich)

Ich habe keine Partnerzugang .. finde ich den auch irgendwo ins Netz?

Wenn du ein wenig googelst wird du das Dokument auch schon wo anders finden. Es handelt sich um das "NAV Performance Guide". Euer Partner hätte es sich aber auch herunterladen können. Das Dokument hat Stand wurde im Jahr 2009 erstellt.
Gruß, Fiddi

Der benötigte Arbeitsspeicher ist in Grenzen immer abhängig von der DB-Größe. Ein "mindestens 8GB" trifft nicht auf kleinere Installationen zu, oder "so groß wie die Datenbank" genauso wenig bei einer 1TB-NAV DB.
Wenn der SQL Server schon eine Cache Hit Ratio von 100% ausweist, dann muss da nicht noch mehr RAM reingesteckt werden.
Genausowenig muss in einer 1TB-Datenbank ca. 1 Terabyte RAM beim SQL Server verfügbar sein.

Hi zusammen,

öhm, hier geht's ja quasi um mein "Steckenpferd", aber ich fürchte ich bin etwas spät dran hier mitzumischen
Ich hab' den Thread nur kurz überflogen, und vieles schein ja auch schon erörtert worden zu sein - sorry, falls ich das eine oder andere wiederhole.

Grundsätzlich:
Die normale CPU Auslaszung liegt bei einem ausreichend dimensionierten Server bei 15-25% im Durchschnitt. Alles darüber ist schlecht, die Gründe dafür vielfältig ...
Die Kernel-Zeiten müssen unter 10% liegen.

Bei VMWare muss die CPU Zuordnung auf "fix" gesetzt sein, niemals "dynamisch". 4 CPU tun's für max. 50 bis 80 User, darüber hinaus kann es bei Power-Usern schon Probleme geben.
4GB RAM ist quasi gar nix für SQL Server - netto sind das max. 2,6 GB. Unter 8GB braucht man IMHO nemals antreten, besser 16GB und aufwärts. Zuwenig RAM erhöht den Druck auf die Platten und damit auch auf die CPU.
Bei Platten reden wir nur von physikalischen Laufwerken, niemals Partitionen oder virtuellen Laufwerken. LUN bei SAN Systemen sind OK, wenn das SAN richtig dimensioniert und konfiguriert ist. Eine physikailsche Trennung von Daten und Log ist bei physilkalischen Laufwerken ein "must have".

Um den Druck auf die CPU zu verringern muss also die VMWare Konfig stimmen. Mehr RAM schadet nicht, auch muss das Disk-Subsystem einwandfrei sein.
Im SQL Server sollte man den "MAx. Degree of Parallelism" auf 1 setzen (NAV <= 4.0 SP3|5.0) oder die Hälfte der CPU (hier also 2) bei NAV >= 5.0 SP1

Wie schon angesprochen muss sicher gestellt sein, dass keine anderen Anwendungen/Prozesse die CPU belasten; Klassiker wären hier:
Virenscanner, Backup Tools, HP Insight Manager o.ä., Remote Tools (VNC etc.) usw.

Auch die NAV Applikation selbst kann Grund für die hohe CPU Last sein, wenn z.B. viele intensive Index Scans durchgeführt werden - hier hilft Profiling, Indexing und C/AL Code Optimierung.

Tja, dann kann es noch eine Million andere Gründe geben ...

LIebe Grüße,
Jörg

Hi Jörg,

ist es für NAV erforderlich auf einem SQL Server eine CPU-Last von 15-25% zu haben? SQL Server an sich laufen ja auch mit höherer CPU Auslastung performant.

Gruß
Jan

Genausowenig muss in einer 1TB-Datenbank ca. 1 Terabyte RAM beim SQL Server verfügbar sein.

Und auch das hängt von der Art u. Weise ab, wie die DB benutzt wird. Bei 1TB-Postendaten, sieht das anders aus als bei einer DB- die z.B. als Foto- Datenbank dient, wo hauptsächlich Indexe gewälzt werden, um dann gezielt ein Blob zu holen.

Die "Cache- Hit Ratio" ist sicherlich ein gutes Maß für die Performance des Systems, nützt einem aber bei der Dimensionierung eines noch zu kaufenden Systems nicht allzu viel, da man den Wert nicht vorher bestimmen kann.

Grß, Fiddi

ist es für NAV erforderlich auf einem SQL Server eine CPU-Last von 15-25% zu haben? SQL Server an sich laufen ja auch mit höherer CPU Auslastung performant.

Das sollte aber nicht der Normalfall sein, damit du auch für aufwendigere Auswertungen bzw. Buchungen noch Luft hast.

Ein Golf VI würde mit 60PS auch fahren, nur einen LKW kannst du damit dann nicht mehr überholen.


Gruß, Fiddi