[Gelöst] SQL-Server? oder Virtualisierung?
15. Februar 2008 00:19
Hallo Forum,
seid einiger Zeit wird Navision immer langsamer und braucht in großen Tabellen wie Archivierte Einkaufszeilen minuten
bis man was machen kann.
Status: SQL-Server 2005 Virtualisiert (VMWare)
2 Dual Core /2GB Ram
4 Partitionen
C: System
D: Primary
E: mdf
F: log
Wartungsaufträge:
3x die Woche statistik optimieren
stdl. log sichern
jeden Abend: Vollständiges Backup
Navision: 4.00 SP3
Einmal Indizes neuorganisieren lassen
hat aber nichts gebracht
Was kann Ich tun um die Performance zu verbessern?
Oder liegt es an der Virtualisierung?
seid einiger Zeit wird Navision immer langsamer und braucht in großen Tabellen wie Archivierte Einkaufszeilen minuten
bis man was machen kann.Status: SQL-Server 2005 Virtualisiert (VMWare)
2 Dual Core /2GB Ram
4 Partitionen
C: System
D: Primary
E: mdf
F: log
Wartungsaufträge:
3x die Woche statistik optimieren
stdl. log sichern
jeden Abend: Vollständiges Backup
Navision: 4.00 SP3
Einmal Indizes neuorganisieren lassen
hat aber nichts gebracht
Was kann Ich tun um die Performance zu verbessern?
Oder liegt es an der Virtualisierung?
15. Februar 2008 02:47
Was kann Ich tun um die Performance zu verbessern?
Durchsuche mal das Forum nach "SQL Performance" - Du wirst "Tonnen" von Hinweisen finden!
Oder liegt es an der Virtualisierung?
Nun, grundsätzlich ist von der Virtualisierung eines produktiven SQL Servers abzuraten.
Was Deine HW Spezifikationen angeht: Ist es das, was via VMWare dem SQL Server zugeteilt wurde? Oder das was physikalisch vorhanden ist?
Denn 2GB RAM für SQL 2005 ist ein "No Go" - egal was in diversen MS Dokus steht, aber so richtig funzt's erst b 8GB ...
15. Februar 2008 08:51
Hallo,
ich kann Jörg nur zu stimmen. Wir hatten den SQL Server am Anfang auch vitualiesiert. Die umstellung auf eine eigenen Maschine hat eine Menge gebracht. Seitdem keine Userbeschwerden mehr über zu langsame Antwort Zeiten. Hurra !.
Wir setzten eine HP DL 380 G3 mit 4 GB speichern ein. Hyperthreading deaktiviert.
Jörg
ich kann Jörg nur zu stimmen. Wir hatten den SQL Server am Anfang auch vitualiesiert. Die umstellung auf eine eigenen Maschine hat eine Menge gebracht. Seitdem keine Userbeschwerden mehr über zu langsame Antwort Zeiten. Hurra !.
Wir setzten eine HP DL 380 G3 mit 4 GB speichern ein. Hyperthreading deaktiviert.
Jörg
Performanceproblem mit Broadcom Netzwerkkarten
15. Februar 2008 09:30
Hallo,
uns ging es vor kurzem ähnlich : Wir hatten massive Performanceprobleme. Nun haben wir festgestellt, dass Navision 4 mit Broadcom Netzwerkkarten starke Probleme hat. Es gibt jedoch 3 Parameter, welcher verändert werden können. Diese machen sich dann deutlich bemerkbar.
Also - wer evtl. ein Problem dieser Art hat (Server mit Windows 2003 + Broadcom Netzwerkkarte + Navision 4), kann sich hier melden.
MfG
Albe
uns ging es vor kurzem ähnlich : Wir hatten massive Performanceprobleme. Nun haben wir festgestellt, dass Navision 4 mit Broadcom Netzwerkkarten starke Probleme hat. Es gibt jedoch 3 Parameter, welcher verändert werden können. Diese machen sich dann deutlich bemerkbar.
Also - wer evtl. ein Problem dieser Art hat (Server mit Windows 2003 + Broadcom Netzwerkkarte + Navision 4), kann sich hier melden.
MfG
Albe
15. Februar 2008 09:30
Nun, grundsätzlich ist von der Virtualisierung eines produktiven SQL Servers abzuraten.
Da kann ich voll zustimmen.
15. Februar 2008 09:47
Danke für die vielen Hinweise!
Ich hab´s geahnt das es nicht funktionieren wird!
Mist!!!
@stryk Die Ressourcen werden von VMWare zugeteilt.
Ich hab´s geahnt das es nicht funktionieren wird!
Mist!!!
@stryk Die Ressourcen werden von VMWare zugeteilt.
15. Februar 2008 15:17
Navisionkämpfer hat geschrieben:@stryk Die Ressourcen werden von VMWare zugeteilt.
Als Erste Hilfe Maßnahme - soz. bis zur Ent-Virtualisierung ;c) - solltest Du dem SQL Server dann unbeding mehr RAM zuordnen (Achtung: SQL Server richtig konfigurieren!) damit ihr wenigstens einigermaßen mit der Kiste arbeiten könnt ...
15. Februar 2008 19:27
Also 2 GB ist arg wenig. Und das mit den 4 Partitionen treibt mir auch den Angstschweiß auf die Stirn. Sind das Partitionen oder eigene Platten?
Die einzelnen Datenbankteile zu trennen ist schon sinnvoll
Trennung des Betriebssystems
Trennung der master und tempdb
Schnelle Platten für die mdf / ndf.
Und das Log file auch auf eine Platte mit schnellem schreibdurchsatz.
Was die RAM zuweisung für den SQL Server angeht. Je mehr desto besser, aber auch das BS braucht etwas RAM zum arbeiten. Nicht das Windows anfangen muss zu swappen
Was die RAM Einstellung im SQL Server angeht, hier ein Link der weiterhelfen sollte.
http://msdn2.microsoft.com/de-de/library/ms178067.aspx
Auch sollte bei den Hardwarecontrolern der Log Platte darauf geachtet werden, ob diese über einen gepufferten Cache verfügen oder nicht. Schlimm wird die vor allem , wenn die abschmiert / Stromausfall, was auch immer und die letzte Transaktion im Cache hing und nicht ins Log geschrieben wurde
Also SQL server sollte 8GB haben, die 2x2 Kerne gehen schon. Per Perfmon, Query Analyzer und Profiler bekommst du dann aber auch raus ob es CPU lastige Prozesse gibt. Die kannst du dann umschreiben und im schlimmsten Falle halt Quadcore.
Welche 4.03 hast du
Die Standard oder irgenwelche HF dazu
Solltest du HF 6 haben, rate ich dir sofort, dich bei deinem Partner zu melden und das KB 945349 einzufordern. Grund: Mit HF6 ist ein "lustiges" Lock verhalten bei Fehlermeldungen zugekommen. Ebenfalls mit HF 6 hinzugekommen ist indexhinting. Das würde ich generell erst mal wieder abschalten und spezifisch nachschauen, bei welchen Tabellen es evtl. sinn macht.
Grüße
Die einzelnen Datenbankteile zu trennen ist schon sinnvoll
Trennung des Betriebssystems
Trennung der master und tempdb
Schnelle Platten für die mdf / ndf.
Und das Log file auch auf eine Platte mit schnellem schreibdurchsatz.
Was die RAM zuweisung für den SQL Server angeht. Je mehr desto besser, aber auch das BS braucht etwas RAM zum arbeiten. Nicht das Windows anfangen muss zu swappen
Was die RAM Einstellung im SQL Server angeht, hier ein Link der weiterhelfen sollte.
http://msdn2.microsoft.com/de-de/library/ms178067.aspx
Auch sollte bei den Hardwarecontrolern der Log Platte darauf geachtet werden, ob diese über einen gepufferten Cache verfügen oder nicht. Schlimm wird die vor allem , wenn die abschmiert / Stromausfall, was auch immer und die letzte Transaktion im Cache hing und nicht ins Log geschrieben wurde
Also SQL server sollte 8GB haben, die 2x2 Kerne gehen schon. Per Perfmon, Query Analyzer und Profiler bekommst du dann aber auch raus ob es CPU lastige Prozesse gibt. Die kannst du dann umschreiben und im schlimmsten Falle halt Quadcore.
Welche 4.03 hast du
Die Standard oder irgenwelche HF dazu
Solltest du HF 6 haben, rate ich dir sofort, dich bei deinem Partner zu melden und das KB 945349 einzufordern. Grund: Mit HF6 ist ein "lustiges" Lock verhalten bei Fehlermeldungen zugekommen. Ebenfalls mit HF 6 hinzugekommen ist indexhinting. Das würde ich generell erst mal wieder abschalten und spezifisch nachschauen, bei welchen Tabellen es evtl. sinn macht.
Grüße
18. Februar 2008 14:52
Also virtualisieren ist natürlich ne tolle Sache, im Bereich Datenbanken würde ich aber davon abraten. Eigentlich machen virtualisierte Umgebungen nur Sinn wenn sich öfters was ändert oder man aus gewissen Gründen mal eben einen Server braucht den man deswegen nicht anschaffen möchte.
ODer... man hat zuviel Geld kauft die akktuellste Konfiguration für einen Server den man kriegen kann virtualisiert diesen zu 2 oder 3 Servern, bezahlt aber Schlussendlich in Summe soviel wie für 8-10 Server gleicher Leistung
ODer... man hat zuviel Geld kauft die akktuellste Konfiguration für einen Server den man kriegen kann virtualisiert diesen zu 2 oder 3 Servern, bezahlt aber Schlussendlich in Summe soviel wie für 8-10 Server gleicher Leistung
19. Februar 2008 21:39
Vielen Dank nochmal an alle,
aber hat irgendjemand Ahnung ?wieso? eigentlich alle davon abraten?
Was macht VMWare da verkehrt?
Kennt jemand einen bei dem es funktioniert hat?
Gruß René
aber hat irgendjemand Ahnung ?wieso? eigentlich alle davon abraten?
Was macht VMWare da verkehrt?
Kennt jemand einen bei dem es funktioniert hat?
Gruß René
25. Februar 2008 18:21
also: genauso wie Green IT ist virtualisierung gerade in aller Munde.
Das heißt aber nicht, daß es für jeden geeignet ist.
Wenn ich ein großes Gebäude habe, in dem mehrere Firmen untergebracht sind, lohnt es sich z.B. anstatt für jede Firma einen extra server aufzustellen, einen großen hinzubauen und die FIrmenserver wirtuell auf dieser Maschine laufen zu lassen. Üblicherweise ist da die IT-Abteilung outgesourced und betreibt die virtuellen Server und vermietet die an die Firmen.
Oder ich baue mit einer VM einen Testserver auf, um Updates usw. zu testen, ohne daß ich extra neue Hardware kaufen muß.
Ein virtueller Server wird aber immer langsamer laufen als "echte" Hardware, obwohl sich da in letzter Zeit viel getan hat.
Das heißt aber nicht, daß es für jeden geeignet ist.
Wenn ich ein großes Gebäude habe, in dem mehrere Firmen untergebracht sind, lohnt es sich z.B. anstatt für jede Firma einen extra server aufzustellen, einen großen hinzubauen und die FIrmenserver wirtuell auf dieser Maschine laufen zu lassen. Üblicherweise ist da die IT-Abteilung outgesourced und betreibt die virtuellen Server und vermietet die an die Firmen.
Oder ich baue mit einer VM einen Testserver auf, um Updates usw. zu testen, ohne daß ich extra neue Hardware kaufen muß.
Ein virtueller Server wird aber immer langsamer laufen als "echte" Hardware, obwohl sich da in letzter Zeit viel getan hat.
25. Februar 2008 21:15
Die Krux ist das richtige Werkzeug für die Aufgabe zu wählen.
To a man with a hammer, everything looks like a nail.
--- Mark Twain
To a man with a hammer, everything looks like a nail.
--- Mark Twain
25. Februar 2008 23:13
Habe von unserem Administrator jetzt insgesamt 4GB Ram bekommen. Es läuft zwar nun wesentlich schneller allerdings hat der SQL-Server sich kaum mehr Speicher reserviert. Am Ende des Tages hat er ungefähr 1,8 GB gecacht.
Etwas verwunderlich ist das schon... ;)
Mal sehen was weiter passiert...
Gruß René
Etwas verwunderlich ist das schon... ;)
Mal sehen was weiter passiert...
Gruß René
26. Februar 2008 11:00
Wenn wir hier von einem 32bit System reden, dann muss in der "Boot.ini" der Schalter /3gb gesetzt werden, da ansonsten Windows es nicht zulässt, dass Anwendungen/Dienste mehr als 2 GB allokieren.
Das das System jetzt schneller läuft, liegt also im wesentlichen daran, dass nun das OS einigermaßen genügend Speicher hat ...
Sind 4 GB RAM verfügbar, dann kann SQL Server ca. 2,8 GB maximal allokieren (Max = "Physikalischer RAM" - 1GB); das sollte man im Performance Counter "SQL Server:Memory Manager - Target Server Memory" wiederfinden.
Das das System jetzt schneller läuft, liegt also im wesentlichen daran, dass nun das OS einigermaßen genügend Speicher hat ...
Sind 4 GB RAM verfügbar, dann kann SQL Server ca. 2,8 GB maximal allokieren (Max = "Physikalischer RAM" - 1GB); das sollte man im Performance Counter "SQL Server:Memory Manager - Target Server Memory" wiederfinden.
26. Februar 2008 11:51
Hallo,
hab das jetzt entsprechend geändert -->
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003 Standard" /noexecute=optout /fastdetect /redirect /3gb
passt das so?
Dann starte ich den Server nochmal durch.
PS: Meine Auslagerungsdatei liegt bei 1,9 GB
Gruß René
hab das jetzt entsprechend geändert -->
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003 Standard" /noexecute=optout /fastdetect /redirect /3gb
passt das so?
Dann starte ich den Server nochmal durch.
PS: Meine Auslagerungsdatei liegt bei 1,9 GB
Gruß René
26. Februar 2008 15:01
Sollte so passen ... wie gesagt: wichtig ist, was "Target Server Memory" anzeigt.
Was die Auslagerungsdatei angeht, so lautet die MS Empfehlung 1,5 fache Größe des RAM, d.h. in Deinem Fall also 6 GB ... aber auch hier kann die tatsächliche Nutzung via "perfmon" ermittelt werden ...
Was die Auslagerungsdatei angeht, so lautet die MS Empfehlung 1,5 fache Größe des RAM, d.h. in Deinem Fall also 6 GB ... aber auch hier kann die tatsächliche Nutzung via "perfmon" ermittelt werden ...