forum Ancestrologie
Ancestrologie - Développement => Développement => Discussion démarrée par: Bruno T. le 20 Février 2012 à 17:46:47
-
Bonjour,
J'ai peut-être trouvé quelque chose de rationnel par rapport au problème latent de mesure du besoin ou pas d'optimiser, mais j'ai besoin d'une base de test
Rappel:
Aujourd'hui la mesure n'en est pas une, c'est un indicateur arbitraire de durée d'usage de la base, il diminue même si il n'y a pas de transaction sur la base, solution provisoire mais qui dure faute de mieux.
Donc je fait appel à une bonne âme, qui aurait une base non optimisée, ayant subit "énormément" de travaux, une base dont la taille sur le disque avant optimisation est "largement" plus importante qu'après.
S vous pensez avoir cela, merci de répondre ici
-
Bonjour,
Ma base avant Optimisation fait 506 068 Ko et après 503 640 KO, cela suffit-il en écart ?
Cordialement
-
La mienne faisait 137000ko après la dernière optimisation, et 168000 aujourd'hui.
Si ça peut vous convenir.
-
Bonjour à tous les 2,
@ emable: je pense que ce ne serait pas suffisamment significatif par rapport à Blefebvre, merci quand même d'avoir répondu.
@ Blefebvre: Si je comprends la dernière sauvegarde après optimisation faisait 137 mo et aujourd'hui après usage et sans optimisation elle serait "grimpée" à 168 Mo, cela me semble intéressant, surtout en faire une copie a mettre de coté ou m'envoyer, avant de faire une optimisation, merci.
Je vais mettre un petit prg en lien , il donnera 2 ou 3 indications sur la base et ça me renseignera pour voir si mon idée tient debout ou pas .
-
Je l'envoie comment. C'est trop gros pour mettre en pièce jointe.
-
Tu peux utiliser un service gratuit en ligne comme dl.free.fr, et la compresser avant (zip, rar, ...)
Merci
(mail en message perso)
-
Merci Blefebvre,
j'identifie des éléments chiffrés prometteurs, je vais analyser tout ça et vous tiendrai au courant
Si d'autres ont des bases avant/après avec toujours différence de taille significative, je suis toujours preneur pour mieux établir un règle.
Merci
-
bonjour Bruno,
est ce que la différence de "poids" entre le backup .gbk et le fichier .bdd peut être un indicateur ?
ajout : pour être plus précis , évolution du ratio .bdd /.gbk avec comme référence le même ration après une optimisation
-
Faut queje recherche, mais je ne pense pas, le gbk doit être un genre de backup, par extraction des datas et règles, puis compression, il est obtenu par l'application gbak.exe, dans ancestro l'optimisation est en fait une sauvegarde/restauration avec cet outil, ce qui est tout a fait normal.
Sauf à avoir des exemples plus concrets, je pense qu'aujourd'hui l'optimisation d'une base, n'apporte plus grand chose sauf grosse base à usage élevé, le fractionnement étant relativement limité, le seul indicateur pertinent identifié à date serait la différence entre le nombre de transactions exécutées et le numéro de la suivante: ex base de lefebvre: on passe de 168Mo à 125Mo lors de optimisation, olors que le .gbk fait 82Mo pour un delta OldestTrans-NextTrans de 2036-174=1862 transactions "inutiles ou égarées", sur mes bases plus petites avec usage très modéré, je n'ai que 5 à 10 d'écart. Apres optimisation, li n'y a plus d'écart, voilà.
Mon idée créé la ratio à partir de ces infos, mais pas eu le temps de finir d'analyser. :oops: Suffit peut-être d'imaginer que ce seul exemple est suffisament concret, pour edicter:
- 168 Mo / 125Mo = 25% de gain de taille pour environ 1800 transaction virées environ 175 utiles (soit un rapport de 10 environ)
- on pose 125Mo correspond 100% optimisé
Donc Merci d'avance au matheux qui va nous pondre une règle pas trop absurde, sur les données 1800, 175 (et éventuellement taille fichier) l'objectif étant de dire qu'un fractionnement ou gain potentiel de 10 % (arbitraire) de la taille du fichier, peut-être considérer suffisant pour déclencher l'optimisation, merci :wink:
D'autre-part le sweep interval indique qu'en dessous de 20000 d'écart, la base ne "réagit" pas, on devrait je pense réduire cette valeur.
"C:\Program Files (x86)\Firebird\Firebird_2_1\bin\gstat.exe" "Bruno-pc:C:\Users\Bruno\Projets\Base de donnees\Test\LEFEBVRECOMPLET.BDD" -header
"C:\Program Files (x86)\Firebird\Firebird_2_1\bin\gstat.exe" "Bruno-pc:C:\Users\Bruno\Projets\Base de donnees\Test\LEFEBVRECPL_OPTIM.BDD"
-header
Database "C:\Users\Bruno\Projets\Base de donnees\Test\LEFEBVRECOMPLET.BDD"
Database header page information:
Flags 0
Checksum 12345
Generation 2051
Page size 4096
ODS version 11.1
Oldest transaction 174
Oldest active 2036
Oldest snapshot 2036
Next transaction 2041
Bumped transaction 1
Sequence number 0
Next attachment ID 9
Implementation ID 16
Shadow count 0
Page buffers 32000
Next header page 0
Database dialect 3
Creation date Mar 5, 2012 14:34:20
Attributes no reserve
Variable header data:
Sweep interval: 20000
*END*
C:\Users\Bruno>"C:\Program Files (x86)\Firebird\Firebird_2_1\bin\gstat.exe" "Bruno-pc:C:\Users\Bruno\Projets\Base de donnees\Test\LEFEBVRECPL_OPTIM.BD
D"
Database "C:\Users\Bruno\Projets\Base de donnees\Test\LEFEBVRECPL_OPTIM.BDD"
Database header page information:
Flags 0
Checksum 12345
Generation 189
Page size 4096
ODS version 11.1
Oldest transaction 173
Oldest active 174
Oldest snapshot 173
Next transaction 179
Bumped transaction 1
Sequence number 0
Next attachment ID 3
Implementation ID 16
Shadow count 0
Page buffers 32000
Next header page 0
Database dialect 3
Creation date Mar 8, 2012 16:33:23
Attributes no reserve
Variable header data:
Sweep interval: 20000
*END*
-
bonjour Bruno,
D'autre-part le sweep interval indique qu'en dessous de 20000 d'écart, la base ne "réagit" pas, on devrait je pense réduire cette valeur.
j'ai fait plusieurs lecture dont cette page: http://www.firebirdsql.org/manual/gfix-housekeeping.html
De ce que je crois comprendre , et pour Firebird SuperServeur , ce Sweep Interval est à 20000 ,valeur sans doute appropriée pour des bases qui sont sollicitées par de nombreux utilisateurs, mais dans nos cas ???
Une valeur de 100 , permettrait le Garbage Collection (automatique ) de fonctionner effectivement .
Vais faire un essai long pour voir si je note une ou des différences à l'utilisation ( vais le mettre à 50)
ajout: c'est fait et vérifié
-
Bonsoir Alain, Philippe
Intéressant ton retour,
tu veux bien dire qu'avec le sweep à 50, l'optimisation parait devenir inutile, et que avant/après optimisation il n'y a pas de différence de taille perceptible ?
Si c'est confirmé, je pense qu'il faudra malgré-tout laissé la possibilité de lancer cette optimisation dans un menu, ou fenetre, au cas ou.
Par contre supprimer la barre et le lancement automatique.
PS: désolé de ma présence rare ces derniers temps, mais ayant repris un emploi, les 1er mois sont assez chargés pour faire sa place, je reviendrais plus régulièrement d'ici quelques semaines, de plus la v2 finale des arbres est sur le feu, faudrait que je boucle avant l'hiver, m'enfin le taf reste plus important.
-
bonsoir,
j'ai préparé un tableau avec les résultats journaliers de :
taille .BDD en Octets || taille .GBK en octets || ratio BDD/GBK || Nbre de Nouv enreg. || Nbre enreg. modifié
je le posterai demain
je ne compte pas faire d'optimisation , ceci pour voir ce qui se passe !
je compte aussi faire (mais sur une sauvegarde) la manip en BOA comme pour récupérer les CP sur toute la base
-
Bonjour,
voici le tableau
La base : 15000 individus, 4500 unions , quand les actes sont mémorisés c'est uniquement en mode fichier ,
seulement qques photos en mode images pour les Identité
Le Sweep a été mis à 50 le 3 octobre
le .BDD faisait 47.240 le .GBK faisait 45.513 Ko (lecture sur l'explorateur)
après optimisation
le .BDD faisait 47.240 le .GBK faisait 45.517 Ko (lecture sur l'explorateur)
ensuite dans le tableau qui suit le poids des fichiers est lu dans les propriétés du fichier
Date BDD octets GBK octets Créées Modifiées BDD/GBK
04/10/2012 48 373 xxx 46 644 xxx 37 75 1.037
05/10/2012 48 373 xxx 46 809 xxx 17 36 1.033
06/10/2012 48 373 xxx 46 854 xxx 8 12 1.032
07/10/2012 51 396 xxx 46 927 xxx 25 36 1.095
08/10/2012 51 396 xxx 46 964 xxx 22 25 1.094
09/10/2012 51 396 xxx 47 010 xxx 25 30 1.093
10/10/2012 51 396 xxx 47 042 xxx 14 34 1.093
ce jour le 11 octobre , avant toute opération , voici ce que donne le gstat
P:\Program Files\Firebird\Firebird_2_1_5\bin>gstat sw50_1360_5130_01oct.bdd
can't format message 21:6 -- message file E:\Fich_Recus\Firebird-2.1.5.18496-0_W
in32\firebird.msg not found
Database header page information:
Flags 0
Checksum 12345
Generation 3571
Page size 4096
ODS version 11.1
Oldest transaction 3545
Oldest active 3546
Oldest snapshot 3546
Next transaction 3547
Bumped transaction 1
Sequence number 0
Next attachment ID 85
Implementation ID 16
Shadow count 0
Page buffers 32000
Next header page 0
Database dialect 3
Creation date Oct 3, 2012 15:20:32
Attributes force write
Variable header data:
Sweep interval: 50
*END*
et ci-dessous le gstat sur ma base que j'avais nommée Sweep20000.bdd
je ne trouve pas de trace d'optimisation avant 15h23 et la sauvegarde que j'ai utilisé est de 12h13 le 03 oct 2012
P:\Program Files\Firebird\Firebird_2_1_5\bin>gstat sweep20000.bdd121003-1213
can't format message 21:6 -- message file E:\Fich_Recus\Firebird-2.1.5.18496-0_W
in32\firebird.msg not found
Database header page information:
Flags 0
Checksum 12345
Generation 2294
Page size 4096
ODS version 11.1
Oldest transaction 1532
Oldest active 2256
Oldest snapshot 2254
Next transaction 2285
Bumped transaction 1
Sequence number 0
Next attachment ID 34
Implementation ID 16
Shadow count 0
Page buffers 32000
Next header page 0
Database dialect 3
Creation date Sep 28, 2012 18:43:38
Attributes force write
Variable header data:
Sweep interval: 20000
*END*
Ce qui me semble significatif c'est qu'avec un sweep à 50 la base semble se maintenir toute seule dans un état où les données en gras restent avec un très faible écart , .... comme après une optimisation !!
-
bonsoir,
toujours en observation, comparaison,... (j'en passe!!!) je viens en relisant le sujet de bout en bout , et en comparant les DataBase Header de la base transmise par LEFEBVRE et la mienne de noter une différence qui doit avoir une certaine importance...
Sa base est avec Attributes : no reserve la mienne avec Attributes : Force Write
Attributes: This part of the report displays information about various attributes of the database. Examples of what you may see are:
no reserve - All pages will be filled to 100% and will be most useful on read-only databases. No space is reserved in each page for updates and/or deletions.
force write - Disc writes are not cached. They are written out to the hardware at the time of the write request. This is used mainly on Windows databases where the cache management system can lead to lost writes and database corruption.
source : http://www.firebirdsql.org/manual/bk02ar17s03.html
et aussi dans cette question/réponse à Firebird-Support
http://ancestrologie.org/forum/index.php?action=post;topic=11836.0;num_replies=12
enfin , je trouve que c'est encourageant de voir les données ci-après au bout d'une semaine de fonctionnement avec le Garbage collection à 50. et après avoir créé à ce jour +/- 150 individus
Oldest transaction 3545
Oldest active 3546
Oldest snapshot 3546
Next transaction 3547
Les explications que l'on trouve dans le premier lien semble dire que jusqu'ici c'est encourageant.
-
bonjour,
mise à jour de mes relevés
voir image
je continue sur la base non optimisée
-
Bonjour,
je stoppe mes enregistrements et vous donne le résumé:
Configuration Firebird
- version 2.1.5 en super serveur
- Database properties
page size 4096
allocated pages 12548 ( après une optimisation )
page buffers 32000
sweep interval 50 (passé à 5 le 02 dec 2012)
Force Writes
Firebird.conf
#RootDirectory =
Je ne suis pas bien clair là dessus , ce qui fait que pour le reste ..., est ce bien pris en compte ??
# File system cache usage
#
# Sets the threshold whether Firebird will use file system cache or not.
# File system caching is used if database cache pages (sets explicitly in
# database header or implicitly via DefaultDbCachePages setting) is less
# than MaxFileSystemCache value.
# To always use file system cache set MaxFileSystemCache to some big value.
# To never use file system cache set MaxFileSystemCache to zero.
#
# Type: integer, measured in database pages
#
#MaxFileSystemCache = 65536
#MODIF perso ALAIN
MaxFileSystemCache = 0
( risques de corruption de la base avec le cache système )
Bref ! j'ai observé pendant plus de 30 jours , voir le tableau XL.
1/ d'une base optimisée le 03 oct 12
voir les repérages en vert --> optimisation sur la base de travail
voir les repérages en jaune ---> optimisation intermédiaire sur une copie de la base de travail
2/ la taille de la .BDD n'augmente que périodiquement et par "bonds" (pages allouées X Page size )
voir les répèrages en bleu
la fréquence de ces bonds est fonction de l'activité
dans cette activité , sont particulièrement déclencheurs : Renumérotation Sosa et création, alimentation d'un nouveau dossier
3/ en résumé :
le 3 oct 12 BDD= 48 373 760 GBK= 46 690 304 ratio BDD/GBK = 1,036 055 7944 départ optimisé
entre le 03 oct et le 06 nov , il y a eu 2 "bonds" intermédiaires de la taille de la BDD
les ratios BDD/GBK ont progressé alors comme suit : = 1,095 237 5757 NON optimisé
= 1,152 950 5875 NON optimisé
le 17 nov 12 BDD= 58 019 840 GBK= 49 676 800 ratio BDD/GBK = 1,167 946 4056 NON optimisé
le 17 nov 12 BDD= 51 396 608 GBK= 49 677 824 ratio BDD/GBK = 1,034 598 6169 OPTIMISÉ
Si cela peut vous inspirer ... c'est tant mieux
bien amicalement
(tableau en zip à suivre en AJOUT
-
Bonjour,
Je viens de relire ce post, et après plusieurs tests, j'en arrive à la même conclusion:
- le sweep n'a pas l'air d'avoir d'influence sur la taille de la base
- la valeur de oldest transaction s'aligne sur celle de next transaction-1
Malgré tout, j'ai quand même positionné le sweep inteval à 50 au lieu de 2000 dans le nouveau script d'installation et la mise à jour (pas encore en ligne) en attendant de trouver le "truc"
Je rajoute: le sweep influe quand même sur la vitesse d'augmentation de la taille de la base d'après ce je lit par ci par là, celà reste à confirmer, peut-être avec des tests partant de la même base, avec les mêmes opérations, mais un sweep 50 et l'autre 2000 par exemple.