SCOM gourmant ? (trop)
Emmanuel Dreux
SP2 non critiques, mauvaise surprise: les DC équipés de 1Go de RAM ont
(TOUS) explosé en plein vol.
En effet, toutes les minutes une dizaine de script sont planifiés qui
consomment chacun un peu plus de 100 Mo ... et donc prennent toute la RAM,
puis pagination excessive, puis donc 100% cpu etc...
On n'avait pas ce problème en environnement de test virtualisé.
Pour tester, le service antivirus a été arrêté et le répertoire Healt
exclus, même problème.
Nous avons vu un fix pour ce type de problème mais notre version de dll est
supérieure à celle apportée par le fix.
Il me semble abhérent que l'agent MOM consomme 1 Go de RAM toutes les
minutes et que pour monitorer des DC qui servent 6 users par jour, il faille
les passer à plus de 2 Go de RAM.
Quel est votre retour d'expérience sur ce sujet?
Y-a-t-il un moyen de déterminer ces scripts schédulés ainsi que ses
paramètres d'exécution, de désactiver les rules qui les déclenchent ou de
tuner et modifier ces scripts pour qu'ils consomment moins?
--
Cordialement,
Emmanuel Dreux
http://www.ilinfo.fr
Yann Gainche [MVP]
Bonjour,
C'est un bug dans le nouveau management pack DNS. Il faut désactiver
les moniteurs sur les zones.
Cordialement,
--
Yann Gainche
MVP - Microsoft Operations Manager
Emmanuel Dreux
Malheureusement, c'était déjà fait, j'avais désactivé tous les monitors et
règles contenant le nom nslookup.
Le problème n'est pas lié à un script en particulier.
C'est qu'une dizaine de scripts s'éxécutent en même temps toutes les minutes
et consomment chacun environ 110Mo. Le calcul est vite fait sur un DC qui
possède 1Go de RAM.
L'utilisation de mémoire monte à 1,8 Go - 2 Go, la mémoire disponible
descend à quelques kilo octets et le DC ne répond plus: pagination excessive,
plus de mémoire, processor queue lenght monte en flèche etc etc.
J'ai ça sur les 10 premiers DC sur lesquels j'ai lancé l'installation de
l'agent.
On a donc stoppé le déploiement et désactivé l'agent sur les DC en question.
Dès que je réactive le service sur un Dc, le comportement réapparait.
Il n'y a pas le problème sur les DC qui ont 4 Go de RAM. Mais il y a encore
plein qui n'ont qu'1 Go de RAM car ils servent peu de users, servent de
domaines de test, d'intégration mais sont quand même considérés comme de la
prod.
Par quel moyens peut-on facilement savoir quels scripts sont planifiés sur
un DC en particulier, et ses paramètres passés en arguments.
Je pourrais essayer de les relancer manuellement et de les tuner/améliorer (
affiner les requêtes WMI, libérer les objets manipulés par les script plus
tôt etc).
--
Cordialement,
Emmanuel Dreux
http://www.ilinfo.fr
"Yann Gainche [MVP]" a écrit :
Yann Gainche [MVP]
Il ya aussi le management pack DHCP qui utilise netsh pour superviser
les zones. à désactiver aussi.
Emmanuel Dreux
C'était un bug du moteur de script.
Au lieu de consommer 120 Mo par script, ça en consomme maintenant 5.
soit 20x5 = 100 Mo à chaque discovery périodique au lieu de 2 Go.
Yann Gainche [MVP]
Bonjour,
peux-tu nous dire quel bug et quel correctif ?
Cordialement,
![Stephane [MS]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjVlhXccLkItr2L2hobUgNieIJaEeqr4fpHWalnVfGIAEgxlpA=s40-c)
Stephane [MS]
Il peut s'agir des problèmes des packs DHCP ou DNS que, me semble-t-il, tu
connais bien.
--
Cdlt
Stéphane
http://blogs.msdn.com/spapp/default.aspx
"Yann Gainche [MVP]" <fo...@gainche.net> a écrit dans le message de
news:%23MIYiNi...@TK2MSFTNGP03.phx.gbl...
Emmanuel Dreux
non, ici le 100% cpu était la conséquence du problème, pas la cause.
Rien à voir avec les 100% cpu causés par les MP DNS ou DHCP.
Je vous fais un petit résumé du problème rencontré (traité par emmadel pour
info).
Symptome:
Une plateforme SCOM.
4 MP déployés: AD, DNS, DHCP, WINS.
Après l'installation de l'agent, les scripts de discovery se lancent.
Résultat:
20 scripts exécutés en même temps toutes les 3 à 5 minutes.
Chaque script consomme 100 à 130 Mo de RAM, soit un total de plus de 2 Go.
Conséquence:
Mémoire disponible tombe à 0.
Donc pagination excessive.
Donc 100% cpu et ongueur de file d'attente CPU augmente.
La machine ne répond alors plus pendant quelques minutes...
Ce même phénomène se déroule toutes les 5 minutes environ.
Même après plusieurs heures, aucune stabilisation.
Résolution:
La mise à jour du moteur de la dernière version du moteur de script Wscript
(actuellement version 5.7) a corrigé le pb.
Chaque script consomme maintenant 5 Mo au lieu de 120.
La charge consécutive à l'exécution de 20 scripts en même temps est
maintenant absorbée "à l'aise".
Note:
Les DC avec suffisemment de RAM ( de 2 à 4go) sont susceptibles de ne pas
rencontrer le pb.
Les DC avec des processeurs de génération récente (puissants) sont
susceptibles de ne pas rencontrer le problème: plus les processeurs sont
puissants, plus les scripts s'exécutent rapidement, moins il y a de risque
d'avoir assez de scripts s'exécutant simultanément pour saturer la RAM.
ça explique pourquoi nous avons rencontré le pb sur "seulement" une
quinzaine de DC.!!! :-)
J'éspère que ces info vous seront utiles.
--
Cordialement,
Emmanuel Dreux
http://www.ilinfo.fr
"Stephane [MS]" a écrit :
Yann Gainche [MVP]
CPU moyenne est de 3 à 4 %.
Je penche plutôt pour un problème sur les serveurs.
Récement, j'ai eu le problème chez un client avec un antivirus Trend
qui malgré la mise en place des restrictions conseillées pour les
agents SCOM continuait de scanner les scripts. En arrêtant l'antivirus,
la consommation CPU revenait à des valeurs normales.
Nous avons également eu des problème avec le pire des agents hardware
du monde : Director sur les plateformes IBM.
cherchez dans ces directions.
Sinon, on doit pouvoir récupérer la fréquence et le type de CPU pour
peupler automatiquement un groupe de machines 'lentes' et s'en servir
pour cible pour des overrides modifiant la fréquence des objets de
découverte.
Pour ce qui concerne DHCP, c'est réglé dans la dernière version du
pack. J'ai aussi testé le MP DNS qui va sortir dans 2 semaines et c'est
également un problème résolu.
Cordialement,