Pb HyperFile 18

Version imprimable

18/10/2013, 10h40
abrial

Pb HyperFile 18

Bonjour,

depuis que nous avons migré notre application de WD14 à WD18, nous constatons des lenteurs d'affichage des listings. Il semble que se soit HyperFile C/S qui met plus de temps pour répondre. Nous avons des fichiers qui ont 500000 Enregistrements (donc pas énorme) mais qui sont assez volumineux (beaucoup de rubriques textes, 2Go pour 500000 Enregistrements). Des requêtes qui passaient en WD14 restent bloquées, sans réponse.

Nous essayons d'optimiser nos requêtes mais cela demande beaucoup de temps et de tests.

Mes questions :
- Quelqu'un a-t-il déjà rencontré ce genre de pb et si oui, avez-vous des solutions ?
- Est-ce que le fait que le disque dur soit fragmenté génère des lenteurs lors de l'accès aux bases ?

Merci de votre aide.
18/10/2013, 11h35
DelphiManiac

Citation:

Il semble que se soit HyperFile C/S ...

Est-ce que lors du passage de W14 à W18 vous avez aussi migré de Hyperfile classic à Hyperfile C/S ?

Citation:

- Est-ce que le fait que le disque dur soit fragmenté génère des lenteurs lors de l'accès aux bases ?

Oui, mais je ne suis pas sûr que ce soit facilement perceptible, normalement des fonctions de cache sont là pour lisser les problèmes de fragmentation. Mais sur le fond : oui, fragmentation = accès à des endroits différend sur le disque, donc plus de déplacement de la tête de lecture.
18/10/2013, 14h00
abrial

Merci de la réponse.

Non, nous étions déjà en HF C/S.
18/10/2013, 23h29
DelphiManiac

Je n'ai pas de solution miracle à proposer. Les pistes que je préconiseraient :

1) Essayer d'isoler une requête qui pose problème.
2) La sortie de son contexte d'exécution, c'est à dire, faire un projet de test qui ne fait qu'exécuter cette requête et afficher les résultats et cela en version 14 et 18.
3) Comparer le temps d'exécution de la requête et le temps d'affichage du résultat indépendamment. La lenteur peut être lié à l'affichage et pas à la requête.

Le serveur C/S a été basculé en 18 aussi ?

4) Si possible, faire les tests précédents sur les 2 versions d'hyperfile C/S, 14 et 18 (sur la même machine bien sûr)
19/10/2013, 07h53
jdsetls

Pour les cas difficles...

Bonjour,

Pour les cas difficiles, la solution est donnée gratuitement par le service technique de PCSoft, à condition qu'il s'agisse de la version en cours.

Auquel cas des patches d'optimisation sont parfois publiés.

Le problème que tu évoques semble suffisamment important pour que tu aies un accès privilégié à leurs services.

En espérant que cette non réponse soit au moins une piste,

Jacques De Schryver
19/10/2013, 09h04
Arnaud B.

Citation:

Envoyé par abrial

Bonjour,

depuis que nous avons migré notre application de WD14 à WD18, nous constatons des lenteurs d'affichage des listings. Il semble que se soit HyperFile C/S qui met plus de temps pour répondre. Nous avons des fichiers qui ont 500000 Enregistrements (donc pas énorme) mais qui sont assez volumineux (beaucoup de rubriques textes, 2Go pour 500000 Enregistrements). Des requêtes qui passaient en WD14 restent bloquées, sans réponse.

Nous essayons d'optimiser nos requêtes mais cela demande beaucoup de temps et de tests.

Mes questions :
- Quelqu'un a-t-il déjà rencontré ce genre de pb et si oui, avez-vous des solutions ?
- Est-ce que le fait que le disque dur soit fragmenté génère des lenteurs lors de l'accès aux bases ?

Merci de votre aide.

Personnellement, j'ai migré une application HF C/S de WD14 à 15, puis 16, 17, 18... je n'ai pas perçu de variation significative (quoique plutôt à la baisse sur 17 et 18), mais je n'ai pas de volumétrie aussi importante que toi.

Piste : vérifier le cache du serveur HF
19/10/2013, 09h55
dsr57
Bonjour,

Citation:

Le problème que tu évoques semble suffisamment important pour que tu aies un accès privilégié à leurs services.

Je ne suis pas sur que le support technique apportera une réponse si se sont des requêtes SQL :?. Ils vont surement te dire d'utiliser les HlitXxxx :cry:

Quelques pistes :
- Est ce que tu as passé le serveur hyperfile en version 18 ?
- Sur le site de pc-soft une mise à jour du serveur Hyperfile C/S a été diffusée le 16/07/2013, l'as tu installé ?
- Autres pistes, as tu ré-indexé les fichiers sur le serveur HF en version 18 ?
21/10/2013, 10h21
abrial

Bonjour,

merci pour toutes ces réponses. Voici des réponses aux questions :
- le serveur a été migré en version 18 (la dernière datant de Juillet).
- une réindexation est effectuée tous les matins
- j'ai essayé d'augmenter la taille du cache, mais ça ne résout pas le pb

Je vais essayer, comme le propose DelphiManiac, de faire un projet de test avec uniquement l'exécution de la requête pour voir ce qu'il en est.

Le pb d'envoyer une requête à Pc Soft est que :
-le pb de lenteur est difficile à montrer (il faudrait monter la manip en WD14 et WD18, lancer en mode Optimisation pour afficher les procédures qui prennent du temps, et envoyer tout ça à Pc Soft (plusieurs Go de données !))
-le pb de blocage de requête se produit uniquement chez quelques clients, mais pas chez moi, même avec leur données. Remarque sur ce pb : ils ont un deuxième serveur HF, pour un autre programme, qui tourne en Hyperfile 15. Nous avons donc 2 instances HF (celle de notre programme est sur le port 4903).
21/10/2013, 20h40
dsr57

Bonjour,

As tu vérifié l'état de la mémoire dans le gestionnaire de tache ?
Car il se pourrait que la mémoire du serveur soit saturée et que tu passes en accès disque.
22/10/2013, 10h58
digi12

bonjour

voir probleme connu chez pcsoft de non dechargement de la mémoire du serveur

http://blogs.pcsoft.fr/post.awp?titl...profiter,2,406

http://blogs.pcsoft.fr/post.awp?titl...fiteelle,2,418

+ dans la lst93 ils ont mis une solution pour gagner de la mémoire
http://www.pcsoft.fr/lst/index.html
voir "libéreZ LA MéMOIRE sur un serveur pour la rendre à hyperfileSQL !"
22/10/2013, 12h49
abrial

Bonjour,

concernant les requêtes qui n'aboutissent pas, chez un client, c'est un serveur Windows 2003 R2. La mémoire RAM est en effet un peu juste (4 Go de RAM, plusieurs applications installés dessus, dont notamment SQL Server qui prend 1Go). Je viens de l'indiquer au client et j'attend son retour.

concernant l'application "libéreZ LA MéMOIRE sur un serveur pour la rendre à hyperfileSQL !", quelqu'un l'a déjà utilisé ? S'applique-t-elle uniquement sur les serveurs 64 bits ?

Merci
29/10/2013, 09h08
abrial

Bon, nous avons toujours les pbs de requêtes qui n'aboutissent pas et de lenteurs. Notre client nous dit ne pas pouvoir augmenter la RAM car il est sur un serveur 2003 32bits, avec 4Go.

Une question concernant les lenteurs que je me pose :
- nous avons une routine qui redémarre le service Hyperfile tous les matins, pour éviter qu'il ne monte trop en RAM : est-ce une bonne opération ou une mauvaise ? Perdons-nous toutes les statistiques accumulées par le serveur HF au cours de la journée ?

Merci.
29/10/2013, 10h39
dsr57

Salut :coucou:

Normalement on redémarre un serveur uniquement pour des opérations de maintenance.

Qu'elle est la taille du cache de la base HF ?
29/10/2013, 11h17
abrial

cela dépend du serveur physique. On essai de mettre 10% de la RAM.
31/10/2013, 10h14
abrial

Bonjour,

je constate que les fichiers NDX sont très petits par rapport au fichiers FIC. Ceci doit être du à la réindexation qui est faite tous les jours avce l'option hNdxCompactage.

D'après vous est-ce que ceci peut nuire aux performances d'HF ?

Merci
08/11/2013, 08h57
dsr57

Je commencerais par augmenter la taille du cache de la base HF.

le serveur en question, a t il d'autres fonctions que serveur de données ?
08/11/2013, 09h07
tatayo
Bonjour,
Je commencerai par analyser l'activité sur le serveur pendant que ces requêtes tournent: utilisation CPU, RAM, activité des disques, du réseau... pour trouver le goulet d'étranglement.
Si le problème se trouve côté:
- CPU: pas grand chose à faire, à part changer de serveur...
- RAM: si le serveur swap, il faut diminuer la consommation mémoire de quelqu'un. Le but étant de ne pas utiliser plus que la RAM physique du serveur.
- Disque: augmenter le cache (voir le point précédent), changer de disque. Une bonne grappe SAS en RAID 10 peut changer les choses (testé et approuvé ! ).
- Réseau: voir ce qui est renvoyé par la requête, si toutes les données renvoyées sont utiles (attention au select * !).
Sans ces stats on ne peut faire que des hypothèses.

Tatayo.
08/11/2013, 09h09
Invité

Bonjour,

Dans notre société, nous avons testé aussi hyperfilesql C/S v17 et nous avons constaté en effet qu'il est plus lent en version 32 bits qu'en version 64 bits. Et quand je dis "plus lent", c'est aussi plus lent que la v17 en 32 bits aussi!

De plus, nous avons constaté qu'a un moment donné hyperfilesql prend énormément de place en mémoire centrale et ce quel que soit le cache qu'on lui attribue.

Du coup nous avons choisi pour l'instant de ne pas mettre du HF C/S v 18 chez les clients mais juste une v17... En attendant la version 19 qui sera (enfin) ACID (il était temps qu'ils rattrapent leur retard là-dessus pcsoft!)