BoeserWest 10 Geschrieben 5. Juli 2006 Melden Teilen Geschrieben 5. Juli 2006 Hallo zusammen, ich hab hier ein kleines mittelschweres Problem :). Ich hab hier einen Windows 2003 SP1 / MS-SQL 2000 SP3 Server im Einsatz. Darauf läuft logischerweise auch eine Datenbank. Diese hat laut TaskPad-Ansicht ca. 1 GB. Das Transaktionsprotokoll ca. 500 MB wobei davon meist nur 50 MB in verwendung sind. Der Server läuft meistens 1-2 Wochen recht optimal, ohne jegliche Performance Probleme. Nach diesen 1-2 Wochen wird er dann immer langsamer, so dass Abfragen von der Client-mde bis zu 45 Sekunden dauern. Zu diesem Zeitpunkt hat die sqlservr.exe ca. 1500 MB Arbeitsspeicher in Verwendung. Also das was ich ihm maximal erlaubt habe. Der Server hat dann noch ca. 200 MB Speicher frei. Das Problem hört erst auf, wenn ich den Server neu gestartet habe - das kann aber keine dauerhafte Lösung sein bei einer geplanten ausfallsicherheit von 99,9 % :D Kennt jemand das Problem oder gibt es dafür ein Heilmittel oder sowas? Hoff ihr könnt mir helfen, Gruß bk. Zitieren Link zu diesem Kommentar
goscho 11 Geschrieben 5. Juli 2006 Melden Teilen Geschrieben 5. Juli 2006 Hallo BoeserWest (hier GuterOst:D :D :D ) Ich hab hier einen Windows 2003 SP1 / MS-SQL 2000 SP3 Server Ich glaube, du hast schon SP4 drauf, denn bei meiner letzten Installation hatte der W2K3 den SQL 2000 nur mit SP4 laufen lassen. Egal, eventuell mal updaten. Zu deinem Problem. Ich vermute stark, dass hat mit den Transaktionslogs zu tun. Ich lasse bei meinen Kunden nachts die Datenbanken komplett sichern und das Transaktionsprotokoll kürzen. Deshalb merke ich dort keine Verzögerungen im normalen Betrieb. Eine Alternative wäre ja auch noch, dass du nachts den SQL-Server stoppst und wieder startest, per Task. Such' mal hier im Board nach, wirst du bestimmt was finden. Die wirkliche Speichernutzung des SQL-Servers kannst du aber nicht im Taskmanager erkennen. Dieser gibt nichtbenutzten Speicher wieder frei, es wird aber nicht im Taskmanager angezeigt. Gruß Goscho Zitieren Link zu diesem Kommentar
hh2000 10 Geschrieben 5. Juli 2006 Melden Teilen Geschrieben 5. Juli 2006 Moin, mal Interessehalber, wieviel Speicher hat der Server und welche Schalter sind in der Boot.ini gesetzt? Habe evtl. das gleiche Problem, ein Server ist sehr sehr langsam (SQL und Konsole) geworden und im Taskmanager waren ca. 1,9GB in Benutzung, Ereignislog zeigt keine fehlerhaften Einträge. System: Athlon 64 X2 4200, 2GB RAM Boot.ini Starteintrag (Von Installation erzeugt): multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Standard" /fastdetect /NoExecute=OptOut /usepmtimer Gruß Kai Zitieren Link zu diesem Kommentar
BoeserWest 10 Geschrieben 6. Juli 2006 Autor Melden Teilen Geschrieben 6. Juli 2006 Moin Kai, ich wüsste zwar nciht was der Starteintrag der Boot.ini damit zu tun hat aber egal ;) multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003 Standard" /noexecute=optout /fastdetect System Intel XEON 2,8 GHz 2 GB RAM @ goscho ... SQL 2000 braucht nur SP3 um unter 2003 zu laufen - desweiteren habe ich die geile aussage unserer entwickler bekommen, dass es mit SP4 Performance-Probleme gibt *gg* Angeblicht liegt es aber immer an uns dass es alles so laaaagt :suspect: Transaktionsprotokoll wird natürlich auch täglich gesichert und gekürzt ... wäre ja doof wenn nicht :D Ich hab das ganze ding jetzt auch schon auf Deadlocks geprüft, aber auch hier ist nichts zu sehen. So langsam bin ich ratlos Zitieren Link zu diesem Kommentar
BoeserWest 10 Geschrieben 6. Juli 2006 Autor Melden Teilen Geschrieben 6. Juli 2006 Noch zu der Sache mit dem Service stoppen und neu starten ... das kanns ja wohl auch nicht sein, wie soll man so eine Ausfallsicherheit von 99,8 % erreichen? *seufz* Zitieren Link zu diesem Kommentar
hh2000 10 Geschrieben 6. Juli 2006 Melden Teilen Geschrieben 6. Juli 2006 Moin Kai, ich wüsste zwar nciht was der Starteintrag der Boot.ini damit zu tun hat aber egal ;) Speicherverwaltung ...;) auf einem anderen Server mit W2k3 / Exchange 2k3 habe ich auch nur 2GB RAM, aber das Setup hat mir zusätzlich noch die Schalter /3GB /USERVA=3030 eingesetzt. Was ist nun besser mit real 2GB und Datenbank (SQL oder Exchange)? Zitieren Link zu diesem Kommentar
Gulp 254 Geschrieben 6. Juli 2006 Melden Teilen Geschrieben 6. Juli 2006 Alles was über den tatsächliche installierten RAM hinausgeht (in der gesamten Speicherverwaltung, also OS und Anwendung - in dem Fall SQL) ist suboptimal, da hier Prozesse/Vorgänge auf das Pagefile (die Auslagerungsdatei) ausgelagert werden und somit auf die Platte wandern. Festplatten sind zur Zeit noch deutlichst langsamer als RAM und da fängt das Problem an, SQL oder Teile davon werden ausgelagert und schon sinkt die DB Performance dramatisch. Hier hilft nur RAM, RAM und nochmals RAM und selbst da sind noch nicht alle Probleme weg, da a:) nur die Versionen ab 2003 Enterprise mehr als 4GB verwenden können, b:) dann die 2GB/2GB bzw mit entsprechendem Switch 3GB/1GB Verteilung von User- und Systemanwendungen greifen und gerne mal Probleme bereiten und c:) das Ganze auch noch verflucht teuer in der Anschaffung wird und nicht jedes Wald und Wiesen Board das packt bzw unterstützt. Eine Ausweichmöglichkeit wären die 64-bit Versionen mit entsprechender Hardware (die ja auch teuer genug ist) und der 64-bit DB. Grüsse Gulp Zitieren Link zu diesem Kommentar
rablu 10 Geschrieben 6. Juli 2006 Melden Teilen Geschrieben 6. Juli 2006 Ueberpruefe: - ob Indizies richtig gesetzt sind - ob Indizies regelmaessig aktualisiert werden - ob die Datenbankstatisk regelmaessig aktualisiert wird Zur weitergehenden Performanceanalyse nimm den SQL Profiler und den SQL Query Analyzer und analysiere damit die uebergebenen SQL Statements. Zitieren Link zu diesem Kommentar
BoeserWest 10 Geschrieben 7. Juli 2006 Autor Melden Teilen Geschrieben 7. Juli 2006 Huhu, das waren ja nun schonmal ein paar ganz nützliche Tips :) Also nur nochmal so zum Anmerken, der Server hat 2 x 2,8 GHz Xeon Prozessoren drin :D Die Sache mit den Indizes war mir auch klar, hier wird aber täglich im Zuge der Sicherung auch ein Task gestartet, der die Indizes optimiert und überprüft - bisher immer ohne Fehler. SQL-Profiler habe ich auch schon laufen lassen, Deadlocks sind keine zu erkennen. Die Abfragen bzw. Update/Insert Anweisungen der Clients sind auch nur Minimal. Es handelt sich ja auch nur um eine Datenbank mit ca. 50-70 Usern - wie macht es dann ein großer Konzern mit über 1000 Usern Speichererweiterung ... jo extrem teuer da das ja auch wieder ECC Ram sein muss :( Also als System läuft Windows 2003 Standard - wieviel würde da denn rein passen? Wäre es evtl. sinnvoll die Pagefile.sys auch auf das Raid 5 zu übertragen ? Läuft aktuell auf der RAID 1 konfig mit dem OS zusammen. So langsam aber sicher muss ich eine Lösung finden - die User würden mich am liebsten stündlich lünchen :wink2: Zitieren Link zu diesem Kommentar
hh2000 10 Geschrieben 7. Juli 2006 Melden Teilen Geschrieben 7. Juli 2006 Hast Du evtl. noch zusätzliche Fehler oder Warnungen im Eventlog (COM+, DCOM)? Zitieren Link zu diesem Kommentar
BoeserWest 10 Geschrieben 7. Juli 2006 Autor Melden Teilen Geschrieben 7. Juli 2006 Nein leider auch nichts, eventlog ist sauber sonst hätte ich wenigstens mal eine anlaufstelle :) Zitieren Link zu diesem Kommentar
Gulp 254 Geschrieben 7. Juli 2006 Melden Teilen Geschrieben 7. Juli 2006 ...... snip Speichererweiterung ... jo extrem teuer da das ja auch wieder ECC Ram sein muss :( Also als System läuft Windows 2003 Standard - wieviel würde da denn rein passen? Wäre es evtl. sinnvoll die Pagefile.sys auch auf das Raid 5 zu übertragen ? Läuft aktuell auf der RAID 1 konfig mit dem OS zusammen. So langsam aber sicher muss ich eine Lösung finden - die User würden mich am liebsten stündlich lünchen :wink2: Mehr als 4GB RAM unterstützen nur die Versionen ab Enterprise und die 64-bit Versionen (wie ich bereits schrieb). Eine Verlagerung des Pagefile auf ein RAID 5 bringt auch nichts, da tendenziell RAID 5 etwas langsamer in der Schreibperformance ist als RAID 1, da ja noch die Paritätsinformationen zusätzlich geschrieben werden müssen. Hinten raus macht es sowieso keinen Unterschied, sobald ausgelagert wird (egal ob auf RAID 5, 1 oder sonstwas) wird es zäh, eben weil Festplatten langsamer als RAM sind. Wenn die DB grundsätzlich performant ist (keine Deadlocks, Indizies ok, etc) wirst Du wohl nicht umhin kommen zB die Statements auf Effizienz zu checken, ob beispielsweise stark verschachtelte Statements verwendet werden, und ggfs zu optimieren und mehr RAM zur Verfügung zu stellen. Grüsse Gulp Zitieren Link zu diesem Kommentar
hh2000 10 Geschrieben 7. Juli 2006 Melden Teilen Geschrieben 7. Juli 2006 ergänzend zu dem was gulp gesagt hat, kannst Du dein Transaction-Log auf einen anderen Platten-Verbund legen. z.B. System auf ein RAID 1 DB auf ein anderes RAID 1 und TLog auf ein anderes RAID1 Meine Config in diesem Fall: - System und DB auf einem RAID 1 - TLog auf einem anderen RAID1 Gruß Kai Zitieren Link zu diesem Kommentar
BoeserWest 10 Geschrieben 7. Juli 2006 Autor Melden Teilen Geschrieben 7. Juli 2006 Danke für eure Ausdauernde Hilfsbereitschaft :) Ich hab jetzt mal eben bei Dell angefragt was ein Original Speicher kostet ... hab fast ne halbe Stunde gebraucht um mich von dem Schock zu erholen ... dafür kauf ich nen ganzen Rechner :rolleyes: Nichts desto trotz werd ich nicht umher kommen weitere 2 Gig einzubauen ... wenn dat nicht läuft dann verklag ich die Programmierer der Datenbank :D thx bk Zitieren Link zu diesem Kommentar
hh2000 10 Geschrieben 7. Juli 2006 Melden Teilen Geschrieben 7. Juli 2006 und dann wird der Server eben erst nach 2 Wochen langsam .... :D :D Spaß beiseite, kannst Du nicht mit den Entwicklern der DB sprechen? Nicht das hier irgendwo ein Memory-Leak ist und der Server nun nur später abschmiert als mit 2 GB. M.E. sollte die DB auch mit 2GB laufen, wenn auch evtl. etwas langsamer und es sollte auf gar keinen Fall ein Reset des Rechner benötigt werden. Mehr Speicher => Kategorie "optimieren" TLog auf andere Platte => Kategorie "optimieren" Reset erforderlich => irgendein Fehler vorhanden (< den suche ich bei meinem Problem-Server auch) Gruß Kai Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.