Moin WSUS-Profis,

erstmal was zu unserer Umgebung.

HP DL380 G4 Server
2x Xeon 3 GHz
3 GB RAM
System-Partition: RAID1 aus 2x 75 GB SCSI
Daten-Partition: RAID5 aus 3x 75 GB SCSI

Windows Server 2003 Standard Edition R2 mit SP 2, alle aktuellen Patches
Microsoft SQL Server 2005 mit SP 3, ebenfalls aktuelle Patches
WSUS 3.0 mit SP2

Der WSUS-Server muss läppische 50 Clients verwalten, das sollte er ja gut hinbekommen.

Der SQL-Server soll hauptsächlich für unser Produktionssystem zur Verfügung stehen (eine Art ERP-System für unsere Fertigung). Die Datenbank für dieses Produktionssystem misst immerhin 25 GB Daten (plus Log). Nebenbei soll der SQL-Server noch das WSUS-Backend darstellen.

Das Problem ist, das unser Produktionssystem zunehmend langsamer läuft. Die ganze Applikation läuft schleppend, es dauert mehrere Sekunden, bis die Masken sich öffnen, etc. pp. Derlei Beschwerden höre ich als Admin mittlerweile täglich.
Bei einigen Applikationen wird die Abfrage sogar nach 30 Sekunden abgebrochen, weil der SQL-Server länger braucht.

Bei der Analyse des Problems ist mir nun aufgefallen, dass der WSUS wohl sehr gerne und häufig mit dem SQL-Server "spricht". Der SQL-Server stellt einen Bericht zur Verfügung, der sich "Serverdashboard" nennt, dort wird die CPU-Verwendung und der I/O nach Datenbanken aufgeschlüsselt. Es hat mich doch sehr erstaunt, dass der Server seit dem letzten Neustart (05. September) folgendes mitgeschrieben hat:

Datenbank	CPU	I/O
Produktion	25%	33%
SUSDB	75%	67%

Das kann doch nicht wahr sein

Ich habe dann den Server Profiler mitlaufen lassen und mir nur die Zugriffe auf die SUSDB ausfiltern lassen. Und siehe da, es greifen sekündlich Prozesse vom WSUS darauf zu.  Die Prozesse heissen ClientWS, ServerSyncWS, ReportingWS, wsusservice und SimpleAuthWS.

Sie führen grossteils eine Stored Procedure aus namens "spGetChangeTrackingInformation", einer der Parameter ist die aktuelle Systemzeit. Die Stored Procdure läuft bis zu 5 Sekunden und führt bis zu 100.000 (!) Lesevorgänge durch.

Warum greifen diese Prozesse im Sekundentakt auf die Datenbank zu? Da kann ich nämlich verstehen, dass der SQL-Server zum Großteil mit dem WSUS beschäftigt ist und unser Produktionssystem vernachlässigt. Ist das ein Konfigurationsfehler? Leider habe ich keine Einstellungen hierzu im WSUS gefunden. Kann ich diese Frequenz herabsetzen?

Alternativ: kann ich im SQL-Server Prioritäten setzen, so dass er die Produktions-Datenbank höher priorisiert? Oder kann ich Begrenzungen für die SUSDB setzen, z.B. dass er maximal xx % der CPU dafür aufwenden darf?


Es wäre interessant, ob das bei anderen Benutzern von WSUS mit einem SQL-Server als Backend auch so ist. Vielleicht mag einer der Leser mal seinen SQL Server Profiler anwerfen und prüfen, ob seine Prozesse auch so häufig auf die Datenbank zugreifen?


Wenn sich die Frequenz der Zugriffe nicht senken lässt, werde ich wohl den WSUS vom SQL-Server auf diese integrierte Datenbank umstellen müssen. Gibt es dazu bereits Erfahrungen?


Grüsse aus Kiel,
Martin

Ich habe WSUS auf SQL-Server Express 2005 laufen. Hier kann ich leider keinen Server-Profiler laufen lassen, das ich mit dem Management Studio Express arbeite. Im Server Dashboard sehe ich nur die Datenbank SUSDB, also ich habe keinen Vergleich zu den anderen Instanzen. Ich habe allerdings 5 SQL-Server Express Instanzen laufen und bisher nboch keine Probleme im Zugriff feststellen können.

MartinG, wenn Du mir sagen kannst wo ich bei mir eventuell nachsehen kann, wie der Prozesszugriff ist , dann tue ich das. Ich bin nur nicht der SQL-Profi. 

MartinG schrieb on 11.09.09 um 14:20:36:

Leider habe ich keine Verwaltung und auch keinen Aktivitätsmonitor. Ich kann nur ein paar Reports ausführen. U.a. auch den Report "Objekt Execution Statistics". In diesem kommt auch die von Dir genannte Prozedur vor, allerdings mit -auf dem ersten Blick- nicht ungewöhnlichen Werten. Diesen Report könnte ich Dir als PDF zu Verfügung stellen, wenn Du damit was anfangen kannst - ich nicht so sehr. 

MartinG schrieb on 11.09.09 um 14:20:36:


Na wenigstens etwas. Hast Du evtl. die WSUS.MSC irgendwo ständig geöffnet?

MartinG schrieb on 11.09.09 um 14:20:36:


Der WSUS installiert ja eine Site im IIS zusätzlich und die Clients nutzen den Service. Wie sieht die GPO aus? Hast Du die Suchhäufigkeit der Clients verändert?

Sunny schrieb on 11.09.09 um 15:14:35:

Nein, ich habe sie geschlossen, weil ich auch vermutet hatte, dass von ihr die ganzen Anfragen ausgingen. Aber geholfen hat das nicht, die Anfragen kommen dennoch alle 5 Sekunden.

Sunny schrieb on 11.09.09 um 15:14:35:

Ja, ich habe (bzw. hatte) die Häufigkeit per GPO auf 8 Stunden gesetzt, da unsere Clients noch einige Updates nachzuholen hatten. Habe sie nun aber wieder auf den Standardwert (22 Stunden) zurückgestellt.

Das wird nun ein wenig dauern, bis die neue GPO sich verbreitet hat. Ich beobachte weiter, wie die Last auf dem SQL-Server aussieht; sie hat sich aber auf jeden Fall schon verringert, die CPU-Last steht "nur" noch zu 66% auf der SUSDB und der IO zu 55%.

Ausserdem werde ich am Sonntag den SQL-Server stoppen und die Festplatten einmal gründlich defragmentieren, das sollte hoffentlich auch helfen. Werde mich dann am Montag nochmal melden.

Danke für eure Hilfe schonmal!

So, die Festplatten des Servers sind frisch defragmentiert, die SUSDB (Grösse 2 GB, davon 1,5 GB verwendet) liegt in einem einzigen Dateifragment vor. Ausserdem habe ich erneut alle Indizes neu erstellt bzw. organisiert. (Unsere Produktionsdatenbank habe ich auch komplett defragmentiert und reindiziert)

Noch kann ich keine Einschätzung geben, ob sich unsere Produktionsdatenbank wieder schneller "anfühlt".
Beim WSUS finde ich aber bedenklich, dass beim Öffnen der Seite "Synchronisierungen" in der MSC ein Timeout aufgetreten ist; offenbar dauerte diese Abfrage so lange, dass die MSC ausgestiegen ist.

Sunny schrieb on 11.09.09 um 20:17:15:

Danke für das Angebot. Momentan habe ich aber geplant, die WSUS-Datenbank vom SQL-Server zu entfernen.

Ich kann mir die Probleme momentan nur so erklären, dass der SQL-Server bedingt durch die ständigen Zugriffe der WSUS-Dienste einen Großteil der SUSDB im Cache/Arbeitsspeicher vorhält, so dass kein Platz mehr für unsere Produktionsdatenbank ist. Warum die Dienste so oft zugreifen, ist mir schleierhaft.

Daher habe ich mir überlegt, die WSUS-Daten umzuziehen und die Internal Database zu nutzen. Hat da vielleicht jemand Erfahrungen gemacht, wie der Export aus dem SQL-Server und der Import in die Internal Database funktioniert? Muss ich WSUS dafür neu installieren? Denn ich möchte es vermeiden, alle Updates noch einmal freizugeben/abzulehnen und erneut herunterzuladen.

Sunny schrieb on 14.09.09 um 11:43:10:

Danke für den Tipp mit den Synchronisierungen. Habe das Script noch ein wenig angepasst, so dass es nur die Synchronisierungen löscht, die älter als eine Woche sind.

DELETE
FROM tbEventInstance
WHERE EventNamespaceID = '2'
AND EventID IN ('381', '382', '384', '386', '387', '389')
AND DATEDIFF(d, TimeAtServer, GETDATE()) > 7 

Sunny schrieb on 14.09.09 um 11:43:10:

Hm, kann man denn mehrere WSUS-Instanzen auf einem Server installieren? Wenn ich Dich richtig verstehe, würde ich dann parallel einen neuen WSUS mit der Internal Database installieren, diesen zunächst als Downstream-Server einstellen, dann zum Haupt-Server ernennen, und den alten WSUS deinstallieren.

Oder müsste ich auf einem zweiten Server temporär einen WSUS installieren, der wie beschrieben als Downstream arbeitet?

Wie wäre es alternativ, den WSUS zu deinstallieren (man kann die Datenbank, Protokolle und heruntergeladenen Updates erhalten), dann mit der WID wieder zu installieren und anschliessend die Datenbank des SQL-Servers über die neu erzeugte Datenbank der WID zu kopieren? (Natürlich würde ich vorher WSUS, IIS und WID stoppen, damit es da keine Probleme gibt.)

Zumindest scheinen die Datenbanken von WID und dem SQL-Server kompatibel zu sein:
(Du musst Dich Einloggen oder Registrieren um Multimediadateien oder Links zu sehen).


PS: Danke übrigens für das WSUS-Tool von Dir, das hat mir bei einigen PCs geholfen.

Hi Al Bundy99,

danke für den Tipp, aber leider hilft das in diesem Fall nicht. Der SQL-Server wuchtet ja bereits unsere große Produktionsdatenbank (25 GB, siehe oben), und dafür darf und soll er gerne so viel Speicher nutzen, wie eben nötig - aktuell sind es 1,7 GB. (Von den vorhandenen 3 GB RAM zwackt der Windows Server sich selbst 1 GB ab, also lässt der SQL-Server immerhin noch 300 MB für die anderen Prozesse frei... Nicht ganz fair, aber "der darf das" )

Die WSUS-Datenbank ist ja nur "Beiwerk" auf unserem SQL-Server, und deshalb will ich sie auch wieder entfernen und in die eigene Windows Internal Database umziehen.