Mi prendo cura di un server Windows nella mia azienda. AFAIK, il server è un membro di active directory. Ho notato dal task manager che il processo LSASS.exe richiede molta memoria e tempo di CPU. Tramite google, ho scoperto che potrebbe essere risolto con alcune patch aggiornate.
Solo curioso. Che cos'è LSASS.exe? Che cosa fa? E perché ci vuole un sacco di memoria e tempo CPU? Può essere ridotto se le patch non funzionano?
Risposte:
LSASS è il sottosistema dell'autorità di sicurezza locale. È in ultima analisi responsabile di prendere la decisione di accesso / accesso negato quando si tenta di accedere alle risorse in un sistema operativo derivato da Windows NT. Ogni volta che provi ad accedere a qualsiasi risorsa, un po 'di codice in fondo a LSASS in realtà dice "Sì, vai avanti" o "Woah! Assolutamente no!"
Sui computer controller di dominio ospita il database di Active Directory. Pertanto, su un computer controller di dominio, vedrai più risorse CPU, RAM e I / O utilizzate da questo processo perché è in esecuzione AD. Su un server membro che non è un controller di dominio non si dovrebbe vedere un impatto altrettanto grande.
Per quanto riguarda l'applicazione delle patch, prendi ciò che "Windows Update" o "Microsoft Update" dice di fare come "la cosa giusta". Per la maggior parte, questo ti porterà ai livelli attuali. Fai attenzione a perdere tempo con LSASS, perché ucciderlo causerà il riavvio del computer.
LSASS.exe è il processo Local Security Authentication Server. Fondamentalmente applica la politica di sicurezza. Se il processo richiede una quantità eccessiva di cicli della CPU, vorrei prima esaminare quali criteri di sicurezza sono in atto.
LSASS.exe è stato colpito da virus in passato, quindi ovviamente devi assicurarti che il tuo software antivirus sia in esecuzione e aggiornato.
Inoltre, è un file di sistema di base, quindi non tentare di ucciderlo. Come Wolverine, calciarlo nelle palle lo farà solo incazzare.
In bocca al lupo
-RaindogShane
Dopo aver dedicato molto tempo a questo problema con Lsass.exe su un server che non era un controller di dominio, ho riscontrato il problema.
C'era una differenza di tempo di circa 4 ore tra gli orologi sul controller di dominio e sul server problematico. L'impostazione degli orologi allo stesso tempo e il riavvio di entrambi i server (non sono sicuro se sia necessario riavviare entrambi) ha impedito al servizio di consumare tutta la memoria. Dopo il monitoraggio per alcuni giorni, il mio problema è stato risolto.
Ho pensato di pubblicarlo qui per le persone che hanno lo stesso problema con questo servizio e non su un controller di dominio.