Udostępnij za pośrednictwem

LSASS: 100% CPU

  • Artykuł

Das begleitet unser Team schon seit Jahren - Anfragen von Kunden die sich über 100% CPU Last auf einem oder allen Domain Controllern beklagen. Um gleich von Anfang an Klarheit zu schaffen: Das ist doch prima, dann weis man doch, dass die CPU nicht umsonst gekauft wurde. Und die Mär von „LSASS leakt doch" möchte ich gleich entkräften. Seit Windows 2003 habe ich selber erst ein einziges Mal ein Leak nachweisen können. (Das war alles nicht ganz einfach und trat nur unter ganz speziellen Umständen auf und führte nur in bestimmten SC Logon Stresstests zu echten Problemen, doch es war tatsächlich ein Leak - was wir natürlich gefixt haben).

Aber im Ernst, was soll LSASS denn sonst machen? LSASS (Local Security Authority Sub-System) ist ein Local Security Provider, besteht im wesentlichen aus LSASS.EXE die dann die eigentlich wichtigen DLLs aufruft: LSASRV.DLL, SAMSRV.DLL (und natürlich auch NTDLL.DLL, CRTDLL.DLL, KERNEL32.DLL). Auf einem Domain Controller ist somit LSASS der wichtigste Service, etwas anderes CPU intensives hat darauf nichts verloren. Natürlich kennen wir Branch Office Scenarios wo ein Rechner in der Filiale steht, dieser gleichzeitig DC\GC, DB und Mail Server ist. Nach unserer Meinung ist das alles andere als ideal und birgt gewaltiges Gefahrenpotential. Allein der Security Aspekt, jeder Anwendungs Admin muss dann gleich Domain Admin sein usw.

Okay, in unserer heilen Welt ist also LSASS der einzige CPU und Speicherintensive Prozeß auf dem DC. Genau so wurde LSASS auch designed: „Was du an Resourcen brauchst, nimm es dir" - ist hier die Philosophie. Auf 32bit Systemen kann es da schon mal eng werden, wenn LSASS sich plötzlich 1,5GB der vorhandenen 2GB nimmt - und auch behält. Aber auch das ist kein Problem sondern gewollt. Um seine Arbeit zu erledigen nimmt LSASS sich also alles an CPU und RAM was es bekommen kann. Das ist grundsätzlich also noch kein Problem - ein Problem wird es erst dann, wenn die CPU Last quasi nicht mehr sinkt (1-2h CPU auf 100% z.B: während der Anmeldezeit ist durchaus okay, aber nicht 10h am Tag) oder wenn wirklich Probleme auftreten, z.B. Fehlermeldungen, Logon geht nicht durch oder dauert extrem lange, Replikation hat Probleme o.ä. Erst wenn solche echten Probleme dazu kommen, dann können wir von einem Problem sprechen. Also: nicht in Panik geraten wenn LSASS mal wieder auf 100% CPU ist, wenn sonst alles geht - prima.

Wie kann ich also feststellen ob ich ein Problem habe und wenn ja, welches? Nun, grundsätzlich geht es hier um Fehler oder Fehlversagen. Das sollte ja im Event.log oder durch Fehlermeldungen sichtbar sein oder von den Anwendern berichtet werden. Oder - noch besser, ich stelle es proaktiv mittels Performance Monitoring fest. Mit Performance Monitoring ist es so wie mit Hubraum: Hubraum ist durch nichts zu ersetzen als durch mehr Hubraum. Genauso ist es mit Performance Monitoring. Nur wenn ich regelmäßig meine Umgebung monitore kann ich Änderungen entsprechend frühzeitig erkennen und schon vor dem wirklichen Problem reagieren. Das kann man automatisieren - aber man muss halt auch mal in die Logs reinschauen. Ich soll also nicht EINMAL ALLES monitoren sondern REGELMÄSSIG die für mich wichtigen KENNDATEN.

Sofort wird jetzt sicher die Frage kommen: „Was sind denn die Trigger bei denen ich einschreiten muss?" Nun, solche Trigger sind mit Vorsicht zu genießen und wir sehen solche fixen Angaben mit sehr gemischten Gefühlen. Die Trigger für einen 8-fach QUAD XEON mit 64GB für 1.000.000 User und Gruppen sind sicher anders als für den Single DC im Kleinbetrieb mit 50 Usern. Also - man muss sich seine Performance Daten selber erarbeiten und zwar in seiner eigenen Umgebung, damit man eine Baseline hat mit der man in kritischen Situation vergleichen kann.

Gehen wir davon aus, „Houston - wir haben ein Problem" :-). LSASS nimmt 100% CPU und die Anwender haben Logon Probleme. Was verursacht nun die Last für LSASS? Da gibt es drei Möglichkeiten das heraus zu finden.

 

1.) Der Server Performance Advisor

Er ist für Windows 2003 entwickelt worden (unter Windows 2000 war ADPERF das entsprechende Tool) und liefert extrem hilfreiche Informationen. Von welchem Typ ist die Last auf dem DC (z.B. NTLM, LDAP, Kerberos usw.), welche Clients erzeugen die höchste Last usw usw. Der SPA wird auf einem DC installiert und dort während der kritischen Last einfach per F9 gestartet. Er sammelt nun 5 min alle notwendigen Daten und kompiliert diese dann in eine XML Datei. Das Standard Installationsverzeichnis ist C:\Perflog, dort im Ordner Report findet man dann die XML Datei - wenn man Glück hatte. Leider ist auch das nicht so ganz perfekt. Der SPA war als ein internes Hilfsmittel entwickelt worden und braucht um seine ganze Funktionalität nutzen zu können ein US-Englisches Betriebssystem mit US-Englischen Regional Settings. Im Zweifelsfall den C:\Perflogs Ordner einfach komplett zu uns einschicken und wir untersuchen das dann genauer.

2.) Ein Netzwerktrace

Auch ein Netzwerktrace kann hilfreich sein, jedoch nur wenn die Last von außen verursacht wird. Der einfachste Schnellcheck ist: Netzwerkkabel ziehen, bleibt die Last hoch? Dann ist die Last intern erzeugt. Geht die Last runter? Dann wird sie von außen erzeugt und ein Netzwerktrace kann evtl. helfen. Leider wird der Netzwerktrace sicher entsprechend groß, und einen Netzwerktrace mit 20 oder 100MB -oder gar mehr- zu untersuchen macht wenig Spaß. Glücklicherweise haben wir ein Script dass den Trace untersucht und einen Report dazu erzeugt. Auch das dauert eine Zeit, doch aus diesem Report lässt sich zumindest mehr erkennen als man selber im Riesentrace übersieht. Wenn hier nun die Topscorer der Last gefunden wurden, dann muss man sich diese Maschinen anschauen und überprüfen, welche Prozesse laufen dort die diese Last erzeugen usw..

3.) Ein Userdump von LSASS

Immer wieder gerne genommen - und bringt so gut wie gar nichts. Ein Userdump in einer Hängesituation ist prima, ein Userdump in einer Überlastsituation ist meistens wertlos. Man erhält hier eine Momentaufnahme, und dann kann man nur noch raten welcher Thread denn etwas seltsames macht. Mein größter LSASS Dump hatte weit über 600 Threads - also auch nicht unbedingt eine Kleinigkeit hier etwas zu finden. Und wenn, dann hilft ein Userdump sowieso nicht, dann muss man man mehrere Userdumps in kurzen Zeitabständen haben, so alle 2-10 minuten. Um die Dumps zu erzeugen braucht man ADPLus (in den Windows Debug Tools dabei, siehe KB286350, How to use ADPlus to troubleshoot "hangs" and "crashes" https://support.microsoft.com/default.aspx?scid=kb;EN-US;286350 ) oder Userdump.exe (User Mode Process Dumper Version 8.1, auf https://download.microsoft.com/ nach USERDUMP suchen)

 

Hier nun der Versuch eines Kochrezeptes um LSASS Last Situationen einzugrenzen:

  • 1.) Habe ich ein Problem?
    - Ist LSASS andauernd oder extrem lange auf 100% CPU?
    - Erhalte ich Fehlermeldungen?
    - Geht etwas nicht (Event.log, Anwender Beschwerden)
    Wenn das nicht zutrifft - dann lieber die Zeit dem Backup und Restore Konzept widmen, oder Urlaubsfotos ausdrucken o.ä. ;-)
  • 2.) Wenn ich also klar ein Problem habe:
    - Ist der DC auf dem aktuellen Stand (Service Pack, Kritische Hotfixes)
    - sind alle DCs betroffen oder nur einer?
    - Tritt die hohe Last noch auf wenn ich das Netzkabel abziehe?
  • 3.) Auf dem DC den SPA installieren (hoffentlich geht das noch)
    - den SPA starten
    - im linken Rahmen unter „Data Collectors and Reports" mit der rechten Maustaste auf „Active Directory" clicken, Properties, und hier unter Schedule die gewünschten Intervalle eintragen, z.B. alle 20 oder 30 min (Dauert sind 300 sec., dies bitte nicht ändern)
    - wenn man dann unter C:\Perflogs die richtigen XML Dateien findet, nachschauen ob man etwas erkennen kann - oder bei uns eine Anfrage eröffnen und den C:\Perflogs Ordner einschicken
  • 4.) Wenn der SPA nicht weiterhilft und das Problem -nach Test- von außen kommt, also bei gezogenem Netzwerkkabel weg ist, dann einen Netzwerktrace dieses DCs machen, ungefiltert, alle Pakete in/out. Puffergröße für den Trace ruhig auf 20 bis 100 MB hochsetzen
    - bei uns eine Anfrage eröffnen und den Trace einschicken
  • 5.) Wenn weder SPA noch Trace etwas bringen (und ich bin mir wirklich sicher ich habe ein Problem) - dann bleibt nur noch der Userdump von LSASS. Das geht z.B. mit:
    - ADPlus
    - Userdump.exe
    - damit in 2-10min Abständen 3-5 Userdumps von LSASS erzeugen
    - bei uns eine Anfrage eröffnen und die Dumps zur Auswertung zur Verfügung stellen

In 90% der Fälle ist der SPA die beste Wahl. Auch ist der Report sehr übersichtlich und kann häufig auch von erfahrenen Administratoren interpretiert werden. Userdumps sind häufig die wirklich allerletzte Rettung und da muss man schon Glück haben das richtige zu finden.

Nun, ich hoffe, das hat etwas Licht ins Dunkel gebracht und das Schreckgespenst von „LSASS leakt" mal geklärt. LSASS macht seinen Job und leidet dabei dann häufig unter unerwartet hoher Last die von außen angetragen wird. Daher ist die Ermittlung einer Grundlast so wichtig. Nur wenn ich mal mit dem SPA Reports zu typischen Hochlastzeiten (morgendlicher Logon) und auch zu Ruhezeiten erstellt habe, weiß ich wie die DCs ausgelastet sind und woraus meine Last besteht. Und damit habe ich eine Grundlage Abweichungen eher zu erkennen und besser eingrenzen zu können. Und dabei wünsche ich Viel Erfolg :-)

Tschau, Hans-Jürgen

Comments

  • Anonymous
    January 01, 2003
    Du schreibst:

Mit Performance Monitoring ist es so wie mit Hubraum: Hubraum ist durch nichts zu ersetzen als durch mehr Hubraum. Genauso ist es mit Performance Monitoring.

-> Hier möchte ich widersprechen. Man kann Hubraum sehr wohl ersetzen, nämlich durch Turbolader und Ladeluftkühler. Wenn das gut gemacht ist, vermisst man den 5,3l-V8 Motor überhaupt nicht. dedsHerbert

  • Anonymous
    January 01, 2003
    Kontra! Ja, mit Turbolader oder Kompressor kann man mehr Drehmoment und mehr Leistung schaffen. Aber ein Turbomotor mit sagen wir mal (ganz willkürlich...) 1,8 Liter Hubraum kommt trotz Zwangsbeatmung niemals an die Charakteristik von ehrlichem "Hubraum-Drehmoment" ran. Hier zu bewundern: http://de.youtube.com/watch?v=3_OLjJPYkXY (Teil 1: http://de.youtube.com/watch?v=-VC_T-u7Y4U) ;) Olaf

  • Anonymous
    January 01, 2003
    ACK. ;-) Ok, der Vergleich hinkt ein wenig, aber einen guten Beweis für "viel hilft viel" findet man auch hier: http://www.youtube.com/watch?v=Nqi2qNovnhY . Ab Minute 7 des Berichts wird es deutlich. Viele Grüße
    Fabian

  • Anonymous
    November 16, 2008
    The comment has been removed