Problème de fin de tâches

Roby · 2021-09-14 10:06:27

Bonjour,

J'ai très souvent mes tâches qui ne se terminent pas (elles restent "en cours"). Du coup après c'est un peu le bordel, car certaines se terminent, du coup quand l'agent revient chercher les infos, il met en erreur celle encore en cours et relance celle qui sont terminées ...

Alors, cela concerne les tâches NetDiscovery

Dans Execution des jobs, j'ai :

vm-glpi-test-2021-01-28-11-49-40
2021-09-13 18:19:40
==importdenied== [ip]:172.18.14.4, [name]:172, [entities_id]:0
613f55dd7dd29
2021-09-13 18:19:40 En cours d'exécution Import refusé [ip]:172.18.14.4, [name]:172, [entities_id]:0
2021-09-13 18:19:40 En cours d'exécution 1 périphériques trouvés
2021-09-13 18:19:40 En cours d'exécution Import refusé [ip]:172.18.14.2, [name]:172, [entities_id]:0
2021-09-13 18:19:40 En cours d'exécution Import refusé [ip]:172.18.14.3, [name]:172, [entities_id]:0
2021-09-13 18:19:40 En cours d'exécution 1 périphériques trouvés
2021-09-13 18:19:40 En cours d'exécution 1 périphériques trouvés
2021-09-13 18:19:39 En cours d'exécution Import refusé [ip]:172.18.14.1, [name]:172, [entities_id]:0
2021-09-13 18:19:39 En cours d'exécution 1 périphériques trouvés
[...]

j'ai activé les logs de l'agent, dans les logs, ça semble se finir plus tard :
[...]
[Mon Sep 13 18:24:03 2021][debug] [thread 20] termination
[Mon Sep 13 18:24:03 2021][debug] [thread 71] termination
[Mon Sep 13 18:24:03 2021][debug2] [thread 61] processed 99 scans
[Mon Sep 13 18:24:03 2021][debug] [thread 61] termination
[Mon Sep 13 18:24:04 2021][debug] [thread 23] #6653, - scanning 172.18.14.253 with SNMP, credentials 2: no result, no response from host 172.18.14.253
[Mon Sep 13 18:24:04 2021][debug] [thread 23] #6653, - scanning 172.18.14.253 with netbios: no result
[Mon Sep 13 18:24:04 2021][debug] [thread 83] #6648, - scanning 172.18.14.248 with timestamp ping: no result
[Mon Sep 13 18:24:04 2021][debug2] [thread 83] #6648, executing ip neighbor show 172.18.14.248
[Mon Sep 13 18:24:04 2021][debug] [thread 25] #6647, - scanning 172.18.14.247 with timestamp ping: no result
[Mon Sep 13 18:24:04 2021][debug2] [thread 25] #6647, executing ip neighbor show 172.18.14.247
[Mon Sep 13 18:24:05 2021][debug] [thread 83] #6648, - scanning 172.18.14.248 in arp table: no result
[Mon Sep 13 18:24:05 2021][debug2] [thread 83] processed 93 scans
[Mon Sep 13 18:24:05 2021][debug] [thread 83] termination
[Mon Sep 13 18:24:05 2021][debug] [thread 25] #6647, - scanning 172.18.14.247 in arp table: no result
[Mon Sep 13 18:24:05 2021][debug2] [thread 25] processed 94 scans
[Mon Sep 13 18:24:05 2021][debug] [thread 25] termination
[Mon Sep 13 18:24:06 2021][debug] [thread 23] #6653, - scanning 172.18.14.253 with timestamp ping: no result
[Mon Sep 13 18:24:06 2021][debug2] [thread 23] #6653, executing ip neighbor show 172.18.14.253
[Mon Sep 13 18:24:06 2021][debug] [thread 23] #6653, - scanning 172.18.14.253 in arp table: no result
[Mon Sep 13 18:24:06 2021][debug2] [thread 23] processed 97 scans
[Mon Sep 13 18:24:06 2021][debug] [thread 23] termination
[Mon Sep 13 18:24:06 2021][error] 33 devices scan result missed
[Mon Sep 13 18:28:43 2021][debug] All netdiscovery threads terminated

Du coup, alors que la tâche est terminée depuis 18:28, sur l'interface elle est encore notée "En cours" ...
Je ne sais pas vraiment par ou chercher ...

Ah, dans la configuration de l'agent, j'ai :
Nombre de threads (découverte réseau) : 100
Timeout SNMP (découverte réseau) : 3
Dernier contact : 13-09-2021 18:29
Nombre de threads (inventaire réseau (snmp)) : 75
Timeout SNMP (inventaire réseau (snmp)) : 3

Merci d'avance

Last edited by Roby (2021-09-14 14:07:17)

gbougard · 2021-09-15 09:22:26

Bonjour Roby,

dans ton log, la ligne "[Mon Sep 13 18:24:06 2021][error] 33 devices scan result missed" est intéressante. Cela me fait penser qu'on a peut-être encore un bogue dans la gestion des threads. J'ai ajouté la ligne qui génère ce message il y a 2 ans quand j'ai entièrement retravailler le multi-threading de cette tâche qui ne fonctionnait déjà pas bien.

En plus de ta config agent, peux-tu préciser quel agent et en quel version tu utilises ? Peux-tu préciser aussi quel OS tu utilises ? J'ai vu quelque part dans la vieille doc qu'il pourrait y avoir des soucis avec entre le sur des threads et SSL. Donc petite question au passage, est-ce que l'url de ton serveur est en "https://" ?

Enfin, peux-tu préciser quel est la plage ip scannée ? Des ips que je vois dans ton log, j'imagine que ça pourrait être juste 172.18.14.1 à 172.18.14.253. Si c'est bien ça, 100 threads pour la découverte, c'est assez overkill. Et même 75 threads pour l'inventaire, ce sera à mon avis beaucoup trop. Les bons chiffres à utiliser dépendent du nombre d'équipement réel que tu as à scanner. Pour l'inventaire, il faut cibler une durée globale d'exécution en calculant tout en sachant qu'on ne va faire l'inventaire que sur des équipements découverts et qui sont donc sensés répondre en snmp (à moins biensûr qu'ils aient été éteints dans l'intervalle). Mettons, si tu estimes que tu as 1000 équipements et que la moyenne de la durée d'un inventaire donné est 20 secondes (et c'est volontairement pessimiste pour la démonstration), cela ferait un traitement en environ 20000 secondes sur un seul thread, soit environ 5h30... si tu répartis la charge sur 10 threads, tu ramèneras la durée totale du traitement à 2000 seconds, soit un peu plus de 30 minutes et ça me semble honnête pour 1000 équipements.
Pour la découverte, c'est un peut plus compliqué... là, il faut plutôt prendre en compte les ips qui ne répondent pas et dont la durée d'un scan sera plutôt le timeout snmp de découverte x le nombre de credentials testés... généralement, si l'équipement répond, le scan de découverte, qui ne tape que sur quelques OIDs, ne va prendre qu'une ou 2 secondes gros max, mais généralement, c'est inférieur à une seconde. Là, sur une plage de 250 ips avec uniquement 10 équipements qui vont répondre et 2 crédentials, la durée de ton traitement sur un seul thread serait probablement de 10 x 1 seconde + (250-10) x timeout de 3 x 2 credentials = 1450 secondes, soit un peu plus de 20 minutes. Si tu répartis la charge sur 10 threads, tu ramèneras la durée à 2 minutes.

Donc passé la petite démo, peux-tu aussi préciser le nombre de credentials définis et associés à ta plage ip ?

Roby · 2021-09-15 12:14:37

Bonjour,

Mes collègues du réseau m'ont mis tout plein de sous réseau ...
Donc, logiquement si je veux tout scanner, je fais
172.18.1 à .14
172.19.1 à .12

192.168.2 à .173

Mais effectivement il y a plein de vide qui ne répondrons pas ... donc beaucoup de timeout ...
Useragent : FusionInventory-Agent_v2.6-1
Version : INVENTORY: v2.6-1
NETWORKDISCOVERY: 4.2
NETWORKINVENTORY: 4.2
OS : Ubuntu serveur 20.04.3

oui, l'url de mon serveur est bien en "https://"

En crédential snmp j'en ai 4 ... alors j'imagine bien que tout ça cumulé ça fait vraiment beaucoup. Mais ce que je ne comprend pas c'est que parfois ça fonctionne !

Ah oui, et suite à mon souci de Wyse, pour le moment j'ai mis uniquement la première plage (172.18.1-.14) ...

Maintenant il est possible que je diminue le nombre de threads sans souci si besoin

Merci

Roby · 2021-09-16 14:26:49

Je viens de tester avec 10 et 10 et ça a terminé avec succès (juste une plage) je vais voir si ça continue puis j'ajouterai les autres plages

Merci

Roby · 2021-09-20 14:23:49

J'ai ajouté toutes les plages et c'est toujours ok. Donc il y a un souci en cas de "gros" multitaches

Je vais laisser à 10 et 10

Merci !

Forum GLPI-Project

Announcement

#1 2021-09-14 10:06:27

Problème de fin de tâches

#2 2021-09-15 09:22:26

Re: Problème de fin de tâches

#3 2021-09-15 12:14:37

Re: Problème de fin de tâches

#4 2021-09-16 14:26:49

Re: Problème de fin de tâches

#5 2021-09-20 14:23:49

Re: Problème de fin de tâches

Board footer