Consommation mémoire

[azerty21]

Bonjour,

J'ai monté une plateforme de test pour un remplacement de nagios/centreon par shinken/centreon et après avoir importer tous mes hosts et une partie de mes services, la plateforme fonctionne mais j'ai une consommation mémoire importante par rapport à ma plateforme nagios/centreon. 300 Mo pour nagios/centreon contre 900 Mo pour shinken/centreon avec 2 fois de services !
(Voir pièces jointes)

Pour info, voici mes deux plateformes :
Plateforme de prod : 500 hosts et 4000 services
Plateforme de test : 500 hosts et 1500 services

Est-ce que vous avez déjà rencontrez ce problème ?
Que puis-je faire pour améliorer cette conso mémoire ?

Merci d'avance pour vos réponses...

[Seb-Solon]

Salut,

J'ai pu faire des tests sur shinken à une epoque et j'avais des problèmes de mémoire car j'avais un peu trop forcé et que je bossais sur des petites VM. Je pense pas que ce soit le cas pour toi, mais je te le dis quand meme.

Sinon, est ce que tu as beaucoup de processus zombies? Ca peut venir de là. Dans ce cas là, essaye d'augmenter le nombre de worker sur ton scheduler. Quelle est ta config sinon? 1500 services checkés à quelle fréquence?

[azerty21]

Merci de ta réponse

Processus zombie

Code: [Sélectionner]

lxlgaedusurv:~# ps aux | grep Z
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
nagios   29786  0.0  0.0      0     0 ?        Zs   18:01   0:00 [sh] <defunct>
nagios   29875  0.0  0.0      0     0 ?        Zs   18:01   0:00 [sh] <defunct>
root     29999  0.0  0.0   9616   908 pts/0    S+   18:01   0:00 grep Z
lxlgaedusurv:~#
Pour les fréquences des services, je t'ai fait 2 screenshots...

[Seb-Solon]

Ok donc à priori, ya pas de zombies

Je ne suis pas un utilisateur de centréon, la colonne 5min / 1 min signifie quoi? Check toutes les 5 minutes et toutes les minutes s'il y a un problème?

Dans ce cas là on serait à 300 checks minutes, c'est peanuts pour Shinken normalement

Quelle est ta config? Essaye de lancer le scheduleur en monde debug pour voir. Il lache pas mal d'infos

[david.guenault]

Les performances de shinken se font généralement au prix d'une augmentation de la mémoire consommée (ya pas de magie désolé). C'est normal.

[naparuba]

Oui en effet, en fait si on aurait gardé le même mode de fonctionnement que Nagios, même en Python on aurait pu garder la même consommation mémoire, mais on a mis en plusieurs daemons (avec une copie de certaines données inévitable entre eux) et surtout beaucoup d'informations de corrélations supplémentaires pour chaque élément qui fait grimper la note. On reste encore dans des ordres de grandeurs acceptables je pense.

[azerty21]

Je ne suis pas un utilisateur de centréon, la colonne 5min / 1 min signifie quoi? Check toutes les 5 minutes et toutes les minutes s'il y a un problème?

C'est bien ça. La fréquence est la même sur les deux serveurs.

Quelle est ta config? Essaye de lancer le scheduleur en monde debug pour voir. Il lache pas mal d'infos

J'ai lancé Shinken en mode debug, regardé les logs mais je ne vois rien d'anormal... Je mets les logs en pièces jointes (anonymisé).

[naparuba]

Hum attends, j'avais zappé la problématique en me focalisant sur la mémoire.

Si je comprends bien tu as deux process à chaque fois avec pleins de ram consommée c'est bien ça? (le zombies c'est un peu à part, je vais y revenir).
Pour les doubles process, c'est "normal", en fait c'est un sous-process qui permet les échanges avec des modules, mais sa consommation de ram "réelle" est quais nulle (merci le copy on write de Linux).


Pour les zombies, tu en as beaucoup? Si tu reste avec pas mal de zombies en continue, je te conseille de diminuer ton processes_by_worker pour ton poller et d'augmenter le min_workers. Il y a combien de CPU sur la machine?

[azerty21]

J'ai refait quelques tests sur l'occupation mémoire par rapport au nombres de services :
500 services : environ 800 Mo de RAM
1000 services : environ 1000 Mo de RAM
1500 services : environ 1200 Mo de RAM
2000 services : environ 1400 Mo de RAM
4000 services : environ 1700 Mo de RAM et 1600 Mo en swap
Avec 4000 services, Centreon perd régulièrement le poller malgré le faites que tous les composants Shinken soient toujours en exécution.

Hosts : 500
Mon Architecture : Dell Poweredge T100, intel xeon x3220 @2.4Ghz (4 coeurs), 2 Go de RAM

Pas de processus zombie actuellement.

Est-ce peine perdue ou y a-t-il un paramètre sur lequel je peux jouer ?

[Seb-Solon]

C'est étrange qu'il n'y ait pas de zombies, car dans le logs de debut, il y en a un peu (pas érorme mais bon)

Code: [Sélectionner]

Checks: total 1604 scheduled 1578 inpoller 26 zombies 0 notifications 440
Latency (avg/min/max) : 0.93/0.18/2.45
Nb checks/notifications/event send: 14
Nb Broks send: 333
Check average = 16 checks/s
16 checks / s c'est pas énorme, sauf si c'st des truc lourd à executer.

[naparuba]

Tu es en quelle version de Python? Sur ma Centos5/Python2.6, j'ai une conf à 8K services sur un serveur à 3Go de RAM, et Shinken doit me prendre 2Go à ce que je vois.

Ca dépends aussi des modules (je tourne sans LiveStatus par exemple). Donc à part le choix des UI/modules et la version de Python, non il n'y a pas de moyens de faire diminuer la consommation RAM (sauf à complexifier le code pour gagner 500Mo de ram, mais je ne pense pas que ça en vaut la chandelle vu les bugs que ça risque de faire après).

[azerty21]

Après quelques nouveaux "ps aux | grep Z", il y a effectivement des processus zombies... 
Je vais essayer d'appliquer les précédents conseils : "je te conseille de diminuer ton processes_by_worker pour ton poller et d'augmenter le min_workers"

Python version 2.6.6

J'ai désactivé le module LiveStatus : ça n'a rien changer...
J'ai désactivé le module PickleRetentionBroker : rien changé non plus...

[naparuba]

Ton Python est pas mal, c'est une version pas trop ancienne (j'ai la même en prod je crois).

Quand tu dis rien n'a changé, c'est pour la RAM? Car Pickle retention ça c'est normal que ça ne change rien mais pas le LS qui lui a une instance complète de conf en ram.

[azerty21]

Oui, c'est pour la RAM que ça n'a rien changé.
Question bête : pour désactiver les modules, il faut les supprimer de la ligne modules dans la partie broker ou faut-il commenter en plus tout le module ?

Hier soir, j'ai passé le processes_by_worker à 192, min_workers à 4 et max_workers à 8. Ce matin, 1700 Mo en RAM et 1900 en swap...

Côté processus zombie, c'est très léger ce matin :

Code: [Sélectionner]

lxlgaedusurv:~# ps aux | grep Z
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     22757  0.0  0.0   9616   904 pts/0    S+   08:53   0:00 grep Z
lxlgaedusurv:~# ps aux | grep Z
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     22758  0.0  0.0      0     0 ?        Z    08:53   0:00 [centstorage] <defunct>
root     22760  0.0  0.0   9616   904 pts/0    S+   08:53   0:00 grep Z
lxlgaedusurv:~# ps aux | grep Z
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     22762  0.0  0.0   9616   904 pts/0    S+   08:53   0:00 grep Z
lxlgaedusurv:~# ps aux | grep Z
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     22764  0.0  0.0   9616   908 pts/0    S+   08:53   0:00 grep Z


[naparuba]

Il suffit de l'enlever de la ligne module de l'objet en effet, pas besoin de commenter tout l'object module.

Tu peux faire un top trié sur la ram pour voir?