Serveur HyperFileSQL - Redemarrage Manta64.exe

Bonjour,

Nous rencontrons des problèmes sur un site client avec notre applicatif Windev 15. (Nous pensons bientôt migrer en version supérieur, mais pas en 20 car la version n'est pas encore stable)
Notre logiciel utilise une base de données HyperFileSQL, et le service Manta64.exe redémarre de façon aléatoire sur le serveur. (Parfois pas du tout dans la journée, parfois 3/4 fois ou une seule fois seulement...)

Le message dans l’observatoire d’évènements est le suivant :

Pièce jointe 168962

Le service redémarre, mais tous les postes doivent se reconnecter (message automatique de windev de reconnexion), ce qui assez (très) handicapant pour les utilisateurs. Et nous avons peur que cette erreur endommage la base de données. (En cas de transaction principalement..)

Nous avons tenté de comprendre ce qui provoque ce genre d’erreur, au niveau des accès à la base (requête ou autres), mais nous n’avons rien constaté d’anormal. (Le bug se reproduit jamais au même moment, ni suite à la même procédure / fenêtre...)
De plus nous avons d’autres sites clients, qui fonctionnent sans problème, dans des environnements similaires (en configuration et en nombre de postes).

Ci-dessous quelques détails sur la configuration.

Configuration du serveur : (Utilisé que pour le Serveur HF)
Fujitsu Primergy TX 150 S8
Windows Server 2012 R2 Fondation
Intel Xeon CPU E5-2420 @ 1,90 GHz
2 disque SATA de 500 Go en RAID-1 (7.2k/min)
16 Go de RAM

Paramètres Centre HFSQL :
Hyper File SQL version 19
Cache des index de 3000 Mo
Cache disque en Automatique

Base de données :
120 fichiers HF (Fichiers d'une centaines d'enregistrements à plusieurs millions)
Taille totale : ~ 10 Go
Accédés par environ 45 postes, avec possibilitée de double connexion sur chaque poste
(deux instances du logiciels possibles par poste)

S’il faut d’autres précisions, n’hésitez pas.

Pouvez-vous nous aider à trouver ce qui peut provoquer cette erreur svp ?

- Pourrait-il s’agir d’une défaillance liée à Windows ?
- Quelles seraient vos préconisations du serveur, en fonction de la base et du nombre d’utilisateurs indiqués ?
- Est-ce qu’un élément dans les statistiques d’activité ou les logs nous permettraient de comprendre l’origine du problème ?
- Voyez-vous d’autres axes de recherche qui nous permettraient de résoudre ce problème ?
- Avez-vous déjà rencontré ce genre de problèmes ?

Pour info, nous avons fait appel à PC Soft, qui nous ont gentiment répondu qu'ils ne répondaient que sur des logiciels maintenus sous leur version actuelle (c'est à dire la V20, même si celle ci n'est pas encore stable..., ironie.. => Pourtant nous avons bien la Clé V20..).

Merci d'avance !
Cordialement
Florian

Rien ne vous empêche d'installer une version supérieure de Manta même si vos programmes sont en 15.

Si vous n'avez pas "confiance" dans la version, 20, vous pouvez installer la version 19.

Bonjour,

Nous sommes déjà en V19 au niveau du Client/Serveur.
Je vais voir surement pour y installer la Version 20.

Auriez vous d'autres pistes ?

Merci d'avance,
Florian

Quelle est la sous-version du serveur HF ? Vérifiez qu'il n'y a pas de mise à jour...

Bonjour,

Après vérification, je suis bien sur la dernière version : 190056s .

Quels sont vos préconisations techniques (serveur) pour une base comme ci-dessous ?

Citation:

---

Base de données :
120 fichiers HF (Fichiers d'une centaines d'enregistrements à plusieurs millions)
Taille totale : ~ 10 Go
Accédés par environ 45 postes, avec possibilitée de double connexion sur chaque poste
(deux instances du logiciels possibles par poste)

---

Merci

Difficile de répondre...
Une grosse base bien pensée et des requêtes intelligentes seront bien gérés par un serveur léger alors que une petite base pourrie avec des requêtes en FULL OUTER JOIN et autre UNION nécessiteront une machine aux capacités supérieures...

La seule vérité c'est que plus le serveur est performant, mieux c'est ;)

Mais quoiqu'il en soit les dimensions de la machine me paraissent plutôt adaptée.

A votre place je tenterais une réparation de l'installation (désinstallation/réinstallation complète).

En fait à la réflexion je dirais surtout que pour ce genre d'exploitation le SGBD fourni par PCSoft n'est pas l'idéal (ça n'engage que moi).

Merci pour vos réponses.

Concernant le Serveur, je prend bien note de votre recommandation, je pense aussi que la réinstallation complète de l'OS ne peut que faire du bien.. je vais voir pour me pencher là dessus.

Concernant les requêtes elles sont pour la plupart optimisées (les principales) sans JOIN pour éviter des pertes de performances, mais chaque action peut provoquer l'écriture d'une dizaine d'enregistrement (voir plus) sur différents fichiers.

Sur votre réflexion concernant HyperFile, effectivement, je m'étais également posé la question. Le problème c'est que cela nécessiterais une grosse phase de développement sur le programme (environ 200k lignes de codes..)
Pour information, vous préconiseriez quoi comme SGBD ? (avec un Accès natif bien développé sans trop de limites..)

Merci beaucoup

J'ai un grand amour pour Oracle... dans mon souvenir (dév sur la version 12 de WD) il n'y avait pas beaucoup de bug dans l'accès natif.
SQLServer présente l'avantage d'exister en version Express...

Après, dans l'absolu, je vous recommande un SGBD reconnu que vos développeur connaissent et qui s'intègrent dans votre éco-système...

D'après ce que je comprends ("...chaque action peut provoquer l'écriture d'une dizaine d'enregistrement (voir plus) sur différents fichiers...") vous utilisez des triggers et procédures stockées... perso Oracle me parait un bon choix car le PL-SQL permet de faire énormément de chose (j'ai été très déçu en découvrant les limites du T-SQL).

Là avec Oracle, on est sur un vrai SGBD effectivement..
Le problème, c'est que nous sommes dans l'impossibilité à l'heure actuelle de changer de SGBD facilement.. Mais l'idée des procédures stockés et strige est intéressante pour soulager les postes clients et les échanges Client/Serveur.

Avez vous déjà testé les procédures stockés sur HyperFile ? et y a-t-il de vrai gains de rapidité ?

Merci d'avance,
Cdt,
Florian

Ouais j'ai testouillé... et ça marchouille... mais c'est du WLanguage... pas un véritable langage de manipulation de données... donc on peut faire des choses mais c'est, comme d'habitude, très particulier et propre à la philosophie PCSoft... le pire c'est le résultat de la création d'une PS qui est stocké dans une espèce de fichier illisible (de le répertoire \__System\__proc de la base associée) depuis un poste non-développeur, pseudo compilé géré avec l'analyse... enfin bref une belle pirouette pour implémenter un beau concept (initialement les PS c'est de la boulette) mais du coup c'est pas très pratique et carrément hors-norme.

Bonjour CFLO

Quasi même config.
Application métier. 50 users. Serveur W2102 R2. Serveur HF 15 en 64 bits. Appli en 32 bits.
Démarrage de la journée parfait. Au fur et à mesure la conso mémoire du CPU monte jusqu'à rester stable à 35% !
Obligé de redémarrer le serveur HF pour que les users puissent continuer à travailler.

Avez vous résolu votre problème ?

Merci bcp

Citation:

---

Envoyé par cflo56

Bonjour,

Nous rencontrons des problèmes sur un site client avec notre applicatif Windev 15. (Nous pensons bientôt migrer en version supérieur, mais pas en 20 car la version n'est pas encore stable)
Notre logiciel utilise une base de données HyperFileSQL, et le service Manta64.exe redémarre de façon aléatoire sur le serveur. (Parfois pas du tout dans la journée, parfois 3/4 fois ou une seule fois seulement...)

Le message dans l’observatoire d’évènements est le suivant :

Pièce jointe 168962

Le service redémarre, mais tous les postes doivent se reconnecter (message automatique de windev de reconnexion), ce qui assez (très) handicapant pour les utilisateurs. Et nous avons peur que cette erreur endommage la base de données. (En cas de transaction principalement..)

Nous avons tenté de comprendre ce qui provoque ce genre d’erreur, au niveau des accès à la base (requête ou autres), mais nous n’avons rien constaté d’anormal. (Le bug se reproduit jamais au même moment, ni suite à la même procédure / fenêtre...)
De plus nous avons d’autres sites clients, qui fonctionnent sans problème, dans des environnements similaires (en configuration et en nombre de postes).

Ci-dessous quelques détails sur la configuration.

Configuration du serveur : (Utilisé que pour le Serveur HF)
Fujitsu Primergy TX 150 S8
Windows Server 2012 R2 Fondation
Intel Xeon CPU E5-2420 @ 1,90 GHz
2 disque SATA de 500 Go en RAID-1 (7.2k/min)
16 Go de RAM

Paramètres Centre HFSQL :
Hyper File SQL version 19
Cache des index de 3000 Mo
Cache disque en Automatique

Base de données :
120 fichiers HF (Fichiers d'une centaines d'enregistrements à plusieurs millions)
Taille totale : ~ 10 Go
Accédés par environ 45 postes, avec possibilitée de double connexion sur chaque poste
(deux instances du logiciels possibles par poste)

S’il faut d’autres précisions, n’hésitez pas.

Pouvez-vous nous aider à trouver ce qui peut provoquer cette erreur svp ?

- Pourrait-il s’agir d’une défaillance liée à Windows ?
- Quelles seraient vos préconisations du serveur, en fonction de la base et du nombre d’utilisateurs indiqués ?
- Est-ce qu’un élément dans les statistiques d’activité ou les logs nous permettraient de comprendre l’origine du problème ?
- Voyez-vous d’autres axes de recherche qui nous permettraient de résoudre ce problème ?
- Avez-vous déjà rencontré ce genre de problèmes ?

Pour info, nous avons fait appel à PC Soft, qui nous ont gentiment répondu qu'ils ne répondaient que sur des logiciels maintenus sous leur version actuelle (c'est à dire la V20, même si celle ci n'est pas encore stable..., ironie.. => Pourtant nous avons bien la Clé V20..).

Merci d'avance !
Cordialement
Florian

---

Citation:

---

Envoyé par Tristan VTSOFT

Quasi même config.
Application métier. 50 users. Serveur W2102 R2. Serveur HF 15 en 64 bits. Appli en 32 bits.

---

A la pointe de la technologie, quasi 100 ans d'avance. Ca marche bien ? :mouarf:

Je pense qu'une évolution vers un manta v18 -> 20 ne serait pas du luxe. W2012 est tellement lourdingue que tu peux commencer par là.

+1 frenchsting

Explication : lors du passage en 19, le serveur HyperFileSQL est devenu HFSQL.

Effet de manche marketing ? Pas uniquement, loin s'en faut.
En effet, PCSoft a sensiblement amélioré le comportement du serveur en passant en ACID. je vous laisse la lecture du détail dans leur documentation et les autres... nulle doute qu'il y a eu inspiration et adaptation. Un peu comme le passage de MyISAM à InnoDB.

Toujours est-il que ces problèmes de fonctionnement du serveur ont été grandement améliorés.

Reste plus à revoir l'indexation des données...

+1 Romu

Merci pour la précision superbement circonstanciée.