Utilisation de la CPU "Peaky" sur les contrôleurs de domaine
Nous avons deux contrôleurs de domaine Windows Server 2008 SP2 (Malheureusement et non 2008 R2) dans un petit domaine client qui présentent une utilisation très "Peaky" de la CPU. Les contrôleurs de domaine présentent tous deux le même comportement et sont hébergés sur VSphere 5.5.0, 1331820. Toutes deux ou trois secondes, l'utilisation de la CPU saute jusqu'à 80-100%, puis goutte rapidement, reste faible pour une seconde ou deux, puis saute de nouveau.
En regardant les données de performance historiques de la machine virtuelle indique que cette condition est passée pendant au moins une année, mais la fréquence a augmenté depuis mars.
Le processus incriminé est Svchost.exe qui enveloppe le client DHCP (DHCPCSVC.DLL), EventLog (WEVTSVC.DLL) et LMHOSTS (LMHSVC.DLL) Services. Je ne suis certainement pas un expert de Windows Internals, mais je ne pouvais pas sembler avoir rien de trouver particulièrement mal lors de la visualisation du processus avec l'explorateur de processus autre que celui de l'événement déclenchant une tonne de RPCBindingunbind Appels.
[.____] À ce stade, je suis hors du café et des idées. Comment devrais-je continuer à résoudre ce problème?
TL; DR: Le fichier EventLog était plein. Les entrées écrasantes sont coûteuses et/ou non implémentées très bien dans Windows Server 2008.
AT @ pk. et @ joeqwerty Suggestion et après la question, j'ai décidé qu'il semblait très probablement qu'une mise en œuvre de surveillance oubliée ait gratté les journaux des événements.
J'ai installé Moniteur de réseau de Microsoft sur l'un des contrôleurs de domaine et a démarré le filtrage pour MSRPC en utilisant le ProtocolName == MSRPC filtre. Il y avait beaucoup de trafic mais tout entre notre site de notre site distant et n'a malheureusement pas utilisé le même port de destination en tant que processus d'écoute EventLog. Zut! Il y a cette théorie.
Pour simplifier les choses et faciliter l'exécution de logiciels de surveillance, j'ai décidé de déballer le service EventLog de Svchost. La commande suivante et un redémarrage du contrôleur de domaine consacrent un processus Svchost au service EventLog. Cela rend une enquête un peu plus facile puisque vous n'avez pas de services multiples attachés à ce PID.
SC config EventLog Type= own
J'ai ensuite eu recours à Procmon et configurez un filtre pour exclure tout ce qui n'a pas utilisé ce PID. Je n'ai pas vu de tonnes de tentatives infructueuses par EventLog pour ouvrir les clés de registre manquantes comme indiqué comme une cause possible ici (Applications apparemment de merde peut s'inscrire en tant que sources d'événement de manière extrêmement médiocre ). De manière prévisible, j'ai vu beaucoup d'entrées réalisées réussies du journal des événements de sécurité (C:\Windows\System32\Winevt\Logs\Security.evtx).
Voici un coup d'œil à la pile sur l'un de ces événements: 
Vous remarquerez d'abord le RPCBinding, puis rpcbindingunbind. Il y avait un Lot de ceux-ci. Comme des milliers par seconde. Soit le journal de sécurité est vraiment occupé ou quelque chose ne fonctionne pas correctement avec le Security.evtx Journal.
Dans EventViewer, le journal de sécurité n'enregistrait que 50-100 événements par minute qui semblait approprié pour un domaine de cette taille. Zut! Il y a la théorie numéro deux que nous avons eu une application avec l'audit d'événements très verbos allumé à gauche dans un coin oublié toujours réveillé. Il y avait encore beaucoup (environ 250 000) d'événements enregistrés, même si le taux d'événements enregistré était faible. La taille du journal peut-être?
Journaux de sécurité - (clic droit) - Propriétés ... et la taille du journal maximum a été définie pour 131 072 kb et la taille du journal utilisait actuellement 131 072 Ko. Le bouton radio 'écrasé selon le besoin' a été vérifié. J'ai constamment affiché que la suppression constante et la rédaction du fichier journal était probablement un travail acharné, surtout quand il était si plein, alors j'ai choisi d'effacer le journal (j'ai enregistré l'ancien journal au cas où nous en aurions besoin pour l'audit ultérieur) et laisser le service EventLog un nouveau fichier vide. Le résultat: l'utilisation du processeur est revenue à un niveau sain d'esprit d'environ 5%.
Vous pourrez peut-être chasser cela en créant un petit collecteur de données.
- Ouvrez le moniteur de performances et créez un nouveau collecteur de données défini par l'utilisateur.
- Choisissez Manuel (aucun modèle) et sélectionnez Données de trace d'événement seulement.
- Ajouter le service de domaine Active Directory : CORE Données et enregistrez l'ensemble.
- Changer le Etat de l'arrêt Sous Propriétés à 1 minute.
- Commencez l'ensemble et attendez.
- Une fois terminé, convertissez le fichier enregistré . ETL Fichier sur A . CSV Utilisation
tracerpt –l “file.etl” –of CSV - Analysez le sommaire.csv et Dumpfile.csv Données dans Excel. Vous voudrez peut-être télécharger ceci importer-dc-info.xlsm doc pour vous aider avec votre analyse.
Si mon hunch est correct, vous allez voir certains périphériques (IP: Port) marteler votre DC.
Certainement un difficile. En dehors de simplement le laisser seul (1 CPU/50% de charge. Qui s'en soucie?), Vous pouvez essayer de configurer un nouveau contrôleur de domaine et voir après quelques jours si celui-ci vous donne le même comportement. Si tel est le cas, vous voudrez peut-être essayer avec une trace de WireShark (évidemment, il y a quelque chose du réseau, ce qui l'entraîne alors)
La chose suivante qui vient à l'esprit est un appel simple à Microsoft