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


25

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.

Performances du gestionnaire de tâches DC3


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.

Performances de la machine virtuelle DC3



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 .

DC3 Process Explorer pour SVCHost.exe



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


Juste spitballing ici: 1. Avez-vous un système de surveillance qui interroge les journaux d'événements sur les contrôleurs de domaine? 2. Avez-vous un type d'audit activé qui peut entraîner une activité intense du journal des événements sur les contrôleurs de domaine?
joeqwerty

1
Je voulais faire un carillon lorsque ce fil est apparu lors d'une recherche Google pour le journal des événements CPU élevé. Ce problème est toujours présent sur le serveur 2012. Juste résolu exactement le même problème sur un serveur 2012 DC. Vérifiez la taille des fichiers journaux. L'option par défaut du chemin du journal est% SystemRoot% \ System32 \ Winevt \ Logs \ Overwrite. J'ai défini le mien pour archiver le journal lorsqu'il est plein et survolé.
KraigM

Pour ceux qui viennent ici de Google, ce problème de service de journal des événements s'applique également aux machines Windows Server sans contrôleur. Dans mon cas, avoir suffisamment d'utilisateurs avec mmc.exe(probablement la fenêtre "Gestionnaire de serveur" par défaut?) Ouverte a également atteint des pointes régulières.
Nickolay

Réponses:


25

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).

ReadFile Security.evtx

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

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%.


Bon travail. De plus, déplacez le TL; DR en haut de la réponse?
Zlatko

Juste pour info ... cela vient de frapper un tas de nos contrôleurs de domaine, dont la plupart sont 2012/2012 R2. Il semble donc qu'il soit également mal implémenté dans les nouvelles versions de Windows Server.
HopelessN00b

C'est donc mon problème, MAIS j'ai réglé pour archiver lorsqu'il est plein et ne pas écraser. La taille maximale du journal est de 1 Go et la taille actuelle est de 639 Mo. Perplexe sur quoi faire à part peut-être effacer le journal comme test. C'est sur 2008 R2 Std et affecte le PDC et le DC secondaire. Les deux sont des VM. J'ai dû allouer 2 sockets / 1 core pour chaque DC ou ils allaient tous les deux extraire des allocations 1/1 et ne répondaient plus. Ajouter plus de RAM n'a rien fait. Il utilise constamment entre 60 et 100% de CPU à ce stade.
Travis

Enregistré / effacé le journal de sécurité. Toujours en cours d'utilisation 74% du processeur.
Travis

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.


1

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


-2

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


Il semble que vous vous adressiez aux personnes qui ont commenté, et non au PO et à la question d'origine. Et vous faites des suggestions comme supprimer AV. L'OP a déjà résolu leur problème et l'a identifié comme un problème de journal des événements. Je ne vois pas cela comme une réponse valable.
David Makogon

Cela n'a pas été résolu si vous avez lu attentivement les affiches et mon résumé. Vous devez souffrir de ce problème pour analyser leurs mots beaucoup plus attentivement que vous ne l'avez fait et voir cela. Je suis désolé que vous ne puissiez pas le faire et m'avez jugé si durement. Par exemple, le PO a déclaré qu'il était revenu à 5%, mais il aurait facilement pu revenir après avoir effacé le journal et il n'a pas suivi - en fait, cela est arrivé à un autre intervenant. Par conséquent, rien n'a été résolu puisqu'il n'a pas vérifié que les résultats sont restés à 5% en permanence.
harry

Désolé Harry - ce n'est pas une réponse; vous revendiquez des logiciels bogués et dites au PO de travailler avec sa société antivirus. C'est idéal pour votre blog personnel ou un article, mais un éditorial n'est pas une réponse à une question de deux ans avec une réponse acceptée, avec une cause racine sans rapport avec l'antivirus.
David Makogon

@harry, étonnamment, je suis de retour ici encore une fois en essayant de le comprendre à nouveau :) Aucun AV sur le système. J'ai fait quelques mises à jour Windows et changé le fichier journal max pour archiver à 500 Mo à partir de 1 Go. Même à 1 Go, il n'a roulé qu'une fois en 8 mois, tandis que mes autres DC roulent un peu plus. J'ai suivi la suggestion "SC config EventLog Type = own" pour sortir le fichier journal. Après le redémarrage, le processus evenlog est tombé en dessous de 1%. Les «dhcp et lmhosts» qui ont été attachés au processus sont également inférieurs à 1% du processeur. J'enregistrais seulement environ 15 événements de sécurité / seconde.
Travis

Je soupçonnais qu'un agent SSO que j'avais exécuté avait quelque chose à voir avec cela car il avait de nombreuses erreurs, mais la désactivation du service n'a pas entraîné une baisse de l'utilisation du processeur, même après un redémarrage. L'agent SSO est de sauvegarde et le processeur est toujours faible, alors qui sait.
Travis
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.