ERREUR 1020, HYPERTHREADING la suite ...
Loïc
Voici le message que j'avais posté il y a quelques temps et expliquant
nos problèmes :
**********************************
Notre application tourne sur un serveur 2000 Pro avec 4 processeurs en
hyperthreading (donc 4 virtuels en plus).
De plus, elle est utilisée en TSE par une 50aine d'utilisateurs.
Suite à des erreurs 1020 intempestives lors de l'utilisation de
traitements assez lourds (requêtes dynamiques, gros fichiers et
jointures), et après recherche sur le net des différentes solutions
proposées, nous avons tenté le code suivant à l'initialisation du
projet, code qui permettrait de désactiver le multithreading :
hInstance est un entier = API("KERNEL32","GetCurrentProcess")
dwProcessAffinityMask est un entier = 1
API("KERNEL32","SetProcessAffinityMask",hInstance,dwProcessAffinityMask)
Les erreurs 1020 ont automatiquement disparu (nous pouvions les
reproduire sans problème), mais le serveur n'a pas tenu la journée :
très fort ralentissement puis blocage.
Nous avons donc du enlever ce code, et les erreurs 1020 ont réapparu.
**********************************
Nous avons désormais désactivé l'hyperthreading directement au
niveau du serveur (bios).
Les erreurs 1020 sont toujours là.
H.E.L.P. :-)
mat
>
> Nous avons désormais désactivé l'hyperthreading directement au
> niveau du serveur (bios).
> Les erreurs 1020 sont toujours là.
>
> H.E.L.P. :-)
>
Bonjour,
Nous avons également ce problème de temps en temps, seulement avec des
machines avec HT (désactivé). Mais c'est devenu relativement rare,
d'autre part je n'ai pas de client avec autant d'utilisateurs.
A part désactiver HT dans le BIOS, depuis quelque temps nous lançons la
procédure suivante à l'ouverture du projet, que je pense correspond à ce
que vous faisiez. Nous n'avons à ce jour pas eu de rapports sur des
ralentissements. Essayez la combinaison des deux mesures, peut-être ça
ira mieux.
J'ai remarqué que les problèmes restants se passent presque toujours
lors d'un accès à une requête, la plupart du temps lors d'une
impression. J'ai noté des problèmes avec les contextes de requêtes HF
dès que nous avons migré l'application de WD8 à WD9. Par conséquent, je
soupçonne que les problèmes sont une combinaison de choses, entre HT et
faiblesses de Windev dans la gestion des contextes HF.
Salutations
Mat
PROCEDURE StopHT()
hInstance est entier
RetourFonction est entier
dwProcessAffinityMask est entier
versionplateforme est chaîne
versionplateforme = SysVersionWindows(sysVersionPlateForme)
SI versionplateforme = "NT"
dwProcessAffinityMask = 1 // ICI: choix du CPU
hInstance = API("KERNEL32","GetCurrentProcess")
RetourFonction =
API("KERNEL32","SetProcessAffinityMask",hInstance,dwProcessAffinityMask)
SI RetourFonction = 0 ALORS
Erreur(ErreurInfo())
Ferme()
FIN
FIN
mat
...
> J'ai remarqué que les problèmes restants se passent presque toujours
> lors d'un accès à une requête, la plupart du temps lors d'une
> impression. J'ai noté des problèmes avec les contextes de requêtes HF
> dès que nous avons migré l'application de WD8 à WD9. Par conséquent, je
> soupçonne que les problèmes sont une combinaison de choses, entre HT et
> faiblesses de Windev dans la gestion des contextes HF.
en fait, je voulais dire que si vous êtes sous WD9 il faudrait analyser
où le programme se plante. Il est possible qu'il faut rendre des
contextes HF plus claires: p.ex. rafraîchir une requête dans l'ouverture
d'un état, même si le contexte ne change pas. Nous avons centralisé la
composition et lancement des requêtes dynamiques dans des méthodes de
classes relatifs aux fenêtres. Il est pensable que cela ajoute au
problème de contextes, pas toujours, mais sous certaines conditions.
S'il est possible d'isoler un endroit problématique, on peut essayer de
limiter le contexte HF à la fenêtre ou l'état concerné.
Ce problème n'est certes pas dû à des erreurs dans le code, mais de
modifications importants dans la gestion de requêtes sous WD9 qui, à ma
connaissance, n'ont jamais été documentés par PC Soft.
DAIREAUX Jean-Baptiste
news:1142343287.7...@j52g2000cwj.googlegroups.com...
Bonjour,
H.E.L.P. :-)
Bonjour,
Avez vous essayez de faire varier la valeur de la variable
dwProcessAffinityMask de façon a ce que la charge d'execution ne soit pas
que sur le processeur n°1 pour vos 50 utilisateur (pour pouvoir bénificier
des autre processeurs)
Nous nous avons fait varier la valeur par rapport au nombre de processeur
virtuel de la machine pour qu'à chaque connexion d'un utilisateur à
l'application, l'exe se lance sur le processeur suivant.
J.B.D.