Wir haben zwei Windows Server 2008 SP2-Domänencontroller (leider nicht 2008 R2) in einer kleinen 150-Clientdomäne, die eine sehr hohe CPU-Auslastung aufweisen. Die Domänencontroller weisen beide dasselbe Verhalten auf und werden auf vSphere 5.5.0, 1331820 gehostet. Alle zwei oder drei Sekunden springt die CPU-Auslastung auf 80-100% und sinkt dann schnell, bleibt für ein oder zwei Sekunden niedrig und springt dann auf nochmal.
Ein Blick auf die historischen Leistungsdaten der virtuellen Maschine zeigt, dass dieser Zustand mindestens ein Jahr andauert, die Häufigkeit jedoch seit März zugenommen hat.
Der fehlerhafte Prozess ist SVChost.exe, der die Dienste DHCP-Client (dhcpcsvc.dll), EventLog (wevtsvc.dll) und LMHOSTS (lmhsvc.dll) umschließt. Ich bin mit Sicherheit kein Windows-Interna-Experte, aber ich konnte beim Anzeigen des Prozesses mit Process Explorer anscheinend nichts besonders Falsches feststellen, als dass das EventLog eine Menge RpcBindingUnbind- Aufrufe auslöst .
Zu diesem Zeitpunkt habe ich keinen Kaffee und keine Ideen mehr. Wie soll ich dieses Problem weiterhin beheben?
mmc.exe(wahrscheinlich das Standardfenster "Server-Manager"?) Geöffnet sind, wurden auch regelmäßige Spitzenwerte erreicht.Antworten:
TL; DR: EventLog-Datei war voll. Das Überschreiben von Einträgen ist teuer und / oder in Windows Server 2008 nicht sehr gut implementiert.
Bei @pk. und @joeqwerty Vorschlag und nachdem ich herum gefragt hatte, entschied ich, dass es am wahrscheinlichsten schien, dass eine vergessene Überwachungsimplementierung die Ereignisprotokolle kratzte.
Ich habe den Microsoft-Netzwerkmonitor auf einem der Domänencontroller installiert und mit dem Filtern nach MSRPC begonnen
ProtocolName == MSRPC. Es gab viel Verkehr, aber alles befand sich zwischen dem RODC unseres Remote-Standorts und benutzte leider nicht denselben Zielport wie der abhörende EventLog-Prozess. Verdammt! Da geht diese Theorie.Um die Dinge zu vereinfachen und das Ausführen der Überwachungssoftware zu vereinfachen, habe ich mich entschieden, den EventLog-Dienst von SVCHost zu entpacken. Der folgende Befehl und ein Neustart des Domänencontrollers reservieren einen SVCHost-Prozess für den EventLog-Dienst. Dies erleichtert die Untersuchung ein wenig, da an diese PID nicht mehrere Dienste angeschlossen sind.
Ich habe dann auf ProcMon zurückgegriffen und einen Filter eingerichtet, um alles auszuschließen, was diese PID nicht verwendet hat. Ich habe nicht Tonnen von Fehlversuchen von EventLog zu öffnen fehlenden Registrierungsschlüssel wie als mögliche Ursache angegeben hier (scheinbar crappy Anwendungen als registrieren Ereignisquellen in extrem schlechten Wege). Voraussichtlich habe ich viele erfolgreiche ReadFile-Einträge im Sicherheitsereignisprotokoll (C: \ Windows \ System32 \ WinEvt \ Logs \ Security.evtx) gesehen.
Hier ist ein Blick auf den Stack bei einem dieser Ereignisse:
Sie werden zuerst die RPCBinding und dann die RPCBindingUnbind bemerken. Es gab viele davon. Wie Tausende pro Sekunde. Entweder ist das Sicherheitsprotokoll sehr beschäftigt oder es funktioniert etwas nicht richtig mit dem
Security.evtxProtokoll.In EventViewer protokollierte das Sicherheitsprotokoll nur zwischen 50 und 100 Ereignisse pro Minute, was für eine Domäne dieser Größe angemessen schien. Verdammt! Es geht um die Theorie Nummer zwei, dass wir eine Anwendung mit sehr ausführlicher Ereignisüberwachung hatten, die links in einer vergessenen Ecke eingeschaltet war und immer noch pflichtbewusst davon tuckerte. Es wurden immer noch viele (~ 250.000) Ereignisse aufgezeichnet, obwohl die Rate der protokollierten Ereignisse niedrig war. Loggröße vielleicht?
Sicherheitsprotokolle - (Rechtsklick) - Eigenschaften ... und die maximale Protokollgröße wurde auf 131.072 KB festgelegt und die Protokollgröße lag derzeit bei 131.072 KB. Das Optionsfeld "Ereignisse nach Bedarf überschreiben" wurde aktiviert. Ich dachte mir, dass das ständige Löschen und Schreiben in die Protokolldatei wahrscheinlich harte Arbeit ist, besonders wenn sie so voll ist, dass ich das Protokoll lösche (ich habe das alte Protokoll gespeichert, nur für den Fall, dass wir es später für die Überwachung benötigen) und den EventLog-Dienst erstellen lassen eine neue leere Datei. Das Ergebnis: Die CPU-Auslastung erreichte wieder ein gesundes Niveau von etwa 5%.
quelle
Möglicherweise können Sie dies durch Erstellen eines kleinen Datenkollektorsatzes verfolgen.
tracerpt –l “file.etl” –of CSVWenn meine Vermutung stimmt, werden Sie sehen, dass einige Geräte (IP: Port) Ihren DC hämmern.
quelle
Sicherlich eine schwierige. Abgesehen davon, dass Sie es einfach in Ruhe lassen (1 CPU / 50% Last, wen interessiert das?), Könnten Sie versuchen, einen neuen Domänencontroller einzurichten und nach einigen Tagen feststellen, ob dieser Ihnen dasselbe Verhalten verleiht. Wenn dies der Fall ist, möchten Sie möglicherweise eine Wireshark-Ablaufverfolgung durchführen (offensichtlich verursacht dies dann etwas vom Netzwerk).
Das nächste, was mir einfällt, ist ein einfacher Anruf bei Microsoft
quelle
Travis, "Archiv" hat dir nicht geholfen. Tatsächlich hat es Ihnen nicht geholfen, das Ereignisprotokoll zu löschen, als es 2/3 größer war. Aber "Archiv" hat KraigM geholfen.
kce: Löschte eine 131 MB "Überschreib" -Datei und verringerte die Leistung von etwa 55% auf 5%. FRAGE: Vielleicht haben Sie irgendwann wieder eine hohe Auslastung festgestellt, da dies (a) nur ausgelöst werden kann, wenn die Überschreibbedingung erreicht ist oder (b) Es kann linear schlechter werden, wenn die Größe der gelöschten Datei von 0 MB auf 131 MB ansteigt.
Einige sehen dies für die Datei security.evtx und andere für das Taskplaner-Betriebsprotokoll. Ich schlage vor, Ihr AV (welches Sie verwenden) vollständig zu deinstallieren und zu versuchen. Eindringlinge müssen ihre Spuren verbergen und ihre Spuren werden in geplanten Aufgaben erstellt, die sie einrichten oder bei denen sie sich anmelden. Sie verbergen ihre Spuren, indem sie die Punkte in diesen Ereignisprotokollen aufheben und sie neu schreiben, um über ihre Spuren zu springen. AVs können dies auf eine fehlerhafte Weise erkennen, da, wenn es Microsoft wäre, mehr von dieser hohen Auslastung berichtet worden wäre, aber ich sehe nur wenige Beiträge beim Googeln. Ich sehe dies auch auf Server 2008 R2 für das security.evtx-Protokoll. Keine Ereignisprotokoll-Abonnenten, keine externen Monitore. Ich habe ein paar AV-Dienste (McAfee) beobachtet, die ausgeführt wurden, und sie hatten eine sehr geringe Gesamtauslastung für einen Server, der so viele Tage in Betrieb war, dass ich vermute, dass er deinstalliert wurde, und dies nur teilweise (benötigt wahrscheinlich das spezielle Deinstallationsprogramm von McAfee), und ich frage mich, ob es Haken gibt Die verbleibenden (oder sogar normal installierten) McAfee-Dienst- oder McAfee-Filtertreiber, die ausgeführt werden, schreiben irgendwie normal in das Ereignisprotokoll und entscheiden in ihrer Filterung, dass sie dies in einen vollständigen Lesevorgang des gesamten Ereignisprotokolls umwandeln müssen. Vertrauen Sie mir, die Filtertreiber von Drittanbietern einiger AV-Unternehmen sind fehlerhaft und auf jeden Fall 10000x fehlerhafter als die Implementierung der Ereignisprotokollierung von Microsoft, was sehr wahrscheinlich perfekt ist. Zusammenfassend lässt sich sagen, dass 100% ALLE AV-Dateien deinstallieren, WENN das Problem behoben ist. Wenn ja, arbeiten Sie mit Ihrem AV-Unternehmen zusammen, um das Problem zu beheben. Es ist nicht ratsam, Ausnahmen für Dateien zu machen.
Beachten Sie bei der Verwendung von procmon auch die WriteFile-Aufrufe, da der Filtermanager durch das Writefile veranlasst wird, die gesamte Datei zu lesen. In meinem Fall wurde der Lesevorgang ungefähr 30 Sekunden nach Abschluss des Schreibvorgangs gestartet, was möglicherweise beabsichtigt ist. Aber es war konsistent und in meinem Fall hatte die Datei eine Größe von 4 GB, und das Lesen der Datei umfasste 64 KB Readfiles mit einer Länge von jeweils 64 KB. Dabei wurden 35% der CPU-Kapazität beansprucht. Sehr traurig.
Update 23.03.2016 Ich habe mir die Filtertreiber auf diesem Computer angeschaut, nachdem festgestellt wurde, dass dies durch einen von ihnen verursacht werden musste (der Ereignisprotokollmechanismus könnte niemals eigenständig fehlerhaft sein, oder die Anzahl der Berichte dieser Art wäre umwerfend und es ist nicht). Ich sah einige Filtertreiber von einem AV-Gerät und von einem bekannten Drittanbieter, der die Leistung von Festplatten für virtuelle Maschinen durch Vorausschau-Lesevorgänge steigert, und fragte den Chefarchitekten (der sehr freundlich und zuvorkommend war), ob sein Produkt das gesamte System möglicherweise übermäßig aggressiv liest Sicherheitsereignisprotokoll (was eindeutig pro Procmon geschah). Dies ist hilfreich für kleinere Sicherheitsprotokolle, jedoch nicht für die hier angegebenen Größen. Auf keinen Fall sagte er. Er stimmte zu, dass es der AV sein könnte.
Wie ich dem Azure-Kollegen weiter unten sagte, haben wir keine Nachfolger des ursprünglichen Posters, wenn das Problem nach dem Löschen des Ereignisprotokolls erneut aufgetreten ist, da dies eine häufige und fehlerhafte Lösung ist, da die Leistung mit der Zeit immer weiter abnimmt. Dies nennt man "Follow-up" und ich sehe aus erster Hand, dass die Lösung des ursprünglichen Posters diejenigen täuschen kann, die nicht glauben, dass sie das Problem gelöst haben. Fast hätte ich mich auch täuschen lassen. Ich habe das Ereignisprotokoll gelöscht und die Leistung verbessert - aber ich habe procmon verwendet und festgestellt, dass das Problem im Laufe der Zeit immer langsamer wird, bis es problematisch wird. Aus irgendeinem Grund kritisiert mich der Azure-Gefährte scharf, als das Originalplakat nicht weiterverfolgt wurde (möglicherweise gestorben, gefeuert, gekündigt oder beschäftigt). Der unten stehende Azure-Mitarbeiter meint, wenn das Original-Poster nicht weiterverfolgt wurde, muss es ein behobenes Problem sein. Das ist ärgerlich und rätselhaft, denn ich kann mir niemanden vorstellen, der technisch so hoch angesehen ist und diese Position einnehmen würde. Ich entschuldige mich, wenn ich einen Nerv getroffen habe. Vielleicht bin ich in meinem Aktivismus anderswo im Internet, wo ich Leute anrufe, auf die Nerven gegangen - hier (Serverfehler) bin ich einfach nett und teile tiefes technisches Wissen, und das Ergebnis von Herrn Azure ist ein Mobbing darüber, ob mein technischer Beitrag gerade ist notwendig oder ist für irgendeinen blog von mir (ich habe keinen solchen blog). Ich habe noch nicht die Absicht, diesen Link an ungefähr ein halbes Dutzend wichtige Bekannte bei Microsoft zu senden und sie zu fragen, was mit dieser Art von Mobbing von einem wichtigen MSFT-Mitarbeiter los ist, da ich mich einzig und allein darauf konzentriere, das Beste von Interesse zu haben Die Community im Kopf und die Antworten von Mr. Azure sind, in wenigen Worten, unglaublich, lebensgefährlich. nervenaufreibend und mobbend - was sicher manchen Spaß macht, anderen etwas anzutun. Ich war anfangs beleidigt, bin aber darüber hinweg und weiß, dass passive oder aktive Leser das, was ich sage, und meine Kommentare zu schätzen wissen - ich stehe zu 100% dahinter, ohne Rücksicht auf rechtliche Gründe, warum es hier auf subtile Weise unangemessen ist oder nicht. Herr Azure, bitte übe Freundlichkeit und unterlasse es, meine Kommentare in ein schlechtes Licht zu rücken. Gehen Sie einfach darüber hinweg und zeigen Sie Zurückhaltung und kommentieren Sie nicht noch einmal. Bitte übe Freundlichkeit und verzichte darauf, meine Kommentare in ein schlechtes Licht zu rücken. Gehen Sie einfach darüber hinweg und zeigen Sie Zurückhaltung und kommentieren Sie nicht noch einmal. Bitte übe Freundlichkeit und verzichte darauf, meine Kommentare in ein schlechtes Licht zu rücken. Gehen Sie einfach darüber hinweg und zeigen Sie Zurückhaltung und kommentieren Sie nicht noch einmal.
Harry
quelle