Utilisation du processeur «maximale» sur les contrôleurs de domaine

Nous avons deux contrôleurs de domaine Windows Server 2008 SP2 (malheureusement pas 2008 R2) dans un petit domaine de 150 clients qui présentent une utilisation du processeur très "pointue". Les contrôleurs de domaine présentent tous les deux le même comportement et sont hébergés sur vSphere 5.5.0, 1331820. Toutes les deux ou trois secondes, l'utilisation du processeur passe à 80-100%, puis diminue rapidement, reste faible pendant une seconde ou deux, puis saute encore.

L'examen des données de performances historiques de la machine virtuelle indique que cette condition dure depuis au moins un an mais que la fréquence a augmenté depuis mars.

Le processus incriminé est SVChost.exe qui encapsule les services DHCP Client (dhcpcsvc.dll), EventLog (wevtsvc.dll) et LMHOSTS (lmhsvc.dll). Je ne suis certainement pas un expert des composants internes de Windows, mais je ne pouvais pas sembler trouver quoi que ce soit de particulier lors de la visualisation du processus avec Process Explorer, sauf qu'il semble que EventLog déclenche une tonne d' appels RpcBindingUnbind .

À ce stade, je suis à court de café et d'idées. Comment dois-je continuer à résoudre ce problème?

TL; DR: le fichier EventLog était plein. L'écrasement des entrées est coûteux et / ou n'est pas très bien implémenté dans Windows Server 2008.

Chez @pk. et @joeqwerty suggestion et après avoir demandé autour, j'ai décidé qu'il semblait très probable qu'une implémentation de surveillance oubliée grattait les journaux des événements.

J'ai installé le Moniteur réseau de Microsoft sur l'un des contrôleurs de domaine et j'ai commencé à filtrer MSRPC à l'aide du ProtocolName == MSRPCfiltre. Il y avait beaucoup de trafic, mais tout se passait entre le RODC de notre site distant et, malheureusement, n'utilisait pas le même port de destination que le processus EventLog d'écoute. Zut! Voilà la théorie.

Pour simplifier les choses et faciliter l'exécution du logiciel 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 dédient un processus SVCHost au service EventLog. Cela rend l'enquête un peu plus facile car vous n'avez pas plusieurs services attachés à ce PID.

SC config EventLog Type= own

J'ai ensuite recours à ProcMon et mis en place un filtre pour exclure tout ce qui n'a pas utilisé ce PID. Je n'ai pas vu des tonnes de tentatives infructueuses d'EventLog pour ouvrir les clés de registre manquantes comme indiqué comme cause possible ici (les applications apparemment merdiques peuvent s'enregistrer en tant que sources d'événements de manière extrêmement médiocre). On pouvait s'y attendre, j'ai vu beaucoup d'entrées ReadFile réussies du journal des événements de sécurité (C: \ Windows \ System32 \ WinEvt \ Logs \ Security.evtx).

Voici un aperçu de la pile de l'un de ces événements:

Vous remarquerez d'abord le RPCBinding puis le RPCBindingUnbind. Il y en avait beaucoup . Comme des milliers par seconde. Soit le journal de sécurité est vraiment occupé, soit quelque chose ne fonctionne pas correctement avec le Security.evtxjournal.

Dans EventViewer, le journal de sécurité enregistrait uniquement entre 50 et 100 événements par minute, ce qui semblait approprié pour un domaine de cette taille. Zut! Il y a la théorie numéro deux selon laquelle nous avons eu une application avec un audit d'événement très verbeux tourné à gauche dans un coin oublié, toujours en train de s'éloigner consciencieusement. Il y avait encore beaucoup (~ 250 000) d'événements enregistrés même si le taux d'événements enregistrés était faible. Taille du journal peut-être?

Journaux de sécurité - (clic droit) - Propriétés ... et la taille maximale du journal a été définie pour 131 072 Ko et la taille du journal était actuellement de 131 072 Ko. Le bouton radio «Remplacer les événements selon les besoins» a été coché. J'ai pensé que supprimer et écrire constamment dans le fichier journal était probablement un travail difficile, surtout quand il était si plein, j'ai donc opté pour Effacer le journal (j'ai sauvegardé l'ancien journal au cas où nous en aurions besoin pour un audit plus tard) et laisser le service EventLog créer un nouveau fichier vide. Le résultat: l'utilisation du CPU est revenue à un niveau sain autour de 5%.

Vous pourrez peut-être poursuivre cela en créant un petit ensemble de collecteurs de données.

• Ouvrez l'Analyseur de performances et créez un nouvel ensemble de collecteurs de données défini par l'utilisateur.
• Choisissez Manuel (pas de modèle) et sélectionnez uniquement les données de trace d'événement .
• Ajoutez le service de domaine Active Directory: données de base et enregistrez l'ensemble.
• Modifiez la condition d'arrêt sous Propriétés à 1 minute.
• Démarrez l'ensemble et attendez.
• Une fois terminé, convertissez le fichier .etl enregistré en .csv en utilisanttracerpt –l “file.etl” –of CSV
• Analysez les données summary.csv et dumpfile.csv dans Excel. Vous pouvez télécharger ce document Import-DC-Info.xlsm pour vous aider dans votre analyse.

Si mon intuition est correcte, vous allez voir certains appareils (IP: port) marteler votre DC.

Certainement difficile. En plus de le laisser seul (1 CPU / 50% de charge .. peu importe?), 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 c'est le cas, vous voudrez peut-être essayer avec une trace Wireshark (évidemment, il y a quelque chose du réseau qui provoque cela)

La prochaine chose qui me vient à l'esprit est un simple appel à Microsoft

Travis, "archiver" ne vous a pas aidé. En fait, même effacer le journal des événements lorsqu'il était au 2/3 n'a pas aidé. Mais "archive" a aidé KraigM.

kce: effacé un fichier "écraser" de 131 Mo et vu les performances chuter de disons 55% o 5% mais QUESTION: peut-être avez-vous finalement vu une nouvelle utilisation élevée car cela ne peut (a) être déclenché que lorsque la condition d'écrasement est atteinte ou (b) il peut s'aggraver linéairement à mesure que le fichier effacé passe de 0 Mo à 131 Mo.

Certains le voient pour le security.evtx et on l'a vu pour le journal opérationnel du Planificateur de tâches. Je suggère de désinstaller complètement votre AV (lequel utilisez-vous) et d'essayer. Les intrus doivent masquer leurs traces et leurs traces sont effectuées dans les tâches planifiées qu'ils configurent ou les connexions qu'ils effectuent. Ils cacheront donc leurs traces en cassant les poignées de ces journaux d'événements et en les réécrivant pour ignorer leurs traces. Les AV peuvent être en train de détecter cela dans un buggy, car s'il s'agissait de Microsoft, une plus grande partie de cette utilisation élevée aurait été signalée, mais je ne vois que peu de messages lors de la recherche sur Google. Je vois également cela sur le serveur 2008 R2 pour le journal security.evtx. Aucun abonné au journal des événements, aucun moniteur externe. J'ai observé quelques services AV (McAfee) en cours d'exécution et leur utilisation totale pour un serveur était très faible pendant tant de jours, donc je soupçonne qu'il a été désinstallé et seulement partiellement (il a probablement besoin du programme de désinstallation spécial de McAfee) et je me demande s'il y a des crochets dans le vestige (ou même normalement installé) du service McAfee ou des pilotes de filtre McAfee en cours d'exécution qui prennent en quelque sorte une écriture normale dans le journal des événements et décident dans leur filtrage qu'ils doivent en faire une lecture complète de tout le journal des événements. Croyez-moi, les pilotes de filtre tiers de certaines sociétés audiovisuelles sont bogués et certainement 10000x plus bogues que la mise en œuvre par Microsoft de la journalisation des événements, ce qui est très probablement parfait. En résumé, désinstaller à 100% TOUS VOS AV ET VOIR SI le problème se résout. Si tel est le cas, collaborez avec votre entreprise audiovisuelle pour réparer leur AV. Il est déconseillé de faire des exceptions de fichiers pour.

De plus, lorsque vous utilisez procmon, faites attention aux appels WriteFile car c'est le fichier Writefile qui déclenchera le gestionnaire de filtres pour lire l'intégralité du fichier. Dans mon cas, la lecture a été lancée environ 30 secondes après la fin de l'écriture, ce qui pourrait être voulu par la conception même du produit. Mais il était cohérent et dans mon cas, le fichier était de 4 Go et le fichier lu impliquait 64 000 fichiers de lecture de 64 Ko chacun et il utilisait 35% du processeur pour y parvenir. Très triste.

Mise à jour 23/03/2016 J'ai regardé les pilotes de filtre sur cette machine après avoir conclu que cela devait être causé par l'un d'eux (le mécanisme du journal des événements ne pourrait jamais être bogué seul ou le nombre de rapports de ce type serait stupéfiant et ce n'est pas). J'ai vu des pilotes de filtre d'un AV et d'une société tierce bien connue qui améliore les performances du disque de la machine virtuelle avec des lectures à venir et j'ai demandé à leur architecte en chef (qui était très gentil et courtois) si son produit pouvait lire de manière trop agressive l'ensemble journal des événements de sécurité (ce qui se passait clairement par procmon). Cela serait utile pour les journaux de sécurité plus petits, mais pas ceux des tailles indiquées ici. Pas du tout ce qu'il a dit. Il a convenu que ce pourrait être l'AV.

Comme je l'ai dit au boursier Azure ci-dessous, nous n'avons pas de suivi de l'affiche originale si le problème est réapparu après avoir effacé le journal des événements, car il s'agit d'une solution courante et erronée car les performances se dégradent à nouveau avec le temps. C'est ce qu'on appelle le "suivi" et je vois de visu que la solution de l'affiche originale peut tromper ceux qui ne font pas de suivi en leur faisant croire qu'ils ont résolu le problème. J'ai aussi failli être dupe. J'ai effacé le journal des événements et les performances ont été améliorées - mais j'ai utilisé procmon et j'ai vu le problème se développer et se développer lentement au fil du temps jusqu'à ce qu'il devienne problématique. Pour une raison quelconque, le boursier Azure me critique sévèrement lorsque l'affiche originale n'a pas suivi (peut-être est-elle décédée, a-t-elle été licenciée, a-t-elle quitté ou s'est-elle occupée)? Le boursier Azure ci-dessous pense que si l'affiche originale n'a pas suivi, cela doit être un problème fixe. C'est vexant et déroutant parce que je ne peux penser à personne qui est si hautement considéré techniquement qui prendrait cette position. Je m'excuse si j'ai piqué un nerf. Peut-être que dans mon activisme ailleurs sur Internet où j'appelle des gens, je suis devenu nerveux - ici (erreur de serveur), je suis simplement gentil et partage des connaissances techniques approfondies et le résultat de M. Azure est de savoir si ma contribution technique est égale nécessaire ou est pour un de mes blogs (je n'ai pas un tel blog). Je n'ai pas encore l'intention d'envoyer ce lien à une demi-douzaine de copains clés de Microsoft et de leur demander ce qu'il se passe avec ce type d'intimidation de la part d'un employé clé de MSFT parce que je suis particulièrement concentré sur le meilleur intérêt de la communauté à l'esprit et les réponses ci-dessous de M. Azure sont, en quelques mots, incroyables, vitrioliques, énervant et intimidant - ce que je suis sûr que certaines personnes aiment faire aux autres. J'ai d'abord été offensé, mais je m'en remets et je sais que les lecteurs passifs ou actifs apprécieront ce que je dis et apprécieront mes commentaires - je suis à 100% derrière sans égard pour les raisons juridiques qui font qu'il est subtilement inapproprié ici ou non. M. Azure, s'il vous plaît, faites preuve de gentillesse et évitez de jeter mes commentaires sous un mauvais jour. Il suffit de s'en remettre et de faire preuve de retenue et de ne pas encore commenter. s'il vous plaît, faites preuve de gentillesse et évitez de formuler mes commentaires sous un mauvais jour. Il suffit de s'en remettre et de faire preuve de retenue et de ne pas commenter encore une fois. s'il vous plaît, faites preuve de gentillesse et évitez de formuler mes commentaires sous un mauvais jour. Il suffit de s'en remettre et de faire preuve de retenue et de ne pas commenter encore une fois.

Harry