[RESOLU] Lenteur wapt-get : solution

[erickeke]

Une solution de contournement à un bug qui m'a longtemps agacé

Version du client : 1.7.4.6077 et supérieur, sur W10 > 1803

Machine hors domaine

Sur certaines machines wapt-get update est très long à se terminer.

En lançant wapt-get update -ldebug on trouve régulièrement ça dans les logs :

2019-06-13 14:59:43,460 DEBUG Transaction took too much time : 2.33699989319
2019-06-13 14:59:45,822 DEBUG Transaction took too much time : 2.31399989128
2019-06-13 14:59:48,397 DEBUG Transaction took too much time : 2.31700015068
2019-06-13 14:59:50,740 DEBUG Transaction took too much time : 2.30399990082
2019-06-13 15:00:17,855 DEBUG Transaction took too much time : 2.37700009346
2019-06-13 15:00:20,233 DEBUG Transaction took too much time : 2.34000015259

Parallèlement quand ces messages apparaissent, Procmon reste bloqué environ 2s sur "CreateFile \\WORKGROUP*\MAILSLOT\NET\NETLOGON" :

mailslot.PNG (9.69 Kio) Consulté 2118 fois

Solution de contournement :

Désactiver Netbios sur TCP/IP :

Capture.PNG (18.68 Kio) Consulté 2118 fois

En relançant wapt-get update -ldebug, le message "Transaction took too much time" disparaît. Dans Procmon plus aucune tentative d'ouverture de mailslot.

Du peu que je comprends, ça semble lié a un appel AD en rapport avec la gestion des comptes utilisateurs. L'appel AD est utilisé même pour interroger un compte local hors domaine... A creuser pour que je comprenne mieux.

Le thread ci-dessous m'a bien aiguillé, les timeouts évoqués étant similaires à ceux rencontrés :
https://social.technet.microsoft.com/Fo ... inserverDS

La première réponse correspond au problème et désactiver Netbios sur TCP/IP règle le problème et on peut enfin profiter d'un WAPT rapide

Je pense que l'équipe Wapt n'a pas rencontré le problème car ils utilisent principalement Wapt sur des machines dans un domaine AD.

Je complèterai mon post plus tard.

[htouvet]

Merci beaucoup pour cette analyse.
Effectivement sur nos infras netbios est généralement désactivé.

Le problème de lenteur peut-être aussi lié à la recherche des groupes auxquels la machine est rattachée.
( setuphelpers.get_computer_groups() )
qui fait appel à l'AD

Je pense qu'il faut qu'on paramètre cet usage ...

Pouvez-vous essayer de mettre une entrée host_profiles vide dans le wapt-get.ini ?

<waptdir>\wapt-get.ini :

Code : Tout sélectionner

[global]
host_profiles=

Les infos remontées faisant potentiellement appel à l'AD ou de la recherche de noms :

setuphelpers.host_info() :

Code : Tout sélectionner

    info['profiles_users'] = get_profiles_users()
    info['local_profiles'] = get_local_profiles()
    info['local_administrators'] = local_admins()
    info['local_groups'] =  {g:local_group_members(g) for g in local_groups()}
    info['local_users'] =  local_users()

dans un waptpython, on peut tester laquelle peut prendre du temps.

[dcardon]

Bonjour Erickeke,

Une solution de contournement à un bug qui m'a longtemps agacé

Version du client : 1.7.4.6077 et supérieur, sur W10 > 1803

Machine hors domaine

Sur certaines machines wapt-get update est très long à se terminer.

merci pour ton long quote. Est ce que tu as eu le temps de voir quelle est la fonction qui prend trop de temps avec la partie NetBIOS?

Comme tu le mentionnais dans ton mail, on a tendance à toujours désactiver Netbios (il y a un paquet dans le store pour cela )

On a fait quelques modifications pour améliorer ce soucis. Ca devrait être intégré dans la prochaine release.

En espérant que ça va résoudre le soucis. Sinon, la désactivation de NetBIOS est aussi une très bonne chose!

Cordialement,

Denis

[erickeke]

Désolé, j'avais loupé pas mal de messages et après vacances et reloupage de message. J'ai mis à jour mon mail vers un que je consulte plus

Non je n'ai pas regardé la fonction, je vais m'y remettre quand j'aurai 5 minutes promis !