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.
Quelqu'un aurait il une id=E9e, une solution, un commentaire ?
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 ;-)
Bonjour,
"Loïc" <antignac.l@logirep.fr> writes:
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
;-)
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
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 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
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
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
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.
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
"Loïc" writes:
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 ;-)
"Loïc" <antignac.l@logirep.fr> writes:
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
;-)
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
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
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).
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
"Loïc" writes:
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 ;-)
"Loïc" <antignac.l@logirep.fr> writes:
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
;-)
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
salut,
concernant l'hyperthreading, voici un article paru sur zdnet :
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
salut,
concernant l'hyperthreading, voici un article paru sur zdnet :
"Loïc" <antignac.l@logirep.fr> a écrit dans le message de news:
1136457640.324829.34720@g47g2000cwa.googlegroups.com...
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 ?
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
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. :-)
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. :-)
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
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. :-)
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. :-)
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
"Loïc" writes:
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 ;-)
"Loïc" <antignac.l@logirep.fr> writes:
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
;-)
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 ;-)
