Nagios defunct child process

Répondre
Avatar de l’utilisateur
dsebire
Messages : 13113
Inscription : ven. 12 janv. 2018 17:44
Localisation : Loiret - entre la ville et les champs

Nagios defunct child process

Message par dsebire »

Hello,

j'ai mon nagios qui est pas mal chargé (l'API VMWARE semble un peu moisie et peu optimisée)
du coup, les process des check (actifs) tardent a être supprimés par nagios (le PPID)

jusque la, pas très inquiétant vu ce qui est indiqué dans la doc nagios (fonctionnement normal)

sauf que dans mon cas, au bout d'une semaine, j'ai un grosse dizaine de Zombies qui restent et qui ne sont pas réclamés (vieux de plusieurs jours/heures)

bug nagios ?
machine trop chargée ? (les zombies aident pas) et donc interruption non recupérée ?

j'ai aucun iowait, que du CPU (calcul)

les io disque, reseau et autre sont faibles, j'ai peu de latence sur l'ensemble de la machine.

qqn a déjà été confronté au pb ?

Merci
Avatar de l’utilisateur
Zedoune
Messages : 15343
Inscription : ven. 12 janv. 2018 17:44

Nagios defunct child process

Message par Zedoune »

Salut

si tu fais netstat t'as pas plein de trucs qui trainent en TIME_WAIT ?
Avatar de l’utilisateur
dsebire
Messages : 13113
Inscription : ven. 12 janv. 2018 17:44
Localisation : Loiret - entre la ville et les champs

Nagios defunct child process

Message par dsebire »

bah si, c'est même un peu le principe :D
il envoie les requêtes et attend la réponse, je monitore pas mal de trucs (y compris a travers du WEB, des fois avec un délai de 75-100ms)

du coup, j'ai plein de socket ouvertes en time wait ;)

J'utilise majoritairement de l'UDP (nrpe) qui a ma connaissance n'etant pas en mode "connecté" restent ouvertes jusque timeout (pas de fermeture de socket)
Avatar de l’utilisateur
Zedoune
Messages : 15343
Inscription : ven. 12 janv. 2018 17:44

Nagios defunct child process

Message par Zedoune »

bah si, c'est même un peu le principe :D
il envoie les requêtes et attend la réponse, je monitore pas mal de trucs (y compris a travers du WEB, des fois avec un délai de 75-100ms)

du coup, j'ai plein de socket ouvertes en time wait ;)

J'utilise majoritairement de l'UDP (nrpe) qui a ma connaissance n'etant pas en mode "connecté" restent ouvertes jusque timeout (pas de fermeture de socket)
il faut peut être augmenter des sysctl en rapport avec le nombre maximum de ports/sockets ouverts/en attente etc.. peut être tu as peut être atteint une limite
Avatar de l’utilisateur
dsebire
Messages : 13113
Inscription : ven. 12 janv. 2018 17:44
Localisation : Loiret - entre la ville et les champs

Nagios defunct child process

Message par dsebire »

ou baisser le timeout sur les connex inactives

je regarde ça, merci mamzelle ;)
Avatar de l’utilisateur
dsebire
Messages : 13113
Inscription : ven. 12 janv. 2018 17:44
Localisation : Loiret - entre la ville et les champs

Nagios defunct child process

Message par dsebire »

bon, je suis loin de la limite.
j'ai a peu près 500 connex en attente.
baisser le timeout ne change rien (1mn d'origine, j'ai tenté jusque 15s)
le nombre de connex ne baisse pas.
=> mes connexions sortantes se ferment en moins de 15s toutes seules.

j'ai remarqué que si j'augmente la charge de la machine, le nombre de zombies augmente en flèche (mais finissent quand même par être récupérés par le process père)

du coup, je sais toujours pas comment ni pourquoi j'en ai de temps en temps qui restent.... :(

Avatar de l’utilisateur
Zedoune
Messages : 15343
Inscription : ven. 12 janv. 2018 17:44

Nagios defunct child process

Message par Zedoune »

je peux pas t'aider plus que ça je connais pas nagios :(
Avatar de l’utilisateur
dsebire
Messages : 13113
Inscription : ven. 12 janv. 2018 17:44
Localisation : Loiret - entre la ville et les champs

Nagios defunct child process

Message par dsebire »

le problème s'est résolu tout seul sur la nouvelle conf.
l'ancienne machine pédalait pas assez vite et des fois les process ne se terminaient pas correctement.
Avatar de l’utilisateur
dsebire
Messages : 13113
Inscription : ven. 12 janv. 2018 17:44
Localisation : Loiret - entre la ville et les champs

Re: Nagios defunct child process

Message par dsebire »

déterrage....
je viens de changer le routeur internet (pour beaucoup plus puissant)
le CPU load de la machine est divisé par 3.
aucune autre modif.

comment est-ce possible ???
L'ancien commençait a être à la ramasse (double de connexions sortantes par rapport à l'époque, des tunnels VPN dans tous les sens, plein de règles de firewall, idem pour le routage etc...)
est-ce que la latence induite par l'ancien routeur pourrait expliquer ça ?
Avatar de l’utilisateur
Ryu_wm
Messages : 8043
Inscription : ven. 12 janv. 2018 17:44

Re: Nagios defunct child process

Message par Ryu_wm »

Tu emploies des proto comme ospf/rip ou snmp ? ça aurait pu expliquer une partie de l'occupation.
Avatar de l’utilisateur
dsebire
Messages : 13113
Inscription : ven. 12 janv. 2018 17:44
Localisation : Loiret - entre la ville et les champs

Re: Nagios defunct child process

Message par dsebire »

quasi que snmp et nrpe.
un peu de http
du ping
gizmo78
Messages : 20482
Inscription : ven. 12 janv. 2018 17:44

Re: Nagios defunct child process

Message par gizmo78 »

j'ai déjà vu de l'empilement de process qui faisaient monter le load de façon débile mais impact réel derrière.

si il galérait à traiter la fermeture des process, why not
Avatar de l’utilisateur
Ryu_wm
Messages : 8043
Inscription : ven. 12 janv. 2018 17:44

Re: Nagios defunct child process

Message par Ryu_wm »

dsebire a écrit : ven. 23 sept. 2016 11:42 le problème s'est résolu tout seul sur la nouvelle conf.
l'ancienne machine pédalait pas assez vite et des fois les process ne se terminaient pas correctement.
un max de zombies ça aurait pu aussi
Avatar de l’utilisateur
dsebire
Messages : 13113
Inscription : ven. 12 janv. 2018 17:44
Localisation : Loiret - entre la ville et les champs

Re: Nagios defunct child process

Message par dsebire »

les soucis de zombie (=galère a fermer les process) ça a été réglé en changeant le serveur.

la j'ai juste changé le routeur, rien niveau config ni machine de supervision.
Répondre