ERREUR 1020 Multithreading

Le
Loïc
Bonjour,

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

Suite des erreurs 1020 intempestives lors de l'utilisation de
traitements assez lourds (requtes dynamiques, gros fichiers et
jointures), et aprs recherche sur le net des diffrentes solutions
proposes, nous avons tent le code suivant l'initialisation du
projet, code qui permettrait de dsactiver 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 problme), mais le serveur n'a pas tenu la journe :
trs fort ralentissement puis blocage.

Nous avons donc du enlever ce code, et les erreurs 1020 ont rapparu.

Quelqu'un aurait il une ide, une solution, un commentaire ?

Merci
  • Partager ce contenu :
Vos réponses Page 1 / 2
Trier par : date / pertinence
Daniel
Le #14210091
Bonjour,
"Loïc"
Bonjour,

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.

Quelqu'un aurait il une idée, une solution, un commentaire ?



Si ce n'est pas le cas, déporter la base sur un serveur de donnée, dans
ce cas tu vas diminuer la charge sur ton serveur d'application TSE.

Sinon, passer en solution client/serveur classique c'est à dire sans
TSE...
Enfin tout dépend de la base que tu attaques si c'est du HF tu
oublies.

De toute façon tu n'as pas 50 solutions, si tu as mis en place un
serveur avec 4 proc en HT et que Windev ne sait pas les gérer sans
plantage, il faut que les traitements "lourd" soit fait sur les postes
clients. iL faut donc délocaliser... ...les traitements.


Un commentaire?
Celà fait 4 ans, que Intel propose de l'HT, qu'une version de WD
sortie avant ne fonctionne pas correctement passe encore, mais ce ne
sera pas acceptable avec WD10.



--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Christophe Charron
Le #14210061
Loïc a écrit :
Bonjour,

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.

Quelqu'un aurait il une idée, une solution, un commentaire ?

Merci



Bonjour,
en quelle version ètes-vous ? Il me semble avoir lu, certainement en
face, que ces erreurs ont disparu avec la version 10 ... ???

--
Cordialement
Christophe Charron

PROLOGIQ
7 bis Rue des Aulnes
69410 Champagne au Mont d'Or

Tel : 0 437 499 107
Fax : 0 437 499 105
mailto:
Loïc
Le #14210051
Nous travaillons sous windev 9, et base de données propriétaire Hyper
File.
Attendre la version 10 mouai ...
Travaillant depuis 9 ans sous windev (depuis la 2.1), je commence à
être lassé d'entendre le même discours concernant les bugs
importants : "la nouvelle version va les résoudre ... "
ça me rappelle un autre produit avec le même type de marketing ...
:-)

Quant au multithreading, j'ai pu recenser pas mal d'articles expliquant
que le problème existe avec d'autres outils que Windev.

C'est pourquoi je cherchais un moyen de le désactiver.

Amicalement bien entendu,

Loïc
Daniel
Le #14210041
"Loïc"
Nous travaillons sous windev 9, et base de données propriétaire Hyper
File.



en hf classic ou c/s?

pour rappel un serveur TSE est à utiliser comme serveur d'application,
qui attaquera un serveur de donnée.

Windev a des limites comme tout outil et il est d'autant plus
nécessaire d'en tenir compte dans une architecture tel que la votre :
- application gourmande en mémoire et CPU ( on est dans de
l'interprèté).
- fuite de mémoire
- non gestion de l'HT
- base de donnée fichier (HF classic)
- accès base non optimisée par les commandes H* (sauf pour HF c'est
normal c'est le client qui fait tout le boulot)


Sur les 3 premiers points on ne peut pas y faire grand chose,
parcontre si vous délocaliser le problème de charge des données sur le
serveur de donnée en utilisant un SGBDR qui tient la route, et que
vous faites un maximum en SQL avec des procédures stockées, vous allez
pas mal gagner...

Oui, c'est vrai il faut probablement repenser le MCD et le MPD, et
envisager le SQL si ce n'est pas déjà fait, mais vous y gagnerez sur
tous les points, et peut être même en oubliant la couche TSE.




Attendre la version 10 mouai ...
Travaillant depuis 9 ans sous windev (depuis la 2.1), je commence à
être lassé d'entendre le même discours concernant les bugs
importants : "la nouvelle version va les résoudre ... "
ça me rappelle un autre produit avec le même type de marketing ...
:-)

Quant au multithreading, j'ai pu recenser pas mal d'articles expliquant
que le problème existe avec d'autres outils que Windev.

C'est pourquoi je cherchais un moyen de le désactiver.




--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
mat
Le #14210031
Loïc wrote:
Bonjour,

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.



Bonjour,

4 processeurs c'est déjà pas mal. Avez-vous fait des tests en
désactivant HT dans le BIOS? Je l'ai fait sur certaines machines et n'ai
pas remarqué un abaissement de la vitesse de traitement (postes de
travail, pas de serveurs).

Salutations
Mat
Daniel
Le #14210021
"Loïc"
Nous travaillons sous windev 9, et base de données propriétaire Hyper
File. Attendre la version 10 mouai ... Travaillant depuis 9 ans sous
windev (depuis la 2.1), je commence à être lassé d'entendre le mê me
discours concernant les bugs importants : "la nouvelle version va les
résoudre ... " ça me rappelle un autre produit avec le même type de
marketing ... :-)

Quant au multithreading, j'ai pu recenser pas mal d'articles
expliquant que le problème existe avec d'autres outils que Windev.

C'est pourquoi je cherchais un moyen de le désactiver.

Amicalement bien entendu,

Loïc




Mince j'avais oublié un truc qui pourrait être intéressant dans ton
cas c'est le ntiers qui est prévu dans la version 10, dans ce cas tu
pourrais mieux controler ton application.

Sinon, tu as Citrix ( avec une ferme de serveur) celà devrait être
bon.
Mais je maintiens mon idée initial TSE n'est pas la solution a tout et
une bonne appli avec une bonne base client/serveur fera
l'affaire. Gros avantage d'un serveur TSE c'est que lors d'une mise à
jour il n'y a que sur le serveur qu'on réinstalle...

--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Adrien
Le #14209911
salut,

concernant l'hyperthreading, voici un article paru sur zdnet :

http://www.zdnet.fr/actualites/informatique/0,39040745,39289582,00.htm

A+

"Loïc"
Bonjour,

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.

Quelqu'un aurait il une idée, une solution, un commentaire ?

Merci
Loïc
Le #14209811
Merci pour vos réponses.
Le souci, c'est qu'il n'est pas vraiment possible de faire accepter à
la direction ce type de changements alors que l'application se termine
suite à 3 ans de développement. De la même manière,
l'administrateur réseau n'accepte pas de prendre le risque de
désactiver l'hyperthreading au niveau du serveur, et c'est la raison
pour laquelle on avait tenté de biaiser par programmation. Nous
travaillons en Hyper File classique parce qu'imposé par la DSI. Chose
que je déconseille depuis pas mal d'année, considérant Windev comme
un très bon produit, mais Hyper File trop limité, sauf pour les
petites applis ... Donc, en gros, on est pas mal limités sur le plan
décisionnel, à part si l'on apporte les preuves concernant l'origine
des problèmes. :-)
Loïc
Le #14209801
Merci pour vos réponses.
Le souci, c'est qu'il n'est pas vraiment possible de faire accepter à
la direction ce type de changements alors que l'application se termine
suite à 3 ans de développement. De la même manière,
l'administrateur réseau n'accepte pas de prendre le risque de
désactiver l'hyperthreading au niveau du serveur, et c'est la raison
pour laquelle on avait tenté de biaiser par programmation. Nous
travaillons en Hyper File classique parce qu'imposé par la DSI. Chose
que je déconseille depuis pas mal d'année, considérant Windev comme
un très bon produit, mais Hyper File trop limité, sauf pour les
petites applis ... Donc, en gros, on est pas mal limités sur le plan
décisionnel, à part si l'on apporte les preuves concernant l'origine
des problèmes. :-)
Daniel
Le #14209721
"Loïc"
Merci pour vos réponses.
Le souci, c'est qu'il n'est pas vraiment possible de faire accepter à
la direction ce type de changements alors que l'application se termine
suite à 3 ans de développement.





De la même manière,
l'administrateur réseau n'accepte pas de prendre le risque de
désactiver l'hyperthreading au niveau du serveur, et c'est la raison
pour laquelle on avait tenté de biaiser par programmation.


Ce qui est une bonne solution car dans ce cas ne concerne que ton appli.

Nous
travaillons en Hyper File classique parce qu'imposé par la DSI.


Mince...

Chose
que je déconseille depuis pas mal d'année, considérant Windev comme
un très bon produit,


idem

mais Hyper File trop limité, sauf pour les
petites applis ...


idem

Donc, en gros, on est pas mal limités sur le plan
décisionnel, à part si l'on apporte les preuves concernant l'origine
des problèmes. :-)



Tu as déjà une partie des éléments, l'appli ne fonctionne pas
correctement en HF classique sous TSE... Dans 5 ans que se passera
t-il?

Si la DSI pour des raisons obscures t'impose l'architecture, et la base
qu'elle prenne ses responsabilités!



--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Poster une réponse
Anonyme