9
SQL 2000 auf dem ESX 3.5.0 und die Performance Probleme
Stehen vor einem SoftwareUpdate und überlegen uns unser Produktiv SQL 2000 auf ein ESX System zu setzen
Hallo,
wir haben ein Inhouse CRM Tool welches sich der SQL 2000 Datenbank bedient. Wir haben vor nächste Woche die Software von der Ver 7 auf Ver 10 upzudaten. Alle Tests waren größtenteils erfolgreich, es sind nur noch kleine Fehler zu beheben, die nichts mit der DB ansich zu tun haben. Das was mir Sorgen bereitet ist die Virtualisierung und die Performance der DB. Unser Applikationsserver sowie der DB Server sind auf einer DELL ESX 3.5.0 Maschine. Vorher waren sie auf einer physikalischen Maschine bzw dediziertem Server.
Die Daten zum DELL Server:
8x 2.6GHz Xeon CPUs, 24GB RAM und ein SAN mit ESX 3.5.0 und Virtual Server 2.5.0
Derzeit sprechen wir von einem 85 Mitarbeiter Unternehmen, in welchem das System von ca 60 Mitarbeitern ständig in Anspruch genommen wird.
DB Größe ~13GB (inkl log Datei ~50GB)
Daten zu der VM mit der SQL 2000 DB: http://img24.imageshack.us/img24/8767/screendb.jpg
Auf dem ESX System laufen mehrere VMs inkl unseren Applikation- und DB Servers. Da ich mit meinem Kollegen eigentlich nur das Inhouse CRM Tool betreuen müssen wir auf das hören was unsere IT Abteilung sagt und die sagt, dass es so in Ordnung gehen muss, da man die CPUs Speicher etc einwandfrei den VMs zusichern kann.
Allen Tests nach bin ich mit der Performance überhaupt nicht zufrieden. Es ist wesentlich langsamer geworden. Die Zugriffe auf die Company Maske dauernd zB nun immer ca 12 Sek. oder mehr. Auf der Version 7, die derzeit noch live ist, dauern die Zugriffe zw 3-8 Sek (nachgemessen). Die KeyUser, die das Tool auch täglich testen konnten hatten in der Laufzeit Probleme mit ihren VM Client, da diese hängen blieben oder Sonstiges. Wenn ich selbst auf dem VM Server arbeitete und gewisse User Einstellungen unternahm oder Felder mit dem CRM Tool in der DB anpasste hatte ich ebenfalls oft Hänger oder Abstürze. Ich bin nun einfach unsicher und frage mich woran das liegen kann. Die Tage werde ich das gleiche System auf einem Dedizierten Server aufsetzen, der zwar nicht der aktuellste ist, jedoch eben dediziert und schauen ob sich da performancetechnisch was tut.
Ich las hier im Forum und auch auf anderen Seiten über Plus- und Minuspunkte zu der Virtualisierung, aber keine Aussage überzeugte mich so richtig auch wenn ich langsam dazu tendiere, dass man SQL Server lieber auf einer non-VM-Maschine installieren sollte.
Ich sprach eben noch mit unserem Entwickler, er meinte auch dass es da wohl Flaschenhals = Busbreite gibt und diese auf dem Server ziemlich ausgelastet ist.
Vielleicht haben einige von euch weitere Tipps, Kritik, Verbesserungsvorschläge, paar Punkte mit denen ich beim Management argumentieren könnte.
Danke im Voraus.
EDIT: Außerdem würde mich interessieren wie man die Datenbank optimieren kann. Die DB ist seit Anfangs 2007 im Einsatz, vorher wurden die Einträge aus dem Access importiert. Seit anfangs 2007 wurde die DB nicht optimiert. Man sagte mir, dass man die DB optimieren und in der Performance verbessern kann.
Hallo,
wir haben ein Inhouse CRM Tool welches sich der SQL 2000 Datenbank bedient. Wir haben vor nächste Woche die Software von der Ver 7 auf Ver 10 upzudaten. Alle Tests waren größtenteils erfolgreich, es sind nur noch kleine Fehler zu beheben, die nichts mit der DB ansich zu tun haben. Das was mir Sorgen bereitet ist die Virtualisierung und die Performance der DB. Unser Applikationsserver sowie der DB Server sind auf einer DELL ESX 3.5.0 Maschine. Vorher waren sie auf einer physikalischen Maschine bzw dediziertem Server.
Die Daten zum DELL Server:
8x 2.6GHz Xeon CPUs, 24GB RAM und ein SAN mit ESX 3.5.0 und Virtual Server 2.5.0
Derzeit sprechen wir von einem 85 Mitarbeiter Unternehmen, in welchem das System von ca 60 Mitarbeitern ständig in Anspruch genommen wird.
DB Größe ~13GB (inkl log Datei ~50GB)
Daten zu der VM mit der SQL 2000 DB: http://img24.imageshack.us/img24/8767/screendb.jpg
Auf dem ESX System laufen mehrere VMs inkl unseren Applikation- und DB Servers. Da ich mit meinem Kollegen eigentlich nur das Inhouse CRM Tool betreuen müssen wir auf das hören was unsere IT Abteilung sagt und die sagt, dass es so in Ordnung gehen muss, da man die CPUs Speicher etc einwandfrei den VMs zusichern kann.
Allen Tests nach bin ich mit der Performance überhaupt nicht zufrieden. Es ist wesentlich langsamer geworden. Die Zugriffe auf die Company Maske dauernd zB nun immer ca 12 Sek. oder mehr. Auf der Version 7, die derzeit noch live ist, dauern die Zugriffe zw 3-8 Sek (nachgemessen). Die KeyUser, die das Tool auch täglich testen konnten hatten in der Laufzeit Probleme mit ihren VM Client, da diese hängen blieben oder Sonstiges. Wenn ich selbst auf dem VM Server arbeitete und gewisse User Einstellungen unternahm oder Felder mit dem CRM Tool in der DB anpasste hatte ich ebenfalls oft Hänger oder Abstürze. Ich bin nun einfach unsicher und frage mich woran das liegen kann. Die Tage werde ich das gleiche System auf einem Dedizierten Server aufsetzen, der zwar nicht der aktuellste ist, jedoch eben dediziert und schauen ob sich da performancetechnisch was tut.
Ich las hier im Forum und auch auf anderen Seiten über Plus- und Minuspunkte zu der Virtualisierung, aber keine Aussage überzeugte mich so richtig auch wenn ich langsam dazu tendiere, dass man SQL Server lieber auf einer non-VM-Maschine installieren sollte.
Ich sprach eben noch mit unserem Entwickler, er meinte auch dass es da wohl Flaschenhals = Busbreite gibt und diese auf dem Server ziemlich ausgelastet ist.
Vielleicht haben einige von euch weitere Tipps, Kritik, Verbesserungsvorschläge, paar Punkte mit denen ich beim Management argumentieren könnte.
Danke im Voraus.
EDIT: Außerdem würde mich interessieren wie man die Datenbank optimieren kann. Die DB ist seit Anfangs 2007 im Einsatz, vorher wurden die Einträge aus dem Access importiert. Seit anfangs 2007 wurde die DB nicht optimiert. Man sagte mir, dass man die DB optimieren und in der Performance verbessern kann.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 112991
Url: https://administrator.de/forum/sql-2000-auf-dem-esx-3-5-0-und-die-performance-probleme-112991.html
Ausgedruckt am: 23.12.2024 um 16:12 Uhr
9 Kommentare
Neuester Kommentar
Ich würde mal mit dem Windows Leistungsmonitor versuchen rauszubekommen, ob die langsame Performance an CPU oder Platte liegt, also ob die CPU Auslastung immer hoch ist, oder ob die Disk-Warteschlange recht hoch ist.
Eventuell würde es auch helfen, der VM mehr als eine CPU zuzuweisen. Schließlich hätte das System auf einem eigenen Server sicher mehr als eine CPU/Kern für sich.
Lief der frühere dedizierte Server auch auf dem SAN, oder hatte der eigene Platten?
Eventuell würde es auch helfen, der VM mehr als eine CPU zuzuweisen. Schließlich hätte das System auf einem eigenen Server sicher mehr als eine CPU/Kern für sich.
Lief der frühere dedizierte Server auch auf dem SAN, oder hatte der eigene Platten?
Hallo Andreas und danke für Dein Kommentar.
Über Leistungsmonitor sah ich dass die CPU recht selten die maximale Auslastung erreicht. Wie genau bekomme ich das mit der Disk-Warteschlange raus?
Das mit den mehreren CPUs wäre eine weiterer Lösungsversuch, danke.
Der dedizierte Server hatte eigene Platten, bin ich mir zu 90% sicher, hab das aber an die IT Kollegen weiter gegeben die sollen das mal für mich rausfinden.
Ich bin gespannt ob es besser läuft, wenn ich hier meinen dedizierten Server endlich installiert habe.
Über Leistungsmonitor sah ich dass die CPU recht selten die maximale Auslastung erreicht. Wie genau bekomme ich das mit der Disk-Warteschlange raus?
Das mit den mehreren CPUs wäre eine weiterer Lösungsversuch, danke.
Der dedizierte Server hatte eigene Platten, bin ich mir zu 90% sicher, hab das aber an die IT Kollegen weiter gegeben die sollen das mal für mich rausfinden.
Ich bin gespannt ob es besser läuft, wenn ich hier meinen dedizierten Server endlich installiert habe.
Was auf den Platten los ist siehst Du im Leistungsmonitor beim Datenobjekt <Physikalischer Datenträger>.
Interessante Leistungsindikatoren dort sind:
Bytes gelesen/s
Bytes geschrieben/s
Transfers/s
=> Die geben allerdings nur absolute Werte raus die man in Relation zu den Fähigkeiten des Plattensubsystems stellen muß und zu den Anforderungen der Datenbank an das Plattensubsystem. Wenn z.B. da nur 1000 Transfers/s stehen kann das bedeutet daß das SAN nicht mehr kann oder auch daß die Datenbank einfach nicht mehr Anfragen stellt, auch wenn das SAN 10000 Transfers/s könnte.
Weiter interessant ist:
Aktuelle Warteschlangenlänge
Zeit %
Leerlaufzeit %
Die Warteschlangenlänge gibt an, wieviel Anfragen sich im Windows an die Platte stapeln (je weniger umso besser, wobei es da auch normal ist das es hohe Spitzenwerte gibt, aber der Durchschnitt sollte relativ niedrig sein). Schau DIr da auch mal die Erklärung des Leistungsmonitors an.
Zeit/Leerlaufzeit gibt an, wieviele Prozent der Gesamtzeit die Platte beschäftigt war oder eben auch nicht.
Also Leerlaufzeit bei 0% bedeutet, daß die Platte voll ausgelastet war. Leider ist die Zeit % Anzeige bei Plattenverbünden (RAID/SAN) nicht toll, da auch deutlich mehr als 100% rauskommen kann. Die Leerlaufzeit ist aber im Normalfall ein relativ guter Indikator.
Interessante Leistungsindikatoren dort sind:
Bytes gelesen/s
Bytes geschrieben/s
Transfers/s
=> Die geben allerdings nur absolute Werte raus die man in Relation zu den Fähigkeiten des Plattensubsystems stellen muß und zu den Anforderungen der Datenbank an das Plattensubsystem. Wenn z.B. da nur 1000 Transfers/s stehen kann das bedeutet daß das SAN nicht mehr kann oder auch daß die Datenbank einfach nicht mehr Anfragen stellt, auch wenn das SAN 10000 Transfers/s könnte.
Weiter interessant ist:
Aktuelle Warteschlangenlänge
Zeit %
Leerlaufzeit %
Die Warteschlangenlänge gibt an, wieviel Anfragen sich im Windows an die Platte stapeln (je weniger umso besser, wobei es da auch normal ist das es hohe Spitzenwerte gibt, aber der Durchschnitt sollte relativ niedrig sein). Schau DIr da auch mal die Erklärung des Leistungsmonitors an.
Zeit/Leerlaufzeit gibt an, wieviele Prozent der Gesamtzeit die Platte beschäftigt war oder eben auch nicht.
Also Leerlaufzeit bei 0% bedeutet, daß die Platte voll ausgelastet war. Leider ist die Zeit % Anzeige bei Plattenverbünden (RAID/SAN) nicht toll, da auch deutlich mehr als 100% rauskommen kann. Die Leerlaufzeit ist aber im Normalfall ein relativ guter Indikator.
Hallo Andreas,
danke für Deine Mithilfe. Ich habe nun festgestellt, dass es weder am Server, noch an der DB liegt, das sind die Masken die für uns programmiert sind, irgendwas scheint damit nicht zu stimmen.
LG und danke nochmals für die Hilfe.
danke für Deine Mithilfe. Ich habe nun festgestellt, dass es weder am Server, noch an der DB liegt, das sind die Masken die für uns programmiert sind, irgendwas scheint damit nicht zu stimmen.
LG und danke nochmals für die Hilfe.
Hallo Andreas,
falls Du noch da bist, kannst Du was mit dem Bild hier anfangen bzw mir das Diagramm deuten?
http://img403.imageshack.us/img403/2807/screensql.jpg
Der blaue Strich ist nicht immer da oben aber recht oft, wenn ich mir das gerade so anschaue, scheint es wieder normal zu sein...
falls Du noch da bist, kannst Du was mit dem Bild hier anfangen bzw mir das Diagramm deuten?
http://img403.imageshack.us/img403/2807/screensql.jpg
Der blaue Strich ist nicht immer da oben aber recht oft, wenn ich mir das gerade so anschaue, scheint es wieder normal zu sein...
Seiten/s gibt an, wieviel Speicher in das Pagefile wandern und wieder von dort gelesen werden, also ein Maß für das Paging.
Allerdings ist die Skalierung schlecht, ab 100 Seiten/s schlägt er schon oben an man sieht also nicht, ob es 110 Seiten/s oder 10000 Seiten/s sind.
Prinzipiell ist Paging eine Bremse, Windows paged aber immer, und knapp über 100 Seiten/s ist auch nicht schlimm. Aber mal die Skalierung im Perfmon ändern und schauen, wieviel tatsächlich gepaged wird.
Warteschlangenlängen von durchschnittlich unter 1 ist OK, an den Platten scheints nicht zu liegen.
Allerdings ist die Skalierung schlecht, ab 100 Seiten/s schlägt er schon oben an man sieht also nicht, ob es 110 Seiten/s oder 10000 Seiten/s sind.
Prinzipiell ist Paging eine Bremse, Windows paged aber immer, und knapp über 100 Seiten/s ist auch nicht schlimm. Aber mal die Skalierung im Perfmon ändern und schauen, wieviel tatsächlich gepaged wird.
Warteschlangenlängen von durchschnittlich unter 1 ist OK, an den Platten scheints nicht zu liegen.
Hallo Andreas,
ich hab das mal ne Weile laufen lassen und wie Du schon sagst die Skalierung (auf 1000) geändert und manchmal, nicht sehr oft aber dennoch ging der blaue Strich paar mal an 800 und 500er Skalierung hoch.
Das Diagramm der Platte (grüner Streifen) ging manchmal auch schon bis knapp 200 hoch.
ich hab das mal ne Weile laufen lassen und wie Du schon sagst die Skalierung (auf 1000) geändert und manchmal, nicht sehr oft aber dennoch ging der blaue Strich paar mal an 800 und 500er Skalierung hoch.
Das Diagramm der Platte (grüner Streifen) ging manchmal auch schon bis knapp 200 hoch.
In dem Fall dürfte es kein Speicherproblem sein, hin und wieder unter 1000 Seiten/s finde ich noch nicht tragisch.
Längerer Durchschnitt über 1000, da könnte man eventuell mal an mehr Speicher denken.
Bei der Datentragerwarteschlange, da ist der Skalierungs-Faktor 100, was heißt 200 = 2.
Und das ist auch nicht viel.
Also von Windows Seite aus würde ich sagen, Du hast kein Performanceproblem.
Vermute eher mal schlechtes DB Design, da kann ich DIr allerdings nicht wirklich weiterhelfen. Der Perfmon kann zwar Performancedaten zum SQL Server liefern, nur die Daten zu interpretieren ist schwierig.
Längerer Durchschnitt über 1000, da könnte man eventuell mal an mehr Speicher denken.
Bei der Datentragerwarteschlange, da ist der Skalierungs-Faktor 100, was heißt 200 = 2.
Und das ist auch nicht viel.
Also von Windows Seite aus würde ich sagen, Du hast kein Performanceproblem.
Vermute eher mal schlechtes DB Design, da kann ich DIr allerdings nicht wirklich weiterhelfen. Der Perfmon kann zwar Performancedaten zum SQL Server liefern, nur die Daten zu interpretieren ist schwierig.
Na das ist doch schon mal viel Wert, dass es von Windows keine Probs gibt, also könnte es noch Netzwerk oder die DB selbst sein? Ich tippe auf das Netzwerk, denn vorher war die DB recht ähnlich und lief recht flott.
Gut, dann hast Du mir schon sehr geholfen, vielen Dank Andreas.
Gut, dann hast Du mir schon sehr geholfen, vielen Dank Andreas.
