Utilizzo "picco" della CPU sui controller di dominio


25

Abbiamo due controller di dominio Windows Server 2008 SP2 (purtroppo non 2008 R2) in un piccolo dominio di 150 client che mostrano un utilizzo della CPU molto "elevato". I controller di dominio mostrano entrambi lo stesso comportamento e sono ospitati su vSphere 5.5.0, 1331820. Ogni due o tre secondi l'utilizzo della CPU salta fino all'80-100% e quindi diminuisce rapidamente, rimane basso per un secondo o due e quindi salta su ancora.

Prestazioni del Task Manager DC3


L'esame dei dati storici sulle prestazioni della macchina virtuale indica che questa condizione è in atto da almeno un anno, ma la frequenza è aumentata da marzo.

Prestazioni della macchina virtuale DC3



Il processo offensivo è SVChost.exe che esegue il wrapping dei servizi Client DHCP (dhcpcsvc.dll), EventLog (wevtsvc.dll) e LMHOSTS (lmhsvc.dll). Non sono certamente un esperto di Windows ma non riesco a trovare nulla di particolarmente sbagliato durante la visualizzazione del processo con Process Explorer diverso da quello che sembra che EventLog stia innescando un sacco di chiamate RpcBindingUnbind .

DC3 Process Explorer per SVCHost.exe



A questo punto sono senza caffè e idee. Come devo continuare a risolvere questo problema?


Spitballing qui: 1. Hai un sistema di monitoraggio che interroga i log degli eventi sui controller di dominio? 2. Hai qualche tipo di controllo abilitato che può portare a pesanti attività del registro eventi sui controller di dominio?
joeqwerty,

1
Volevo entrare in contatto con questo thread spuntato su una ricerca di Google per il registro eventi CPU elevata. Questo problema è ancora presente sul Server 2012. Ho risolto esattamente lo stesso problema su un Server 2012 DC. Controlla le dimensioni del file di registro. Il percorso di registro predefinito è% SystemRoot% \ System32 \ Winevt \ Logs \ L'opzione radio Sovrascrivi ha problemi a gestire file di registro di dimensioni maggiori. Ho impostato il mio per archiviare il registro quando è pieno e rollover.
KraigM,

Per coloro che arrivano qui da Google, questo problema del servizio Registro eventi si applica anche ai computer Windows Server non controller. Nel mio caso, anche avere abbastanza utenti con mmc.exe(probabilmente la finestra "Server manager" predefinita?) Aperta ha raggiunto picchi regolari.
Nickolay,

Risposte:


25

TL; DR: il file EventLog era pieno. La sovrascrittura delle voci è costosa e / o non implementata molto bene in Windows Server 2008.


A @pk. e il suggerimento di @joeqwerty e dopo averlo chiesto in giro, ho deciso che sembrava molto probabile che un'implementazione di monitoraggio dimenticata stesse raschiando i registri degli eventi.

Ho installato il Network Monitor di Microsoft su uno dei controller di dominio e ho iniziato a filtrare MSRPC usando il ProtocolName == MSRPCfiltro. C'era molto traffico ma era tutto tra il RODC del nostro sito remoto e sfortunatamente non utilizzava la stessa porta di destinazione del processo di ascolto EventLog. Darn! Ecco quella teoria.

Per semplificare le cose e semplificare l'esecuzione del software di monitoraggio, ho deciso di scartare il servizio EventLog da SVCHost. Il comando seguente e il riavvio del controller di dominio dedicano un processo SVCHost al servizio EventLog. Questo rende le indagini un po 'più semplici poiché non hai più servizi collegati a quel PID.

SC config EventLog Type= own

Ho quindi fatto ricorso a ProcMon e impostato un filtro per escludere tutto ciò che non utilizzava quel PID. Non ho visto tonnellate di tentativi falliti da parte di EventLog di aprire le chiavi del Registro di sistema mancanti come indicato come possibile causa qui (le applicazioni apparentemente scadenti possono registrarsi come fonti di eventi in modi estremamente poveri). Com'era prevedibile, ho visto molte voci ReadFile riuscite nel registro degli eventi di sicurezza (C: \ Windows \ System32 \ WinEvt \ Logs \ Security.evtx).

ReadFile Security.evtx

Ecco uno sguardo allo Stack su uno di quegli eventi: RpcBindingUnbind

Noterai prima RPCBinding e poi RPCBindingUnbind. Ce n'erano molti . Come migliaia al secondo. Il registro di sicurezza è davvero occupato o qualcosa non funziona correttamente con il Security.evtxregistro.

In EventViewer il registro di sicurezza registrava solo tra 50 e 100 eventi al minuto, il che sembrava appropriato per un dominio di queste dimensioni. Darn! Secondo la teoria numero due, abbiamo avuto qualche applicazione con un auditing di eventi molto dettagliato girato a sinistra in un angolo dimenticato e ancora diligentemente nascosto. Sono stati registrati ancora molti (~ 250.000) eventi anche se la frequenza degli eventi registrati era bassa. Dimensione del registro forse?

Registri di sicurezza - (clic destro) - Proprietà ... e la dimensione massima del registro è stata impostata per 131.072 KB e la dimensione del registro era attualmente di 131.072 KB. Il pulsante di opzione "Sovrascrivi eventi secondo necessità" è stato verificato. Ho pensato che eliminare e scrivere costantemente nel file di registro fosse probabilmente un duro lavoro soprattutto quando era così pieno, quindi ho optato per Cancella il registro (ho salvato il vecchio registro nel caso in cui ne avessimo bisogno per il controllo in seguito) e lasciare che il servizio EventLog creasse un nuovo file vuoto. Il risultato: l'utilizzo della CPU è tornato a un livello normale intorno al 5%.


Bel lavoro. Inoltre, sposta TL; DR in cima alla risposta?
Zlatko,

Cordiali saluti ... questo ha appena colpito un sacco di nostri controller di dominio, molti dei quali sono 2012/2012 R2. Quindi sembra non essere altrettanto ben implementato nelle versioni più recenti di Windows Server.
HopelessN00b

Quindi questo è il mio problema, MA ho impostato l'archiviazione quando è pieno e non scrivo troppo. La dimensione massima del registro è 1 GB e la dimensione corrente è 639 MB. Sconcertato su cosa fare se non cancellare il registro come test. Questo è su R2 R2 standard e sta interessando il PDC e il controller di dominio secondario. Entrambi sono VM. Ho dovuto allocare 2 socket / 1 core per ogni DC o entrambi avrebbero espulso 1/1 allocazioni e non avrebbero più risposto. L'aggiunta di più RAM non ha fatto nulla. A questo punto utilizza costantemente tra il 60-100% di CPU.
Travis,

Salvato / cancellato il registro di sicurezza. Esegue ancora il 74% di utilizzo della CPU.
Travis,

5

Potresti essere in grado di inseguire questo creando un piccolo set di raccolta dati.

  • Aprire Performance Monitor e creare un nuovo set di raccolta dati definito dall'utente.
  • Scegli Manuale (nessun modello) e seleziona Solo dati traccia evento .
  • Aggiungi il servizio di dominio Active Directory: dati di base e salva il set.
  • Modificare la condizione di arresto in Proprietà su 1 minuto.
  • Avvia il set e attendi.
  • Al termine, convertire il file .etl salvato in un .csv utilizzandotracerpt –l “file.etl” –of CSV
  • Analizza i dati summary.csv e dumpfile.csv in Excel. Puoi scaricare questo documento Import-DC-Info.xlsm per aiutarti con la tua analisi.

Se il mio sospetto è corretto, vedrai alcuni dispositivi (IP: porta) martellare il tuo DC.


1

Certamente difficile. Oltre a lasciarlo solo (1 CPU / 50% di carico .. chi se ne frega?), Potresti provare a configurare un nuovo controller di dominio e vedere dopo alcuni giorni se questo ti dà lo stesso comportamento. In tal caso, potresti provare con una traccia di Wireshark (ovviamente, c'è qualcosa dalla rete che causa questo allora)

La prossima cosa che viene in mente è una semplice chiamata a Microsoft


-2

Travis, "archivio" non ti ha aiutato. In effetti, anche cancellare il registro eventi quando era cresciuto di 2/3 non ti ha aiutato. Ma "archivio" ha aiutato KraigM.

kce: ha cancellato un file "overwrite" da 131 MB e ha visto un calo delle prestazioni da dire 55% o 5% ma DOMANDA: forse alla fine hai visto di nuovo un elevato utilizzo poiché questo potrebbe (a) essere attivato solo quando viene raggiunta la condizione di sovrascrittura o (b) potrebbe peggiorare linearmente quando il file eliminato aumenta da 0 MB a 131 MB.

Alcuni lo vedono per security.evtx e uno lo vede per il registro operativo di Utilità di pianificazione. Suggerisco di disinstallare completamente il tuo AV (quale stai usando) e di provare. Gli intrusi devono nascondere le loro tracce e le loro tracce vengono create nelle attività pianificate che configurano o negli accessi che eseguono. Quindi nasconderanno le loro tracce rompendo le maniglie di questi registri eventi e riscrivendole per saltare le loro tracce. Gli AV potrebbero rilevare questo problema in modo errato poiché se fosse Microsoft, sarebbe stato segnalato un maggior utilizzo di questo elevato utilizzo ma sto vedendo solo pochi post quando googling. Lo vedo anche sul server 2008 R2 per il registro security.evtx. Nessun abbonato al registro eventi, nessun monitor esterno. Ho osservato un paio di servizi AV (McAfee) in esecuzione e avevano un utilizzo totale molto basso per un server per così tanti giorni, quindi sospetto che sia stato disinstallato e solo parzialmente (probabilmente ha bisogno del programma di disinstallazione speciale di McAfee) e mi chiedo se ci sono hook in il vestigio (o anche normalmente installato) il servizio McAfee o i driver di filtro McAfee in esecuzione che in qualche modo prendono una normale scrittura nel registro eventi e decidono nel loro filtro che devono trasformarlo in una lettura completa di tutto il registro eventi. Fidati di me, i driver di filtro di terze parti di alcune aziende AV sono difettosi e sicuramente più potenti di 10000 volte rispetto all'implementazione da parte di Microsoft della registrazione degli eventi, che è molto probabilmente perfetta. In sintesi, disinstallare al 100% TUTTI I TUOI AV E VEDERE SE il problema si risolve. In tal caso, collabora con la tua azienda AV per riparare il loro AV. Si sconsiglia di fare eccezioni ai file per.

Inoltre, quando si utilizza procmon, prestare attenzione alle chiamate WriteFile perché Writefile è ciò che attiverà il gestore filtri per leggere l'intero file. Nel mio caso, la lettura è stata avviata circa 30 secondi dopo il completamento della scrittura, che potrebbe essere di progettazione. Ma era coerente e nel mio caso il file era di 4 GB e il file letto comportava 64 KB di file di lettura ciascuno di 64 KB di lunghezza e per raggiungere questo scopo ha utilizzato il 35% della CPU. Molto triste.


Aggiornamento 23/03/2016 Ho esaminato i driver di filtro su questa macchina dopo aver concluso che questo doveva essere causato da uno di essi (il meccanismo del registro eventi non poteva mai essere difettoso da solo o il numero di segnalazioni di questo tipo sarebbe sconcertante e non è). Ho visto alcuni driver di filtro da un AV e da una nota società di terze parti che aumenta le prestazioni del disco della macchina virtuale con letture future e ha chiesto al loro architetto capo (che era molto gentile e gentile) se il suo prodotto potrebbe leggere in modo eccessivamente aggressivo l'intero registro eventi di sicurezza (che stava chiaramente accadendo per procmon). Ciò sarebbe utile per i registri di sicurezza più piccoli ma non quelli delle dimensioni riportate qui. In nessun modo ha detto. Ha concordato che potrebbe essere l'AV.

Come ho detto al collega Azure di seguito, non abbiamo un seguito dal Poster originale se il problema riemerse dopo aver cancellato il registro eventi perché è una soluzione comune ed errata poiché le prestazioni peggiorano nel tempo ancora una volta. Questo si chiama "followup" e vedo in prima persona che la soluzione del poster originale può ingannare coloro che non seguono il credere di aver risolto il problema. Anche io sono quasi stato preso in giro. Ho cancellato il registro eventi e le prestazioni sono migliorate, ma ho usato Procmon e ho visto che il problema aumenterà e crescerà lentamente nel tempo fino a quando non diventa problematico. Per qualche ragione, il collega di Azure mi critica duramente quando il poster originale non ha dato seguito (potrebbe essere morto, licenziato, abbandonato o occupato). Il collega Azure in basso pensa che se il poster originale non ha dato seguito, deve essere un problema risolto. Questo è fastidioso e sconcertante perché non riesco a pensare a nessuno che sia tecnicamente molto considerato che prenderebbe questa posizione. Mi scuso se ho pizzicato un nervo. Forse nel mio attivismo altrove su Internet, dove chiamo le persone, mi sono preso il coraggio - qui (serverfault) sono semplicemente gentile e condividendo profonde conoscenze tecniche e il risultato di Azure è il bullismo sul fatto che il mio contributo tecnico sia pari necessario o è per alcuni dei miei blog (non ho tali blog). Non ho ancora intenzione di inviare questo link a circa una mezza dozzina di amici chiave di Microsoft e chiedere loro cosa sta succedendo con questo tipo di bullismo da un dipendente MSFT perché sono focalizzato singolarmente sull'interesse di la comunità in mente e le risposte sottostanti dal signor Azure sono, in poche parole, incredibili, al vetriolo, snervante e prepotente - che sono sicuro che ad alcune persone piace fare agli altri. Inizialmente ero offeso, ma ci sono passato e so che, i lettori passivi o attivi apprezzeranno ciò che sto dicendo e apprezzeranno i miei commenti - lo sostengo al 100% senza riguardo per motivi legalistici perché è sottilmente inappropriato qui o no. M. Azure, per favore pratica la gentilezza e astieniti dal trasmettere i miei commenti in cattiva luce. Superalo e mostra moderazione e non commentare ancora. per favore pratica la gentilezza e astieniti dal trasmettere i miei commenti in cattiva luce. Superalo e mostra moderazione e non commentare ancora. per favore pratica la gentilezza e astieniti dal trasmettere i miei commenti in cattiva luce. Superalo e mostra moderazione e non commentare ancora.

Harry


Sembra che tu stia affrontando le persone che hanno commentato, e non l'OP e la domanda originale. E stai suggerendo suggerimenti come la rimozione di AV. L'OP ha già risolto il problema e lo ha identificato come un problema del registro eventi. Non lo vedo come una risposta valida.
David Makogon,

Ciò non è stato risolto se hai letto attentamente i poster e il mio riassunto. Devi soffrire di questo problema per analizzare le loro parole con molta più attenzione rispetto a quello che hai fatto e vedere questo. Mi dispiace che tu non sia in grado di farlo e mi abbia giudicato così duramente. Ad esempio, l'OP ha dichiarato di essere tornato ad un 5% sano, ma avrebbe potuto facilmente tornare dopo aver cancellato il registro e non ha dato seguito - in effetti questo è successo a un altro commentatore. Pertanto nulla è stato risolto poiché non ha verificato che i risultati siano rimasti permanentemente al 5%.
Harry

Scusa Harry, questa non è una risposta; stai facendo affermazioni su software difettoso e stai dicendo all'OP di lavorare con la loro società antivirus. Questo è ottimo per il tuo blog personale o un articolo, ma un editoriale non è una risposta, a una domanda di due anni con una risposta accettata, con una causa radice non correlata all'antivirus.
David Makogon,

@harry sorprendentemente sono tornato di nuovo qui cercando di capirlo di nuovo :) Nessun AV sul sistema. Ho fatto alcuni aggiornamenti di Windows e ho cambiato il file di registro massimo per archiviarlo a 500 MB da 1 GB. Anche a 1 GB si è capovolto solo una volta in 8 mesi mentre l'altro mio DC si ribalta un po 'di più. Ho seguito il suggerimento "SC config EventLog Type = own" per dividere il file di registro. Dopo il riavvio, il processo evenlog è sceso al di sotto dell'1%. Anche i "dhcp e lmhosts" collegati al processo sono inferiori all'1% della CPU. Stavo registrando solo circa 15 eventi di sicurezza / secondo.
Travis,

Ho sospettato che un agente SSO che avevo in esecuzione avesse qualcosa a che fare con esso poiché aveva molti errori ma la disabilitazione del servizio non ha comportato un calo nell'uso della CPU anche dopo un riavvio. L'agente SSO esegue il backup e la CPU è ancora in esaurimento, quindi chi lo sa.
Travis,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.