Discussion :

[Zabriskir]

Bonjour,

Nous avons une appli avec une base d'environ 1Go.
Le service fbserver.exe (version 2.0) consomme seulement 30Mo.

Est-ce normal ?
Ne devrait-il pas consommer beaucoup plus de RAM comme un autre SGBDR (SQL Server par exemple) ?

Merci pour vos réponses

[makowski]

Firebird est moins gourmand
ceci dit, cela dépend aussi des traitements en cours
les tris par exemple, vous consommer plus de Ram

[Zabriskir]

Merci pour votre réponse.

Seulement, les performances ne sont pas au rendez-vous.
Sur le forum SQL Server, tout le monde dit qu'un SGBD charge les données en RAM pour limiter les accès disques et gagner en performances.

Je me demande donc comment Firebird fait pour être à la fois performant et peu gourmant en ressource.

Mon appli n'étant pas performante du tout, je me demande si le paramétrage est correct.

Merci

[makowski]

c'est possible oui
mais comme ça dans le vide, impossible à dire
il n'y a pas que la mémoire qui compte, loin de là
c'est Firebird Classic ou Superserver ?
combien de bases, de connexions simultanées, quelle memoire dispo sur la machine, quel OS ?

que donne un :

Code :

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

select MON$PAGE_SIZE, MON$OLDEST_TRANSACTION, MON$OLDEST_ACTIVE,MON$OLDEST_SNAPSHOT, MON$NEXT_TRANSACTION ,MON$PAGE_BUFFERS, MON$PAGES FROM MON$DATABASE ;

[Zabriskir]

Comment savoir si c'est un classic ou un superserver ?

Tourne sur un Windows 2003 avec 2Go de RAM, 1 seul CPU.

J'ai lancé la requête :

Statement failed, SQLCODE = -204
Dynamic SQL Error
-SQL error code = -204
-Table unknown
-MON$DATABASE
-At line 1, column 141

??

[makowski]

c'est pas Firebird 2.1 donc
fbserver.exe donc SuperServeur

2Go de ram c'est pas énorme, il y a d'autres programmes sur ce serveur ?

un gstat -h mabase, ça donne quoi ?

[Zabriskir]

Merci pour vos réponses rapides.

le gstat donne :

Database header page information:
Flags 0
Checksum 12345
Generation 607905890
Page size 4096
ODS version 11.0
Oldest transaction 607905880
Oldest active 607905881
Oldest snapshot 607905881
Next transaction 607905882
Bumped transaction 1
Sequence number 0
Next attachment ID 0
Implementation ID 16
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Aug 4, 2008 10:39:42
Attributes force write, no reserve

Variable header data:
Sweep interval: 20000
*END*

1 seule base utilisée. Pas beaucoup de connexions simultanées (10 max).
Il y a un Tomcat qui tourne sur la même machine.

[makowski]

et avec Tomcat sur la même machine il reste de la mémoire dispo ?
parce que Tomcat, ça consomme
Il est toujours possible d'augmenter le cache de la base
là c'est la valeur par défaut, donc si firebird.conf n'a pas été changé c'est 2048 pages soit 2048*4096 = 8Mb
donc en fonction de la mémoire dispo ce cache peut être augmenté, mais il faut laisser de la mémoire pour les opérations de tri

après le cache ne fait pas tout, une bonne struture de tables, la maintenance des index, les bons index déclarés, un sweep régulier, des requêtes bien écrites jouent encore plus sur les perfs

[Zabriskir]

Je partage votre avis sur le bon choix des index, la bonne écriture des requêtes...
Par contre, qu'entendez-vous par maintenance des index et sweep régulier ?

A votre avis :
En admettant que notre configuration (1 base de 1Go, pas beaucoup de connexions) ait été faite proprement sous Firebird, elle devrait rivaliser avec la même chose sous SQL Server ou Oracle, non ?

Merci

[makowski]

oui pour rivaliser

mais une requête efficace sous MsSQL peut ne pas l'être sous Oracle, une requete efficace sous Oracle pas efficace sous MsSQL, efficace sous Firebird pas efficace sous Oracle, ....

sweep : gfix -sweep

maintenance index : SET INDEX ACTIVE