LSASS.EXE hohe CPU ...
 
Benachrichtigungen
Alles löschen

LSASS.EXE hohe CPU Last auf allen DC's

6 Beiträge
2 Benutzer
0 Likes
2,269 Ansichten
(@geloeschter-benutzer)
Reputable Member
Beigetreten: Vor 2 Jahren
Beiträge: 263
Themenstarter  

so, ich auch mal mit einem Problem.

 

Wir haben seit Freitag auf einen Schlag auf allen DC's in der Root Domäne eine CPU Auslastung auf nahezu 100%. 

Es wurden davor, dabei keine Updates installiert und keine AD-seitigen Änderungen im System vorgenommen. Man kann im Monitoring schön sehen, dass das Problem wirklich minutengenau um 12Uhr startete. Bisherige Diagnosen haben noch nicht wirklich zu einer guten Eingrenzung führen können. Ich sehe, das grundsätzlich alles funktioniert (ad Replikation untereinander und in die anderen Domänen. Auch Anmeldungen gehen, aber langsam und manchmal mit Timeouts. Jemand sowas schonmal gehabt und einen Ansatz? Bisher sieht es für mich so aus, als werden die DC's geflutet mit Auth Anfragen. Wenn man auf einem DC die NIC deaktiviert, geht seine Last schlagartig runter. Mit dem Performance Monitor sie man auch Netzauslastung ansich..klar, ist ja ein DC. Aber eingrenzen auf bestimmte Netzsegmente ist noch nicht gelungen. 

Leider funktioniert auch das "Active Directory Replication Status Tool" läuft nicht mehr. hätte ich gerne zur Replikationsprüfung genutzt.

 

Falls jemand einen Ansatz hat, immer her damit :)

 

Gruß,
Ralf

 

Dieses Thema wurde geändert Vor 2 Jahren von Anonym

   
Zitat
NorbertFe
(@norbertfe)
Noble Member
Beigetreten: Vor 3 Jahren
Beiträge: 1411
 

Kannst du die dcs vom Rest abkoppeln, um zu sehen ob’s dann runtergeht? (Ja dann steht alles andere) Und dann eben schauen wer die Anfragen stellt. Bei der Leistung müßte man das doch im lan Monitoring sehen können.


   
AntwortZitat

(@geloeschter-benutzer)
Reputable Member
Beigetreten: Vor 2 Jahren
Beiträge: 263
Themenstarter  

leider haben wir ein extrem großes Netz und dies ist leider auch nicht separiert (Client/Server)

Wir vermuten derzeit, dass die Probleme aus einer ESX Umgebung kommen und von den (ggf per Massendeploy) ausgerollten VM's erzeugt werden. 
Deren VLAN wollen wir nun von den ESX Hosts runternehmen, ansonsten kann ich nur mit der Windows Firewall auf den DC's testen und das ist gelinde gesagt Scheisse.

Ich bin mir mittlerweile fast sicher, dass es ein "hausgemachtes" Problem an unserem Hauptstandort ist, denn alle anderen DC's ind en anderen Ländern laufen absolut unauffällig. Auch Replikations/Anmeldefehler sehe ich nicht...nur eben extrem laggy das Ganze. Spätestens am Montag wird das zu Problemen führen.

 

Gruß,
Ralf


   
AntwortZitat
NorbertFe
(@norbertfe)
Noble Member
Beigetreten: Vor 3 Jahren
Beiträge: 1411
 

Ohne separierte Netze ist das natürlich ungünstig. :/ wär zumindest nach der problemfindung dann ein Thema was man angehen sollte.

vdi oder was deployed ihr da?


   
AntwortZitat

(@geloeschter-benutzer)
Reputable Member
Beigetreten: Vor 2 Jahren
Beiträge: 263
Themenstarter  

so, ich denke wir haben es eingegrenzt.

Die Last innerhalb von LSASS.EXE wird zu 99% durch TSG (KDC) Requests erzeugt. Dies von höchstwahrscheinlich nur einem (technischen) User. Daher wird es zu großer Wahrscheinlichkeit ein Deployment bei uns sein, das wohl seit Freitag läuft. Der Performance Monitor mit dem vordefinierten Set für "Active Directory Diagnostic" ist hier sehr hilfreich gewesen. Der Rest der Eingrenzung erfolgte durch gezieltes netzwerkseitiges Abschalten von Etagen/Gebäudeteilen, um die Sache überhaupt erstmal auf eine Abteilung eingrenzen zu können.

Veröffentlicht von: @norbertfe

wär zumindest nach der problemfindung dann ein Thema was man angehen sollte

Da hast du recht..wir sind da bereits in der Umsetzung. Aber das dauert, da sehr viel zu beachten/zu tun ist. Gewachsene Strukturen sind nicht so schnell zu ändern.

 

Gruß und Danke,
Ralf

 


   
AntwortZitat
(@geloeschter-benutzer)
Reputable Member
Beigetreten: Vor 2 Jahren
Beiträge: 263
Themenstarter  

argl, ich mag's ja, Sachen 2x zu schreiben :)

 

Nachtrag für die, die es ggf brauchen können.

der SPN für CIFS in unserer Domäne war durch irgendwas oder irgendwen abhanden gekommen. Die deployten, nicht in der Domäne befindlichen VM's konnten so die relevanten Netzlaufwerke auf "\\domaene.TLD\Folder" nicht mehr mappen. Die dahinter liegenden Scripte auf den VM's liefen dadurch ins Leere, hier unter anderem auch mal Robocopy genannt. Dies erzeugte eine recht hohe Auslastung auf allen DC's bei uns, die Auswirkungen auf die Produktion hatten (TimeOuts). 

Nach Setzen des SPN's für CIFS lief es großteils wieder, manche VM's kamen weiterhin nicht mit dem Mapping klar. Wir haben daher dann einen DNS Alias davor geschaltet. Hinter dem "verstecken" sich nun unsere DC's und man hat eine rudimentäre Lastverteilung, natürlich keine Fehlererkennung, weil per DNS Round Robin eingerichtet. Aber der Vorteil ist, das wir zentral DC's rein oder rausnehmen können, ohne dass die Startscripte in den diversen Entwicklungsabteilungen jedes mal angepasst werden müssen. 

Überlegung ist nun, DNS/Authentifizierungsanfragen für diesen Alias auf den Kemp zu legen, hab ich noch nicht gemacht bisher. Hat dann wiederum den Vorteil, das wir den Dienst dahinter mit prüfen können.

 

Nun denn, vielleicht hilfts wem...vielleicht mir wenn ich in 2  Jahren danach suche :).

 

Gruß,
Ralf

Diese r Beitrag wurde geändert Vor 2 Jahren von Anonym

   
AntwortZitat

Teilen: