Sur un réseau constitué des 5 postes en xp SP3 (TPV Toshiba-TEC STA10)
avec un poste "serveur" (pc bureautique XP SP3)
De façon aléatoire (une à deux fois par jour maximum et pas tous les
jours) mon application se fige. En analysant les logs (dbactivelog) il
s'avère que la fonction hajoute(monficher,hblocageecriture) rends la
main au bout de 1 minutes 30 au lieu de quelques millisecondes. Vu que
je tente cet ajout plusieurs fois avant de déclencher une erreur, cela
provoque un gros blocage (qui oblige à redémarrer un ou plusieurs poste)
Une fois le poste qui provoque le ralentissement éteint, l'application
recommence à fonctionner sur les autres postes (encore faut-il savoir
lequel est incriminé et le redémarrer en 1er)
Je viens de terminer de migrer mon application en client serveur afin de
résoudre le problème si celui-ci est lié au mode classic mais j'aurais
aimé etre sur de la cause du problème avant de passer en C/S.
L'application en elle même est utilisée à plusieurs milliers
d'exemplaire (8000 postes environ) en classic et c'est la 1ere fois que
nous rencontrons le problème.
Il y avait des problèmes d'index corrompu sur le site mais le câblage a
été entièrement refait et depuis plus de problèmes de ce type.
Auriez vous un retour sur ce type de problème ?
Nous allons tenter de provoquer l'erreur en surchargeant le réseau (qui
ne l'est pas en situation normale) et de monitorer le réseau avec wireshark.
Je suis preneur de tout idée qui me permettrait de mettre le doigt sur
la cause de ce ralentissement.
Dernière info, le site étant isolé (pas d'internet et pas de lecteur de
disque / Cd) il n'y a pas d'antivirus actif.
Le Thu, 27 Oct 2011 14:55:51 +0200, Fredo a écrit:
Le 27/10/2011 09:56, tt a écrit :
[...]
Je dois avoir dans mes notes, quelque part, des choses à faire sur les répertoires partagés des fichiers de données WD (notamment sur les Optimistic Locks du protocole SMB) . Si cela t'intéresse, je peux le rechercher.
Salut,
Merci pour ce post, effectivement, le problèmes des oplocks m'est ve nu a l'esprit et j'ai fait les modifications en question dans les bases de registre.
Néanmoins de mémoire, c'était plus dans le cas d'environnement disparates (xp/95 + NT) et dans mon cas tous les postes sont en XP SP3 et les sympthomes étaient une moultitude d'index corrompus.
Bon dev,
Fred.
Nous l'avons eu avec des postes tous sous XP avec un serveur sous linux (samba). -- TT
Le Thu, 27 Oct 2011 14:55:51 +0200, Fredo <Fredo@gb-informatique.com> a
écrit:
Le 27/10/2011 09:56, tt a écrit :
[...]
Je dois avoir dans mes notes, quelque part, des choses à faire sur les
répertoires partagés des fichiers
de données WD (notamment sur les Optimistic Locks du protocole SMB) . Si
cela t'intéresse, je peux le rechercher.
Salut,
Merci pour ce post, effectivement, le problèmes des oplocks m'est ve nu a
l'esprit et j'ai fait les modifications en question dans les bases de
registre.
Néanmoins de mémoire, c'était plus dans le cas d'environnement
disparates (xp/95 + NT) et dans mon cas tous les postes sont en XP SP3
et les sympthomes étaient une moultitude d'index corrompus.
Bon dev,
Fred.
Nous l'avons eu avec des postes tous sous XP avec un serveur sous linux
(samba).
--
TT
Le Thu, 27 Oct 2011 14:55:51 +0200, Fredo a écrit:
Le 27/10/2011 09:56, tt a écrit :
[...]
Je dois avoir dans mes notes, quelque part, des choses à faire sur les répertoires partagés des fichiers de données WD (notamment sur les Optimistic Locks du protocole SMB) . Si cela t'intéresse, je peux le rechercher.
Salut,
Merci pour ce post, effectivement, le problèmes des oplocks m'est ve nu a l'esprit et j'ai fait les modifications en question dans les bases de registre.
Néanmoins de mémoire, c'était plus dans le cas d'environnement disparates (xp/95 + NT) et dans mon cas tous les postes sont en XP SP3 et les sympthomes étaient une moultitude d'index corrompus.
Bon dev,
Fred.
Nous l'avons eu avec des postes tous sous XP avec un serveur sous linux (samba). -- TT
Fredo
Le 27/10/2011 17:20, Emmanuel Haefelé a écrit :
"Fredo" a écrit
[Joke] Une autre piste que je n'ai pas évoqué ... que notre logiciel habitué au climat provençal de sa conception ne supporte pas le climat alsacien (Client à Brumath) [/Joke]
C'est effectivement une éventualité à ne surtout pas négliger ;)
Bonne chance.
Emmanuel Haefelé.
Bon,
Le client/serveur a supporté le climat Alsacien et il n'y a eu aucun blocage ce week-end ( 2 soirées à plus de 1000 clients et 1 soirée à 900 clients)
Après avoir discuté la chose avec des collègues développeurs, la piste la plus sérieuse serait pour moi le switch d'entrée de gamme. J'ai proposé au revendeur de le remplacer par un HP ou un Cisco.
En tout cas, la solution C/S a permis de passer par dessus le problème mais sans le corriger pour autant. On va essayer au cours de semaines qui viennent de trouver la cause ... au cas ou.
Bon dev,
Fred
Le 27/10/2011 17:20, Emmanuel Haefelé a écrit :
"Fredo" <Fredo@gb-informatique.com> a écrit
[Joke]
Une autre piste que je n'ai pas évoqué ... que notre logiciel habitué au
climat provençal de sa conception ne supporte pas le climat alsacien
(Client à Brumath)
[/Joke]
C'est effectivement une éventualité à ne surtout pas négliger ;)
Bonne chance.
Emmanuel Haefelé.
Bon,
Le client/serveur a supporté le climat Alsacien et il n'y a eu aucun
blocage ce week-end ( 2 soirées à plus de 1000 clients et 1 soirée à 900
clients)
Après avoir discuté la chose avec des collègues développeurs, la piste
la plus sérieuse serait pour moi le switch d'entrée de gamme. J'ai
proposé au revendeur de le remplacer par un HP ou un Cisco.
En tout cas, la solution C/S a permis de passer par dessus le problème
mais sans le corriger pour autant. On va essayer au cours de semaines
qui viennent de trouver la cause ... au cas ou.
[Joke] Une autre piste que je n'ai pas évoqué ... que notre logiciel habitué au climat provençal de sa conception ne supporte pas le climat alsacien (Client à Brumath) [/Joke]
C'est effectivement une éventualité à ne surtout pas négliger ;)
Bonne chance.
Emmanuel Haefelé.
Bon,
Le client/serveur a supporté le climat Alsacien et il n'y a eu aucun blocage ce week-end ( 2 soirées à plus de 1000 clients et 1 soirée à 900 clients)
Après avoir discuté la chose avec des collègues développeurs, la piste la plus sérieuse serait pour moi le switch d'entrée de gamme. J'ai proposé au revendeur de le remplacer par un HP ou un Cisco.
En tout cas, la solution C/S a permis de passer par dessus le problème mais sans le corriger pour autant. On va essayer au cours de semaines qui viennent de trouver la cause ... au cas ou.
Bon dev,
Fred
phig
Le 27/10/2011 16:58, Fredo a écrit :
Le 27/10/2011 15:59, Emmanuel Haefelé a écrit :
"Fredo" a écrit
En attendant, j'ai effectué les modifications nécessaires dans mon projet afin de pouvoir travailler en client serveur et le même test (chez le client) en mode client/serveur a été concluant (impossible de provoquer le blocage à nouveau)
Ca c'est déjà une bonne nouvelle.
Je m'orienterais donc sur un problème réseau mais lequel ... drivers, câblage, switch ... j'aurais bien aimé savoir.
Je ne voudrais pas t'orienter dans une mauvaise direction car à te lire il est quand même assez difficile de déterminer si c'est un conflit d'accès ou un problème réseau. Concernant ce dernier problème je n'y connais pas grand chose mais je dirais, cablage ou drivers, si c'est toujours le même TPV qui est en cause (même si ça peut aussi être le cable entre le switch et le serveur et donc concerner tous les postes). Pour le reste c'est plus délicat, je pense qu'idéalement il faudrait commencer par remplacer le switch et voir ce que ça donne.
Ceci étant dit, si ça à l'air de fonctionner en C/S à ta place je commencerais déjà par voir pendant un certain temps ce que ça donne dans cette configuration et ensuite j'aviserai.
En tout état de cause, le test en situation réelle se fera ce week-end car le client attends une très forte affluence dans son établissement.
Je posterais le résultat lundi matin :)
salut. j'ai vu que tu avais résolu ton pb, mais il y a une piste qui n'a pas été évoquée: le parefeu de windows....
Nous utilisons ici des switch Dlink niveau II sur un reseau _très_ chargé sans problème notable (vlan,téléphonie sur ip,imagerie,40 postes mais en HF/CS).
Le 27/10/2011 16:58, Fredo a écrit :
Le 27/10/2011 15:59, Emmanuel Haefelé a écrit :
"Fredo" <Fredo@gb-informatique.com> a écrit
En attendant, j'ai effectué les modifications nécessaires dans mon
projet afin de pouvoir travailler en client serveur et le même test
(chez le client) en mode client/serveur a été concluant (impossible de
provoquer le blocage à nouveau)
Ca c'est déjà une bonne nouvelle.
Je m'orienterais donc sur un problème réseau mais lequel ... drivers,
câblage, switch ... j'aurais bien aimé savoir.
Je ne voudrais pas t'orienter dans une mauvaise direction car à te
lire il
est quand même assez difficile de déterminer si c'est un conflit d'accès
ou un problème réseau. Concernant ce dernier problème je n'y connais pas
grand chose mais je dirais, cablage ou drivers, si c'est toujours le
même TPV qui est en cause (même si ça peut aussi être le cable entre le
switch et le serveur et donc concerner tous les postes). Pour le reste
c'est plus délicat, je pense qu'idéalement il faudrait commencer par
remplacer le switch et voir ce que ça donne.
Ceci étant dit, si ça à l'air de fonctionner en C/S à ta place je
commencerais déjà par voir pendant un certain temps ce que ça donne dans
cette configuration et ensuite j'aviserai.
En tout état de cause, le test en situation réelle se fera ce week-end
car le client attends une très forte affluence dans son établissement.
Je posterais le résultat lundi matin :)
salut.
j'ai vu que tu avais résolu ton pb, mais il y a une piste qui n'a pas
été évoquée: le parefeu de windows....
Nous utilisons ici des switch Dlink niveau II sur un reseau _très_
chargé sans problème notable (vlan,téléphonie sur ip,imagerie,40 postes
mais en HF/CS).
En attendant, j'ai effectué les modifications nécessaires dans mon projet afin de pouvoir travailler en client serveur et le même test (chez le client) en mode client/serveur a été concluant (impossible de provoquer le blocage à nouveau)
Ca c'est déjà une bonne nouvelle.
Je m'orienterais donc sur un problème réseau mais lequel ... drivers, câblage, switch ... j'aurais bien aimé savoir.
Je ne voudrais pas t'orienter dans une mauvaise direction car à te lire il est quand même assez difficile de déterminer si c'est un conflit d'accès ou un problème réseau. Concernant ce dernier problème je n'y connais pas grand chose mais je dirais, cablage ou drivers, si c'est toujours le même TPV qui est en cause (même si ça peut aussi être le cable entre le switch et le serveur et donc concerner tous les postes). Pour le reste c'est plus délicat, je pense qu'idéalement il faudrait commencer par remplacer le switch et voir ce que ça donne.
Ceci étant dit, si ça à l'air de fonctionner en C/S à ta place je commencerais déjà par voir pendant un certain temps ce que ça donne dans cette configuration et ensuite j'aviserai.
En tout état de cause, le test en situation réelle se fera ce week-end car le client attends une très forte affluence dans son établissement.
Je posterais le résultat lundi matin :)
salut. j'ai vu que tu avais résolu ton pb, mais il y a une piste qui n'a pas été évoquée: le parefeu de windows....
Nous utilisons ici des switch Dlink niveau II sur un reseau _très_ chargé sans problème notable (vlan,téléphonie sur ip,imagerie,40 postes mais en HF/CS).
Fredo
Le 02/11/2011 13:48, phig a écrit :
Le 27/10/2011 16:58, Fredo a écrit :
Le 27/10/2011 15:59, Emmanuel Haefelé a écrit :
"Fredo" a écrit
En attendant, j'ai effectué les modifications nécessaires dans mon projet afin de pouvoir travailler en client serveur et le même test (chez le client) en mode client/serveur a été concluant (impossible de provoquer le blocage à nouveau)
Ca c'est déjà une bonne nouvelle.
Je m'orienterais donc sur un problème réseau mais lequel ... drivers, câblage, switch ... j'aurais bien aimé savoir.
Je ne voudrais pas t'orienter dans une mauvaise direction car à te lire il est quand même assez difficile de déterminer si c'est un conflit d'accès ou un problème réseau. Concernant ce dernier problème je n'y connais pas grand chose mais je dirais, cablage ou drivers, si c'est toujours le même TPV qui est en cause (même si ça peut aussi être le cable entre le switch et le serveur et donc concerner tous les postes). Pour le reste c'est plus délicat, je pense qu'idéalement il faudrait commencer par remplacer le switch et voir ce que ça donne.
Ceci étant dit, si ça à l'air de fonctionner en C/S à ta place je commencerais déjà par voir pendant un certain temps ce que ça donne dans cette configuration et ensuite j'aviserai.
En tout état de cause, le test en situation réelle se fera ce week-end car le client attends une très forte affluence dans son établissement.
Je posterais le résultat lundi matin :)
salut. j'ai vu que tu avais résolu ton pb, mais il y a une piste qui n'a pas été évoquée: le parefeu de windows....
Nous utilisons ici des switch Dlink niveau II sur un reseau _très_ chargé sans problème notable (vlan,téléphonie sur ip,imagerie,40 postes mais en HF/CS).
Salut,
Excuse moi si je te parais obtus mais que viens faire le parefeu windows sur un réseau local et en HF Classic ? Je viens néanmoins de vérifier, les TPV n'étant pas connectés au NET, le parefeu a été désactivé.
Pour ce qui est du switch je me trompe peut être (et ces marques ont peut être fait des progrès) mais j'ai plus souvent eu des problèmes dus à cette gamme de switch (DLink, TrendNet, ...) qu'avec des matériel catégorisé comme étant plus haut de gamme. En tout cas, on va refaire un test avec un switch HP et on verra.
Bon dev,
Fred.
Le 02/11/2011 13:48, phig a écrit :
Le 27/10/2011 16:58, Fredo a écrit :
Le 27/10/2011 15:59, Emmanuel Haefelé a écrit :
"Fredo" <Fredo@gb-informatique.com> a écrit
En attendant, j'ai effectué les modifications nécessaires dans mon
projet afin de pouvoir travailler en client serveur et le même test
(chez le client) en mode client/serveur a été concluant (impossible de
provoquer le blocage à nouveau)
Ca c'est déjà une bonne nouvelle.
Je m'orienterais donc sur un problème réseau mais lequel ... drivers,
câblage, switch ... j'aurais bien aimé savoir.
Je ne voudrais pas t'orienter dans une mauvaise direction car à te
lire il
est quand même assez difficile de déterminer si c'est un conflit d'accès
ou un problème réseau. Concernant ce dernier problème je n'y connais pas
grand chose mais je dirais, cablage ou drivers, si c'est toujours le
même TPV qui est en cause (même si ça peut aussi être le cable entre le
switch et le serveur et donc concerner tous les postes). Pour le reste
c'est plus délicat, je pense qu'idéalement il faudrait commencer par
remplacer le switch et voir ce que ça donne.
Ceci étant dit, si ça à l'air de fonctionner en C/S à ta place je
commencerais déjà par voir pendant un certain temps ce que ça donne dans
cette configuration et ensuite j'aviserai.
En tout état de cause, le test en situation réelle se fera ce week-end
car le client attends une très forte affluence dans son établissement.
Je posterais le résultat lundi matin :)
salut.
j'ai vu que tu avais résolu ton pb, mais il y a une piste qui n'a pas
été évoquée: le parefeu de windows....
Nous utilisons ici des switch Dlink niveau II sur un reseau _très_
chargé sans problème notable (vlan,téléphonie sur ip,imagerie,40 postes
mais en HF/CS).
Salut,
Excuse moi si je te parais obtus mais que viens faire le parefeu windows
sur un réseau local et en HF Classic ? Je viens néanmoins de vérifier,
les TPV n'étant pas connectés au NET, le parefeu a été désactivé.
Pour ce qui est du switch je me trompe peut être (et ces marques ont
peut être fait des progrès) mais j'ai plus souvent eu des problèmes dus
à cette gamme de switch (DLink, TrendNet, ...) qu'avec des matériel
catégorisé comme étant plus haut de gamme. En tout cas, on va refaire un
test avec un switch HP et on verra.
En attendant, j'ai effectué les modifications nécessaires dans mon projet afin de pouvoir travailler en client serveur et le même test (chez le client) en mode client/serveur a été concluant (impossible de provoquer le blocage à nouveau)
Ca c'est déjà une bonne nouvelle.
Je m'orienterais donc sur un problème réseau mais lequel ... drivers, câblage, switch ... j'aurais bien aimé savoir.
Je ne voudrais pas t'orienter dans une mauvaise direction car à te lire il est quand même assez difficile de déterminer si c'est un conflit d'accès ou un problème réseau. Concernant ce dernier problème je n'y connais pas grand chose mais je dirais, cablage ou drivers, si c'est toujours le même TPV qui est en cause (même si ça peut aussi être le cable entre le switch et le serveur et donc concerner tous les postes). Pour le reste c'est plus délicat, je pense qu'idéalement il faudrait commencer par remplacer le switch et voir ce que ça donne.
Ceci étant dit, si ça à l'air de fonctionner en C/S à ta place je commencerais déjà par voir pendant un certain temps ce que ça donne dans cette configuration et ensuite j'aviserai.
En tout état de cause, le test en situation réelle se fera ce week-end car le client attends une très forte affluence dans son établissement.
Je posterais le résultat lundi matin :)
salut. j'ai vu que tu avais résolu ton pb, mais il y a une piste qui n'a pas été évoquée: le parefeu de windows....
Nous utilisons ici des switch Dlink niveau II sur un reseau _très_ chargé sans problème notable (vlan,téléphonie sur ip,imagerie,40 postes mais en HF/CS).
Salut,
Excuse moi si je te parais obtus mais que viens faire le parefeu windows sur un réseau local et en HF Classic ? Je viens néanmoins de vérifier, les TPV n'étant pas connectés au NET, le parefeu a été désactivé.
Pour ce qui est du switch je me trompe peut être (et ces marques ont peut être fait des progrès) mais j'ai plus souvent eu des problèmes dus à cette gamme de switch (DLink, TrendNet, ...) qu'avec des matériel catégorisé comme étant plus haut de gamme. En tout cas, on va refaire un test avec un switch HP et on verra.
