Consommation mémoire

[azerty21]

Le top mémoire en pièce jointe.

J'ai désactivé la WebUI, l'occupation RAM a l'air plus faible. Toujours un peu de swap mais la ram oscille entre 1400 et 1600 Mo après 30 minutes de fonctionnement. Centreon n'a pas perdu le lien avec le poller.
Sur ta plateforme à 8K services, est-ce que la WebUI est activée ?

[naparuba]

Y a plusieurs trucs que j'ai du mal à comprendre sur ta capture :
* on ne voit pas le broker : tu n'as plus de modules liés?
* on voit une armée de mysql à 40Mo le process : c'est normal?
* un voit des pollers avec une conso mémoire un peu haute je trouve.

Voici ce que j'ai (8k services, modules NDO, logs et WebUI pour le broker) en conso mémoire :
mysql     687m/581m  /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/ (1 seul process)
nagios    329m/311m python26 bin/shinken-broker
nagios    247m/210m python26 bin/shinken-broker
nagios    152m/144m python26 bin/shinken-scheduler
Puis 10 httpd 159m/133m
Puis arbiter à 124m
Puis 5 pollers à 12m chacun (tu vois la différence avec les tiens? bizar)

On a donc pas du tout la même distribution, je ne comprends pas trop pourquoi.

[Seb-Solon]

Ouais, son scheduler prend pas mal de mémoire je trouve... 

[funkyman]

je trouve que le load est elevé aussi 

[naparuba]

Son scheduler est élevé oui. Pour le load, bah quand on swap, on a perdu donc le load explose 

[azerty21]

Petite précision : tous mes hosts sont distants, connectés par VPN donc avec un peu de latence.

Une partie de mon shinken-specific.cfg :

Code: [Sélectionner]

define poller {
  poller_name poller-1
  data_timeout 120
  timeout 3
  address 127.0.0.1
  port 7771
  manage_sub_realms 0
  max_workers 8
  check_interval 60
  polling_interval 1
  realm All
  max_check_attempts 3
  min_workers 4
  processes_by_worker 192
}
define reactionner {
  data_timeout 120
  timeout 3
  address 127.0.0.1
  reactionner_name reactionner-1
  manage_sub_realms 0
  max_workers 15
  spare 0
  check_interval 60
  polling_interval 1
  realm All
  max_check_attempts 3
  min_workers 1
  port 7769
}
define broker {
  broker_name broker-1
  data_timeout 120
  check_interval 60
  modules Simple-log, ToNdodb_Mysql ,Service-Perfdata, Host-Perfdata, PickleRetentionArbiter
  port 7772
  manage_sub_realms 1
  spare 0
  timeout 3
  address localhost
  realm All
  max_check_attempts 3
  manage_arbiters 1
}
define arbiter {
  modules PickleRetentionArbiter
  spare 0
  address 127.0.0.1
  port 7770
  arbiter_name Arbiter-Master
}

define scheduler {
  data_timeout 120
  check_interval 60
  weight 1
  modules PickleRetention
  spare 0
  timeout 3
  address 127.0.0.1
  scheduler_name default
  max_check_attempts 3
  realm All
  port 7768
}
define receiver {
  data_timeout 120
  check_interval 60
  port 7773
  spare 0
  timeout 3
  address 127.0.0.1
  realm All
  receiver_name receiver-1
  max_check_attempts 3
}

Ligne non commentée sur

brokerd.ini

Code: [Sélectionner]

workdir=/opt/shinken/var
user=nagios
group=nagios
use_local_log=1
local_log=brokerd.log

pollerd.ini

Code: [Sélectionner]

workdir=/opt/shinken/var
user=nagios
group=nagios
use_local_log=1
local_log=pollerd.log

reactionnerd.ini

Code: [Sélectionner]

workdir=/opt/shinken/var
interval_poll=5
maxfd=1024
port=7769
user=nagios
group=nagios
idontcareaboutsecurity=0
use_ssl=0
certs_dir=etc/certs
ca_cert=etc/certs/ca.pem
server_cert=etc/certs/server.pem
hard_ssl_name_check=0
use_local_log=1

receiverd.ini

Code: [Sélectionner]

workdir=/opt/shinken/var
interval_poll=5
maxfd=1024
port=7773
user=nagios
group=nagios
idontcareaboutsecurity=0
use_ssl=0
certs_dir=etc/certs
ca_cert=etc/certs/ca.pem
server_cert=etc/certs/server.pem
hard_ssl_name_check=0
use_local_log=1

schedulerd.ini

Code: [Sélectionner]

workdir=/opt/shinken/var
port=7768
user=nagios
group=nagios
idontcareaboutsecurity=0
use_ssl=0
certs_dir=etc/certs
ca_cert=etc/certs/ca.pem
server_cert=etc/certs/server.pem
hard_ssl_name_check=0
use_local_log=1


[naparuba]

Je ne vois qu'une seule chose d'un peu bizar : PickleRetentionArbiter sur le broker. Sinon le reste est classique.

Tu peux regarder sans le module de retention du scheduler pour voir?

[azerty21]

Petite vidéo de la commande top avec le PickleRetentionArbiter désactivé.

[Seb-Solon]

Dommage, on ne voit pas le nom des process. Je ne vois rien de très choquant perso. Si nap pense que 25% de Mem c'est normal, on voit juste que le CPU est utilisé..

[naparuba]

C'est une très bonne idée ça la vidéo 

Je ne vois rien de très choquant. On a le premier process à 400Mo, mais les autres sont tranquille. On a quand même en moyenne 500+100Mo de dispo au final, sur une machine de seulement 2Go c'est pas si mal.

C'est qui le process à 400Mo exactement? (scheduler ou broker?)

[azerty21]

Nouvelle semaine, nouvelle mémoire ! Le serveur est passé à 4 Go de RAM !
La consommation est toujours élevée mais ces 2 Go supplémentaires permettent un fonctionnement sans perte de connexion avec le poller de Centreon.
J'ai également refait une vidéo ce matin (après un week-end de fonctionnement) de la commande top avec le tri sur la mémoire ainsi que l'affichage des commandes

[naparuba]

Ca va mieux en effet. Tu as un joli load, tu as beaucoup de CPU sur la machine? (beaucoup de checks snmp qui tournent on dirait)

Sinon on voit un gros scheduler, c'est étonnant que ce soit lui le plus gros. Tu as beaucoup de comments ou de downtime de définis? As-tu encore le module de retention Nagios par hasard?

Bon en même temps 500Mo c'est pas la mort, mais bon je suis curieux

[azerty21]

4 CPU

Pas de downtime ni de comments définis.

Le module de retention Nagios ne semble pas actif :

Code: [Sélectionner]

lxlgaedusurv:~# ll /usr/local/nagios/var/retention.dat
-rw------- 1 nagios nagios 17K 25 janv. 10:55 /usr/local/nagios/var/retention.dat

Les modules PickleRetention (appelé par le scheduler) et PickleRetentionArbiter (appelé par l'arbiter) sont quant à eux actifs.

[naparuba]

Ok donc ton load est bien, faut pas plus

Pour le nagiosretention, ce module est en read only, donc c'est normal que le fichier de retention de nagios ne soit pas mis à jour. En même temps il fait 17K, donc même en le chargeant, ça n'explique pas une telle taille pour le scheduler :p

[funkyman]

D’après vous, j'ai le même probleme ?

Avec 4000 services en actifs, nous avons des pics de load :

top - 16:16:29 up 1 day,  6:19,  2 users,  load average: 53.42, 22.43, 15.88
Tasks: 188 total,   1 running, 187 sleeping,   0 stopped,   0 zombie
Cpu(s): 52.5%us,  3.3%sy,  0.0%ni, 33.2%id, 10.6%wa,  0.0%hi,  0.3%si,  0.0%st
Mem:   1028880k total,   451100k used,   577780k free,     3340k buffers
Swap:  2064376k total,   549616k used,  1514760k free,    31092k cached

quelques minutes plus tard

top - 16:21:14 up 1 day,  6:18,  2 users,  load average: 1.92, 10.14, 11.85
Tasks: 190 total,   4 running, 183 sleeping,   0 stopped,   3 zombie
Cpu(s): 14.6%us,  2.4%sy,  0.0%ni, 79.7%id,  3.3%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   1028880k total,   443888k used,   584992k free,     3440k buffers
Swap:  2064376k total,   553504k used,  1510872k free,    31680k cached

en laissant tourner le top j'ai l'impression d'avoir des "vagues" de plugins lancés en parallèles, j ai l’impression qu ils ne sont pas bien reparti dans le temps  par le sheduler:-\

A noter qu'avec 2500 services, nous avons un load moyen de 1,3 sans pics de load.

Qu elles sont les pistes pour débugger ?