[WD14] Hajoute qui rends la main après 1m30
Le
Fredo
Bonjour,
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.
Merci d'avance,
Fred
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.
Merci d'avance,
Fred
Bonjour Fredo,
Est-ce que l'option hblocageecriture est vraiment nécessaire, tu veux
maintenir l'enregistrement bloqué après l'ajout ?
Mono-postes pour la plupart ou plutôt multi-postes ?
Nous n'utilisons jamais l'option hblocageecriture sur la fonction hajoute
et généralement avec ce type de problème chez nous hAjoute rend la main.
Est-ce que tu testes le resultat de hajoute et s'il n'y arrive pas tu
retentes ?
Cordialement,
Emmanuel Haefelé.
[...]
Bonjour,
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). S i
cela t'intéresse, je peux le rechercher.
--
TT
En relisant ton mail, tu indiques que hajoute te rend la main au bout d'1
minute 30, je suppose donc que tu n'as pas une gestion personalisée des
blocages comme chez nous. Donc on pourrait en conclure qu'effectivement ça
pourrait encore être un problème de cablage. Si ce contexte est avéré,
passer en mode C/S pourrait donc régler certains problèmes mais sans doute
pas la totalité. Tu n'auras plus de blocage mais sans doute d'autres
erreurs liées à la communication entre le serveur et le poste.
Cordialement,
Emmanuel Haefelé.
Ton problème m'intéresse, j'ai fait quelques recherches dans mes logs car
de notre côté nous traçons ce genre d'erreur. Déjà elles sont très rare
mais que ce soit en classic ou en C/S nous avons malgré tout ces erreurs
que nous appellons chez nous des erreurs de time out. Donc ce que je t'ai
dit plus haut n'est peut-être pas tout à fait exact même si nous
constatons qu'il y en a plus en classic qu'en C/S.
Voila ce que je peux te dire, donc si c'est ça il faut regarder du côté
des cartes réseaux, switch ou du cablage. Mais regarde quand même si
l'option hblocageecriture est vraiment nécessaire dans ton contexte, ça me
parait un peu particulier.
Cordialement,
Emmanuel Haefelé.
Salut et merci pour tes remarques,
Pour ce qui est de nos install, nous avons environ 50% de monopostes et
50% de réseau (de 3 à 20 postes, peu de 20 :)
Sur le site en question, il y a en utilisation "normale" peu de traffic,
les utilisateurs sont speed, mais en terme informatique, le réseau est
peu sollicité (nous avons des sites beaucoup plus important et beaucoup
plus actifs)
Ce que nous avons fait : Installer sur un des TPV une boucle qui génère
des enregistrements sur le même principe que celui que nous utilisons
"en vrai" .. blocage d'un enregistrement pour être sur d'être seul à
écrire à un instant T, écriture de notre facture, déblocage de
l'enregistrement qui fait office de sémaphore (d'ou le hajoute en
blocage écriture)
"Grâce" à cette boucle qui génère en 1 minute plus de facture que les
utilisateurs en 30 minutes, nous avons réussi à provoquer un blocage.
L'enregistrement du traffic réseau par WireShark ne m'a pas donné grand
chose mis à part une trame TCP/IP (SMB) de demande de blocage qui est a
priori retransmise ... après 1m30 (par contre entre la 1ere transmission
et la retransmission, j'ai quand même des trames entre la caisse en
question et le serveur.) Pour provoquer le blocage, il a fallut la
boucle et que deux utilisateurs "synchronisent" leur enregistrement.
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)
Je m'orienterais donc sur un problème réseau mais lequel ... drivers,
câblage, switch ... j'aurais bien aimé savoir.
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 :)
Merci encore,
Fred.
Salut,
Merci pour ce post, effectivement, le problèmes des oplocks m'est venu 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.
Ca c'est déjà une bonne nouvelle.
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.
Ok, c'est toujours intéressant. Et si ça se reproduit à l'avenir, tiens
nous au courant on finira bien par trouver ...
Cordialement,
Emmanuel Haefelé.
[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]
Effectivement, le switch est un dlink ... j'aurais préféré un Cisco ou
un HP mais bon ... ce n'est pas moi qui fournis le matos.
Merci encore,
Fred.
C'est effectivement une éventualité à ne surtout pas négliger ;)
Bonne chance.
Emmanuel Haefelé.
J'ai un problème similaire sur un gros fichier (avec un index tellement
gros que j'ai du activer l'extension >2go)
Le premier hlittrecherchepremier mais un temps tellement important qu'il
arrive que mon watchdog termine le programme.
Au relancement suivant, ca refonctionne
comme si, HF vérifiait les index au premier acces
(et du coup, ca rame au premier coup, et après c'est dans le cache du
disque dur)
Le 27/10/2011 09:02, Fredo a écrit :