Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

ERREUR 1020, HYPERTHREADING la suite ...

3 réponses
Avatar
Loïc
Bonjour,

Voici le message que j'avais post=E9 il y a quelques temps et expliquant
nos probl=E8mes :

**********************************
Notre application tourne sur un serveur 2000 Pro avec 4 processeurs en
hyperthreading (donc 4 virtuels en plus).
De plus, elle est utilis=E9e en TSE par une 50aine d'utilisateurs.

Suite =E0 des erreurs 1020 intempestives lors de l'utilisation de
traitements assez lourds (requ=EAtes dynamiques, gros fichiers et
jointures), et apr=E8s recherche sur le net des diff=E9rentes solutions
propos=E9es, nous avons tent=E9 le code suivant =E0 l'initialisation du
projet, code qui permettrait de d=E9sactiver le multithreading :

hInstance est un entier =3D API("KERNEL32","GetCurrentProcess")
dwProcessAffinityMask est un entier =3D 1
API("KERNEL32","SetProcessAffinityMask",hInstance,dwProcessAffinityMask)


Les erreurs 1020 ont automatiquement disparu (nous pouvions les
reproduire sans probl=E8me), mais le serveur n'a pas tenu la journ=E9e :
tr=E8s fort ralentissement puis blocage.

Nous avons donc du enlever ce code, et les erreurs 1020 ont r=E9apparu.
**********************************

Nous avons d=E9sormais d=E9sactiv=E9 l'hyperthreading directement au
niveau du serveur (bios).
Les erreurs 1020 sont toujours l=E0.=20

H=2EE.L.P. :-)

3 réponses

Avatar
mat
Loïc wrote:

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
Avatar
mat
mat wrote:
...
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.
Avatar
DAIREAUX Jean-Baptiste
"Loïc" a écrit dans le message de
news:
Bonjour,

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. :-)

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.