dataKEKS 11 Geschrieben 11. Juli Melden Geschrieben 11. Juli Hallo Freunde der Microsoft Welt, ich verzweifle gerade an unserem Management Server - er läuft im Schnitt etwa einmal die Woche auf 100% CPU Last, Auslöser Spooler.exe. Eckdaten: - Windows Server 2022 - kein DC - UniFi Manager, Axis Camera Station etc - Drucker von Develop, Epson, HP, und Lexmark werden über ihn gespoolt Wir können bislang nicht eingrenzen woher das kommt, es passiert sowohl innerhalb als auch außerhalb der Schulzeiten, sprich egal ob die Geräte an sein müssten oder nicht, ob gedruckt wird oder nicht - einfach null Ansatz. Durch die bunte Mischung an Aufgaben ist es leider leichter gesagt als getan die Maschine komplett neu aufzusetzen drum würden wir schon gerne versuchen der Ursache auf den Grund zu gehen - nur wie? Dank Monitoring mit Zabbix wissen wir, das die CPU Last gestern bis etwa 19:30 Uhr komplett friedlich war, dann aber sich stetig gesteigert hat und heute morgen war mit Dienstneustart der Spuck auch wieder vorbei, siehe Anlage. Die andere Spitze kommt durch die Datensicherung und erscheint damit in der Nacht jedes Werktags, somit ist das in Ordnung. Was ich schon gecheckt habe ist die Ereignisanzeige, unter den Drucker- und Dokumentdiensten ist die letzte Meldung vom 23. April 2025 und somit auch nicht zielführend Wenn euch nichts anderes einfällt würde ich alle Drucker Schritt für Schritt auf unseren zweiten Management Server auslagern und auf dem problematischen löschen, aber es wäre ja schon cool dem Problem auf den Grund gehen zu können.... Grüße aus BaWü Norbert Zitieren
cj_berlin 1.476 Geschrieben 11. Juli Melden Geschrieben 11. Juli Moin, habt ihr schon versucht, mit Treiberisolation herumzuspielen? Manchmal kann das helfen. Was auch helfen kann, ist das Rendering auf die Clients zu verschieben (da gibt es Gruppenrichtlinien für). Natürlich nur, wenn sie das können. Zitieren
dataKEKS 11 Geschrieben 11. Juli Autor Melden Geschrieben 11. Juli Haben wir noch nie gemacht, lese mich da gerade mal ein. Hast Du damit gute Erfahrungen? Zitieren
cj_berlin 1.476 Geschrieben 11. Juli Melden Geschrieben 11. Juli Sowas ist in der Regel entweder wegen blöder Treiber (da hilft Isolation) oder wegen blöder Druckjobs (da *kann* das Verlegen auf den Client helfen)... Aber manchmal sind Treiber so schlecht, dass da gar nichts hilft als einen generischen zu nehmen und auf irgendwelche fortschrittlichen Features zu verzichten. Spooler Logging hochsetzen: Two Minute Drill: Enabling Print Queue Logging | Microsoft Community Hub Zitieren
Weingeist 176 Geschrieben 11. Juli Melden Geschrieben 11. Juli Häufigste Ärger-Ursache seit MS-Security-Hardening: Verbinden mit Printserver-Name statt Print-Server FQDN. Das prüfe ich immer als erstes da alles an Fehlerbilder möglich ist. Dann würde ich noch das NTLM-Logging sowie Firewall-Logging auf Droped Pakete aktivieren sofern nicht bereits gemacht. Wenn z.B. NTLM systemweit deaktiviert wird, dann versuchen die Drucker sich nach Ablauf des Kerberos Tickets des Users sich permanent per NTLM zu verbinden. Was dann so halb funktioniert (aber nicht sollte) oder eben auch nicht (random). Das ist vor allem bei den Protected Users nach ~3h der Fall. Wenn das viele machen, könnte ich mir schon einen Anstieg der CPU-Last vorstellen. Ansonsten der beste Tipp den ich Dir punkto Drucker geben kann: Ausschliesslich die teure(re)n Business-Geräte der grossen Hersteller verwenden. Da passt auch das Treiberpaket inkl. Updates über viele Jahre. Dann: Printserver immer isoliert betreiben ohne anderen Krams. (einfache Rollbacks). Zitieren
dataKEKS 11 Geschrieben 14. Juli Autor Melden Geschrieben 14. Juli Heute Nacht war es mal wieder so weit: 100% CPU Last.... Also war in diesem die Treiber Isolation leider noch nicht die Lösung, also weiter suchen, denn von alten, nicht mehr benötigten Treibern habe ich den Server bereits befreit und jetzt im Schuljahr (hier an BaWü haben wir noch bis Ende des Monats Schule) darf ich die Treiber nicht aktualisieren... Gruß Norbert Zitieren
zahni 584 Geschrieben 14. Juli Melden Geschrieben 14. Juli Wenn man den Zustand hat,, kann man mit der Process Explorer den zuständigen Thread ermitteln, die CPU-Last verursacht. Wenn das nicht gerade eine OS-Thread ist, kann da Rückschlüsse auf den zuständigen Treiber finden. Ich könnte mir z.B. vorstellen, dass irgendein Consumer-Treiber eine interne Update- oder nach-Hause-Telefonier-Funktion hat und einfach seinen C&C-Server nicht erreichen kann. Wir hatten früher von Mutterkonzern DNS-Auflösung für alle Internetadresse, ohne dass die Server eine Verbindung herstellen konnten. Das kann zu Hängern führen, weil Verbindungsversuche in einen Timeout laufen.... https://learn.microsoft.com/de-de/sysinternals/downloads/process-explorer Zitieren
daabm 1.409 Geschrieben 15. Juli Melden Geschrieben 15. Juli (bearbeitet) Dachte grad auch an Procexp - vielleicht mit konfigurierten Symbols. Aber alleine die DLL-Namen geben ja oft schon Rückschlüsse auf den Verursacher bearbeitet 15. Juli von daabm 1 Zitieren
dataKEKS 11 Geschrieben Samstag um 13:26 Autor Melden Geschrieben Samstag um 13:26 Also außer der der Spooler mir unverständlicher Weise Verbindungen zu einem unseren Terminalserver hat (auf dem bis zu meiner Anmeldung niemand angemeldet war) habe ich noch keine Erleuchtung finden können :-( Zitieren
zahni 584 Geschrieben vor 5 Stunden Melden Geschrieben vor 5 Stunden (bearbeitet) An dieser Stelle dann auf Properties und dann auf "Threads" klicken. Welcher Thread macht die Auslastung? PS: Und man dem Thread dann mal den Stack anschauen, bearbeitet vor 5 Stunden von zahni Zitieren
dataKEKS 11 Geschrieben vor 5 Stunden Autor Melden Geschrieben vor 5 Stunden Da hatte ich eigentlich nachgesehen und nichts entdeckt, aber da es sicher nicht lange auf sich warten lässt checke ich das die Woche noch einmal sowie der Fehler kommt.... Update folgt Norbert Zitieren
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.