Discussion :

[Bowen]

Bonjour,

Je m'en remets à vous car j'ai beau tenter de résoudre mon bug avec PC-Soft, rien n'avance depuis près d'un mois et d'une dizaine de mails.

J'ai régulièrement et aléatoirement deux bugs sur le moteur HF.

1. Le moteur Manta.exe se plante, entrainant une écriture dans l'observateur d'évènements Windows
2. Des lignes de la base de données sont dupliquées

Ces deux bugs n'arrivent pas au même moment, mais je pense qu'il ont une cause commune car lorsque je débranche le plus gourmand de mes programmes, les deux problèmes disparaissent.

Lors du plantage du manta.exe, le journal des évènements m'affiche ces erreurs :

Tables non libérées en fermeture de session

Application défaillante Manta.exe, version 15.0.1.400, horodatage 0x4b55e3b6, module défaillant ntdll.dll, version 6.0.6001.18000, horodatage 0x4791a7a6, code d’exception 0xc0000005, décalage d’erreur 0x00043387, ID du processus 0x140c, heure de début de l’application 0x01cb0bac51c9b5fc.

Echec du chargement du serveur HyperFileSQL.
Erreur: Que s'est-il passé ?
Impossible d'ouvrir le fichier <__System\UserTable.FIC>.

Code erreur : 70150
Niveau : erreur fatale (EL_FATAL)
Code erreur WD55 : 150

Code d'erreur système : 32
Message d'erreur système :
Le processus ne peut pas accéder au fichier car ce fichier est utilisé par un autre processus.

Dump de l'erreur du module 'WDHFSRV.DLL' (15.00Ef).
Informations de débogage :
##(IXStream)-Handle=<FFFFFFFF>##
Informations supplémentaires :
EIT_SRCFILE : <__System\UserTable.FIC>
EIT_LOGICALTABLENAME : <UserTable>

Le démarrage du service HyperFile a échoué.
Error=0

Je cherche à isoler le problème de ces plantages.
Je penche pour une surcharge du moteur HF, le moteur ne plantant en effet que lorsqu'un programme travaillant en permanence en tache de fond est lancé. Ce programme ne fait rien de plus compliqué que mon programme principal, mais il le fait en permanence.

L'erreur
Le processus ne peut pas accéder au fichier car ce fichier est utilisé par un autre processus [...] <__System\UserTable.FIC>
me fait également pencher vers cette théorie.

Que pensez-vous de cette théorie?
Sauriez-vous comprendre ce fait planter le moteur HF si régulièrement grâce à ces journaux d'évènements ? ou même seulement me donner une piste ?
(à part bien sur changer de SGBD)

Et merci à ceux qui ont pris le temps de lire ce long post.

[SevenSoftware]

Bonjour,

Si le systeme manque de ressources, vérifiez que vous liberez les ressources
SQL avec des HAnnuleDeclaration.
Ca peut eviter au programme permanent de devenir obèse en mémoire...

C'est juste une piste, peut être que ça n'a rien à voir...

Patrick

[EDM-TAHITI]

Hello,
Commençons par le début, le moteur Manta tourne sur quoi un serveur en 2000/2003/2008? Sur une machine dédié en XP, Vista, Seven??

puis

Dans le paramétrage du moteur Manta (en principe, dans le répertoire d'installation), le fichier HFCONF.INI devrait ressembler un peu à cela:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
[INIT]
DBRootPath=%%EXE%%\BDD // endroit ou se trouve les bases physiques
Name=[NOM DE LA MACHINE]
AccessPort=4900 // port par défaut, voir s'il est ouvert/autorisé systeme
NdxCacheSize=38
MoreThan2Go=1
JNLRootPATH=%%EXE%%\BDD\__JNL // chemin du journal de la BDD
JNLBackupRootPATH=%%EXE%%\BDD\__JNLBackup // backup dudit journal
ServerLogPath=%%EXE%%\Logs // chemin des log, paramétrage utilisateurs (est-ce ici ou ca coince????)
ServerLogLevel=WL,PARAM
LogConnexion=0
ServerLogMaxFileSize=100
ServerLogMaxFiles=3
PerformacePath=%%EXE%%\Perf
PerformanceMaxFileSize=100
PerformacePeriod=0
ServerLogLevels=
ServerLogMaxSize=300
ActivityStatisticMaxFileSize=500
ActivityStatisticPath=%%EXE%%\ActivityStatistics
ActivityStatisticPeriod=3

L'erreur que tu as, je ne l'ai jamais rencontrée, donc, j'y vais avec douceur pour comprendre.

Enfin, la table recherchée, à savoir, usertable.fic est la table de paramétrage des accès utilisateurs du moteur Manta. Cete table se trouve à l'endroit, par défaut

[Disque+Répertoire installation]\BDD\__SYSTEM\[TOUTES LES TABLES DE PARAMETRAGES]

Si tu n'as pas l'une de ces tables, ca part en cacahuètes, je viens de faire le test.

Enfin, ne relances-tu pas ton serveur depuis le poste, par une commande de type

HDEMARRESERVEUR([NOMDUSERVEUR],[PORTDUSERVEUR])

Au pire des cas, mais cela ne répond pas, je le sais, à ta problèmatique, pour le moment, essayes de créer un utilisateurs ayant les même pouvoir que l'admin par défaut qui est créée et reagrde si cela change la stabilité du moteur.

Tu peux faire tout cela dans le centre de contrôle...

A te lire sur le sujet....

[Bowen]

La config matérielle, c'est un serveur dédié HF, deux serveurs frontaux de 15 utilisateurs TSE (une même appli déposée sur chaque serveur), 10 PDA connectés sur la BDD en permanence, et deux applications effectuant des extractions/opération permanentes de la base (une envoyant des données à un site web, l'autre effectuant des MAJ sur la base et des envois FTP, pilotée par socket depuis les PDA)
La config des serveurs tient la route, ce sont les trois mêmes :
Serveur Fujitsu/siemens
Win2008/32
Double quad core 2,5Ghz
4 Go Ram
Disques RAID 5, 512 Mo cache, 15 000 tours/min
Bref, une config qui devrait tenir la route, et qui avec n'importe quel autre SGBD donnerai des perfs très raisonnables.

Pour la config du .ini, j'ai du mal à penser au que ça vienne de ça
(mais ça ressemble à ce que tu as mis).

Je pense que je n'ai pas été assez précis dans mon message car le plantage du Manta.exe a lieu environ une fois par jour, si je branche un de mes programmes les plus gourmands, et peu fréquemment quand je ne le branche pas.

Pour l'idée de SevenSoftware, c'est vrai qu'il n'y a pas de HAnnuleDeclaration partout, mais une bonne partie du code est faite, et je n'ai pas vu de différence quand je l'ai fait. Pour moi, la source de données est sensée être détruite lors de la fermeture de l'objet le contenant (ex.: en fermant la fenêtre où elle est déclarée).

[EDM-TAHITI]

Hello,
merci pour toutes ces précisions qui annulent tout ce que j'ai dis (rires).
Bon, alors, à la vue de tes config serveurs, il me semble que le problème tient en deux points, à savoir:
- si comme je le comprend, tous les utilisateurs se connectent en TSE, le noyau de chaque utilisateurs sur le serveur est d'environ 640Ko, et si tu multiplies le nombre d'utilisateurs par 640Ko, tu dépasses tes 4Mo de mémoire, non?
- Lorsque les utilisateurs ferment leur session, es-tu sur qu'ils ferment bien l'appli avant ou reste-t-elle dans la session TSE restée ouverte??? En effet, le fait de fermer une session ne ferme pas les applis qui sont lancées, et ceci peut expliquer cela.

Tu as une belle config, il est vrai, mais je pense que quelque soit la base attaquées, tu aurais, avec plus ou moins de bonheur, des soucis, sinon identique, récurants....

Voilà ce que je peux te dire, mais la piste me semble, vu d'ici, meilleur que ma première intervention... (désolé)

SevenSoftware a mille fois raison de te dire d'annuler les déclarations une fois qu'elles ne seront plus utilisées. C'est à mettre dans la fermeture de la fenetre, ca prend pas beaucoup de temps et evite de grossir la mémoire inutilement.

Mais tiens nous informé en fonction de la montée en charge de tes serveurs. Fais le test avec 5 utilisateurs maxi (noyau de 3.2 Mo), je laisse de la place pour le reste (un peu) et regarde si l'erreur se reproduit. Dans la négative, la piste semblerait être la bonne, sinon, je continuerai à creuser.

Enfin, puique tu es sous 2008serveur (et quelque soit la realse), as-tu regarder du côté paramétrage avec adedit?

En effet, avec l'avénement de 2008, l'encapsulage dans AD et ton OU travaille sur les objets et non plus sur un AD, tu peux par exemple pour les mots de passe gérer des GP par groupe d'utilisateurs....

Et donc, te permettre de gérer en plus les sessions du groupe TSE (que tu as du créer, je pense) et d'éteindre par exemple leur session en fonction des jours et horaires de la semaine... Encore une piste...

Bon, je vais pas en écrire des tonnes, mais tout est piste, et c'est un jeu... de pistes...

[Bowen]

Les utilisateurs sont connectés en TSE oui, mais pas sur le serveur HF. Ce serveur est dédié à la base de données (en fait, il fait également tourner les deux petites applications dont je parlais)
Les connexions TSE se font sur les deux autres serveurs, et les programmes sont lancés à partir de là.
J'ai un switch managable entre ces serveurs, et deux cartes réseau sur chaque. Ce qui me donne un lien 2 Giga entre chaque serveur.

La base de données n'est pas énorme, elle fait 2.2 Go.

Par contre, il y a beaucoup d'accès à la base de données (notamment à cause d'accès récursifs pour des calculs de disponibilités qui doivent rester corrects en permanence et donc recalculés à chaque demande).

Un exemple du volume des accès ?
J'ai activé les logs sur le serveur HF (logs des appels au serveur) et l'analyse de 15 minutes pour cet après-midi, entre 14h45 et 15h me donne 60 000 lignes.

Pour adedit, bien essayé mais il n'y a ni domaine, ni active directory.

[EDM-TAHITI]

Hello
C'est quoi le release du moteur Manta???
cela a son importance car j'ai eu des soucis avec une version en particulier...
A te lire
et désolé pour les fausses pistes, mais j'avais pas les yeux réveillés...

[Bowen]

No pb, c'est déjà bien de filer un coup de main.
Le HF est le dernier serveur en ligne, version 15 (j'ai pas le numéro sous la main).
Les programmes sont tous en 14, dernière version.
Sauf le tout dernier, en 15 dernière version.

[EDM-TAHITI]

Hello,
et je pense aussi aux journaux de W2K8, ils disent quoi, y'a une trace du plantage??? et si oui, ils disent quoi????
et entre les cartes réseaux, tu passes par un switch, administrable? ou un Hub? ou es-tu en crossover sur les câbles?
et as-tu essayé de modifier la négociation des cartes et de passer non pas en autonegociation mais en dur(!) avec un full ou un half duplex??? juste pour savoir???
J'essaye de trouver une explication, mais pas simple! surtout si cela fait un mois que ca dure...

[EDM-TAHITI]

Hello,
un autre truc qui m'est arrivé, y'a pas longtemps, un câble réseau défectueux qui, quand il n'etait pas en charge fonctionnait pas trop mal, mais des lenteurs du poste se faisaient jour, et en revanche, lorsque je mettais à jour l'appli en réseau, il ne voulait rien savoir, il partait en cachuètes...
Et je te dis cela car j'ai plusieurs testeurs qui me disaient que le switch répondait bien, que les liens physiques avec l'apérage etaient ok, mais quand j'ai passe le fluck, il m'a montré que il etait le meilleur.
C'est aussi une autre piste...

[Bowen]

et je pense aussi aux journaux de W2K8, ils disent quoi, y'a une trace du plantage??? et si oui, ils disent quoi????

Les journaux de windows sont dans mon tout premier post, c'est l'observateur des évènements qui les a relevé (section Application)
Pour le problème réseau, j'ai du mal à penser que ça vient de là aussi. Une copie de fichier d'un serveur à l'autre mets par exemple un temps tout à fait raisonnable.

"mais quand j'ai passe le fluck" ???
Qu'est-ce que tu veux dire par là ?

Pour info, le programme qui fait planter quand je le branche n'est pas en réseau, il est lancé sur la console du serveur HF lui-même.

Je pense de plus en plus qu'il n'y aura pas de solution, à part changer de SGBD et tous les ordres SQL du programme.

[vmolines]

C'est l'application qui plante, le problème ne peut pas venir du réseau. Vous pouvez oublier cette piste.

[EDM-TAHITI]

Hello
Le fluck ou fluke (qui est la marque) est un appareil de mesure d'envois et de réception de données informatisées. Il calcule entre autre le spectre send/received et le temps passé...

Pour info et sans faire de pub car il sont meader dans le domaine - leader mondiaux

http://fr.farnell.com/fluke&CMP=KNC-...S|b|3382339472

Bon, revenons a nos moutons, ce n'est pas parcre que le programme 'qui fait planter' est uniquement sur la machine que cela ne vient pas du réseau...

Si tu peux faire un test, tu passes en charge normale et tu debranches la carte reseau du serveur qui sert les postes, a mon avis, tu verras bien si le moteur manta part en cachuètes.
Si oui, la piste est à creuser...

[Bowen]

Pas facile à faire ce test, je me vois pas couper le serveur du réseau pendant une journée chez le client, juste pour faire un test, et savoir si le programme en question suffit à lui seul à faire planter le Manta.exe.
De plus, le programme en question étant alimenté par les actions des utilisateurs (une table d'actions à effectuer qui se remplit), le test ne servirait à rien.
Au bout de 20 minutes, le programme ne ferait plus aucune écriture.

[EDM-TAHITI]

Hello,
Oui, je comprends bien... Pas facile à réaliser. Je te donne des pistes, après tu vois ce que tu peux réaliser.
Et quand ca plante, le gestionnaire de tâches, il est comment? Saturé en mémoire, en services? Combien de threads as-tu? L'occupation de chaque tâche?
Ce que je trouve étrange, c'est que le fichier impossible à lire fait parti des fichiers propres à la gestion de Manta... Mais par expérience, ce qui se voit n'est pas forcément la cause du problème, mais souvent sa résultante. Le moteur fait-il une réindexation lors du plantage, as-tu des problèmes d'index??
Voilà, encore plein de questions, je m'en excuse, mais j'essaye de comprendre.
Ah, un dernier truc, j'ai eu une fois un soucis avec ma carte graphique de type ASUS Radeon, les drivers posés soucis. Et comme tu es en TSE, c'est peut être une autre piste... Cela figé mon poste de développement, et surtout les services... Encore une piste

[Bowen]

D'abord merci d'avoir regardé depuis le début.

Effectivement, les tests sont difficiles à effectuer et pas forcément concluants.
Je pense de plus en plus qu'on ne pourra pas changer grand chose, à part faire une ré-écriture complète du programme, et le faire tourner sur un moteur plus sérieux.
J'ai en effet la confirmation de PCSoft que tous les ordres venants des requêtes sont retraduits en HLitxxx. Ce qui n'arrive à priori pas avec les ordres SQLxxx.
Je pense que la surcharge du moteur manta.exe vient de là, et que 60 000 lectures pour 15 minutes c'est décidément beaucoup trop (pour n'importe quel serveur d'ailleurs). En espérant que les lectures seront plus performantes sur un autre moteur, et que ça me réduira le nombre de lectures.

J'ai en effet pas mal de code qui remplace des jointures trop longues à exécuter par des lectures sur plusieurs fichiers.

Je serais curieux de faire une comparaison de temps de lecture sur un autre moteur. Je vais lancer un post en ce sens d'ailleurs.

[EDM-TAHITI]

Hello,
Je suis désolé de ne pouvoir apporter une reelle solution...
Quand tu me dis que 60.000 lectures pour 15 minutes, c'est beaucoup, certe, mais cela ne fait que 66 lectures par seconde... (quand même).
Et du côté du chache serveur, tu es comment? J'ai remarqué qu'il était sensible, le bougre. Comme tu as de la mémoire, pourrais-tu augmenter ce cache du moteur manta afin de voir si cela optimise les accès (j'ai fais des tests, assez concluant).
Et dans ton relevé de statistiques, qu'est-ce qui prend le plus de temps, les lectures, les écritures, les deux? et la mémoire cache du serveur, elle dis quoi???
Je pense comme toi, même si tu changes de moteur, que tu auras, à un moment donné, ce genre de paramétrages à faire, ou refaire...
Fais des essais et tiens moi informé.
Bon courage pour ce debut de semaine