Firebird 2.0 embedded - et lenteur aléatoire [Résolu]

[charlyoleg]

Bonjour,

Voila quand je fais un select first(5000) id from matable where age_du_capitaine=54
ma requête prends environ une seconde à s'éxécuter.
Ma table contient 2 millions 700 miles enregistrements, mais là n''est pas le problème.
Je fais ma requête grâce à un composant TJvUIBDataSet que je connecte à un datasource que je connecte à un tdbgrid.
Ensuite je fais un monJvUIBdataset.last et là ca prend 10 secondes.
Ca va vu le contenu de ma table. Mais ce que je ne comprends pas c'est pourquoi il arrive que cette même requête prenne plus de 7minutes de façon aléatoire ??? et si je ressaye aussitot aprés hop le tout passe à nouveau à 10secondes....

Je précise que ma base est en lecture seule, qu'il y a eu un backup/restore juste avant de la mettre en lecture seule.

J'ai vérifié dans le répertoire temporaire de windows rien de particulier mis à part le fichier de lock quand Firebird bricole la table, pas de fichier temp dans mon appl, rien... et la date de modification de la base ne change jamais...

Pourquoi le temps d'éxécution d'une même requête peut-il autant varier?

Merci,

[makowski]

parce que dans le cadre d'un fetch aussi gros, ce sont les accès disque qui font la différence et donc le cache des pages, le cache des disques ...

quelle idée aussi de mettre 5000 enregistrements dans une grille

après d'autres choses rentre en jeu : les index, la bonne santé de la base (cf stats, un sweep ne se serait il pas déclenché au moment de la requête plus longue, normalement non si la base et les requêtes sont en read only ...)

[charlyoleg]

Envoyé par makowski

parce que dans le cadre d'un fetch aussi gros, ce sont les accès disque qui font la différence et donc le cache des pages, le cache des disques ...

ok, mais je ne comprends pas pourquoi si je reboote mon pc, au premier lancement de mon appli la requête peut prendre 10s si c'etait une histoire de cache ça devrait être lent au premier lancement, non?

Envoyé par makowski

quelle idée aussi de mettre 5000 enregistrements dans une grille

Je dois afficher dans un dbgrid le résultat de la recherche de l'utilisateur (en me limitant à 5000) C'est un choix du client.

Envoyé par makowski

après d'autres choses rentre en jeu : les index, la bonne santé de la base (cf stats, un sweep ne se serait il pas déclenché au moment de la requête >plus longue, normalement non si la base et les requêtes sont en read only ...)

Pour les index , j'ai fait un restore/back juste avant de la mettre en lecture seule,et aussi un gfix –mend, la base devrait etre en bonne santé

[makowski]

1/ ce n'est pas parce qu'un client demande quelque chose qu'il faut forcément le faire exactement comme il le demande surtout si cela entraine des dysfonctionnement
2/ soit tu nous dis pas tout, soit ton disque est très lent, soit tu n'as pas d'index sur ton champ du where, mais tes perfs ne sont vraiment pas bonnes

[charlyoleg]

10 secondes pour ma requête ca me va, ce qui me va pas trop c'est le coté un peu aléatoire.
il est à préciser que ma requête est plutot comme ca:
select first(5000) id from matable where nom_capitaine like '%kowsk%'
et donc les index semblent pas utilisés dans ce cas..ca me pose pas de problème, je souligne seulement le caractère aléatoire du temps d'éxécution et celà sur 4 pc différents.

[makowski]

select first(5000) id from matable where nom_capitaine like '%kowsk%'

donc pas d'index utilisé, donc parcours de la table en NATURAL,
donc différences de perfs liées aux accès disques
(tous les caches rentrent en jeux, de celui de Firebird à celui du disque en passant par l'OS)
s'il y a assez de mémoire sur le poste, essayer mettre un maximum de pages dans le cache, puisque c'est une base en lecture seule
peut être aussi qu'une taille de page plus grande peut aider

[charlyoleg]

je viens de modifier le fichier firebird.conf :
DefaultDbCachePages = 16384 #4096 #2048
Ce doit etre la mise en cache mais pour augmenter la taille des pages je ne vois pas.

tu connais pas un bon bouquin sur firebird qui fait le tour d'un peu tout?
Merci,

[makowski]

Envoyé par charlyoleg

tu connais pas un bon bouquin sur firebird qui fait le tour d'un peu tout?
Merci,

celui d'Helen
http://ibphoenix.com/main.nfs?a=ibph..._firebird_book

[charlyoleg]

merci beaucoup

[Delfino]

Pourquoi le temps d'éxécution d'une même requête peut-il autant varier?

C'est a cause des transactions ouvertes en même temps au moment de la requête, examiner les y tu veras que c'est pas le même d'une requête a l'autre..

[charlyoleg]

Envoyé par Delfino

C'est a cause des transactions ouvertes en même temps au moment de la requête, examiner les y tu veras que c'est pas le même d'une requête a l'autre..

Bonjour,
Ca me paraît étrange car lorsque je lance mon appli elle fait toujours les même traitement, et de temps à autre j'ai le ralentissement. Logiquement, d'aprés ce que tu dis cela ne pourrait être aléatoire.
Merci,

[Barbibulle]

Faites vous un fetch all systématique ?
Car il est possible que celà viennent tout simplement de vos composants.
Par defaut et ce pour optimiser seul les enregistrements affichés à l'écran sont rapatriés. Et la suite est envoyée uniquement à la demande (lorsqu on descend dans la grille).

En forçant un fetch all (vous placer votre curseur à la fin de vos données) vous forcer le programme à lire tous les enregistrements.
Essayer de faire celà pour voir si vous avez un résultat plus cohérant (10minutes systématique )

Enfin autre piste à explorer... Vous dites que votre base de données est en lecture seule. Je comprend que vous avez rendu le fichier de la base en lecture simple ??? Si c'est le cas je suis assez étonné que celà fonctionne et vous invite à ne pas la mettre en lecture seule. Firebird a besoin d'écrire dans le fichier pas mal de chose technique et ce meme si vous ne faite que des selects... Il y a qu'en utilisant la version embedded que l'on peut avoir une base en lecture seule (pour créer un catalogue sur CDROM par exemple).

Celà pourait etre une explication car tant qu"il a suffisamment de mémoire il n'ecrit pas dans le fichier les données techniques mais arrivé un moment donné il essaye d'ecrire dans le fichier en lecture seul et celà creé probablement ce gros ralentissement.

Si vous ne voulez pas que les utilisateurs puissent ecrire dans votre base, vous n'avez qu'à tout simplement gérer un profil (role) qui n'aura le droit que de lire vos tables.


J'espere que je vaus avoir droit à un "Formidable !!"

[makowski]

Envoyé par Barbibulle

Enfin autre piste à explorer... Vous dites que votre base de données est en lecture seule. Je comprend que vous avez rendu le fichier de la base en lecture simple ??? Si c'est le cas je suis assez étonné que celà fonctionne et vous invite à ne pas la mettre en lecture seule. Firebird a besoin d'écrire dans le fichier pas mal de chose technique et ce meme si vous ne faite que des selects... Il y a qu'en utilisant la version embedded que l'on peut avoir une base en lecture seule (pour créer un catalogue sur CDROM par exemple).

faux on peut avoir des bases en lecture seule avec n'importe quelle version de Firebird

[charlyoleg]

bonjour,

a propos du coup que ma base doit etre en embedded, le titre de mon message est assez explicite (Firebird 2.0 embedded - et lenteur aléatoire ) :-)
merci,