Hello Bruno,
Le Wednesday 07 October 2009 20:37:55 Bruno Friedmann, vous avez écrit :
> Bonjour Eric.
>
> Eric Bollengier wrote:
> > Le Wednesday 07 October 2009 07:08:07 Bruno Friedmann, vous avez écrit :
> >> La présence des index ralenti effectivement l'écriture de
> >> l'enregistrement, mais voilà de toute façon il les faut pour les
> >> opérations de db_check (Il y avait des messages sur la ml anglaise qui
> >> recommandait au minimun une fois par mois.
> >
> > Je dirais qu'il faut lancer le dbcheck quand la table Filename à plus de
> > 50% des enregistrements qui ne sont plus référencés. Cela dépend donc de
> > votre installation, mais je dirais que 1 fois par ans ou tous les 6 mois
> > est suffisant. (voir jamais). (Il faut aussi le lancer après un mauvais
> > crash ou des mauvaises manips)
> >
> > Je ne vous conseille pas de ralentir des centaines (voir milliers) de
> > jobs pour une maintenance annuelle.
>
> Ok cela contredit certains messages que j'avais lu ( peut-être un peu vieux
> d'ailleurs ) En fait je lance cela à peu près une fois par trimestre, avec
> mysql l'avantage c'est que cela effectue aussi un table optimize ( en tout
> cas mysql après db_check ne fait pas plus ) ce qui réduit quand même la
> fragmentation interne des index et tables.
Pas besoin de lancer dbcheck pour faire la maintenance classique et obligatoire
de la base de donnée (analyse, vacuum, optimize etc...)
Ces deux procédures n'ont rien à voir, et les commandes de maintenance du
moteur de la base n'a pas besoin d'index pour fonctionner.
Sur une "grosse" base, il faut faire de la maintenance plusieurs fois par
semaine.
> >> La question est de savoir si la contruction de ces index ne met
> >> pas trop de temps à ce moment là. Plus leur suppression après.
> >
> > Avec 40M d'enregistrements, on doit tourner autour de 5min de création
> > ...
> >
> >> J'ajoute à titre d'information la configuration utilisé ici pour un
> >> serveur de backup. (AMD X2 5600, 4Go Ram, 1 disque système + 1 paire
> >> Raid1 sata pour mysql ) avec beaucoup moins d'enregistrements
> >> au total 25 Millions de record dans File
> >> 356000 PathId dans Path
> >> et 1,6 Millions de FileNameId
> >
> > J'ai publié sur le blog Bacula une série de test avec 75M de fichiers
> > dans File, et le backup de 1.5M de tout petits fichiers prennait en
> > moyenne 6mins sur MyISAM.... La restauration 1.5M sur 2.2M (50
> > incrementales + 1 Full) 5 à 6min (création des fichiers sur ext3 inclus).
>
> Bon le pb c'est que là c'est très souvent le cache kernel qui aide un
> maximum. Dès que l'on dépasse la taille de la ram, on voit les vrais
> résultats io disks. (que l'on m'arrête si je me trompe ... )
J'ai fait des tests sur un PC "basique" acheté début 2009, et oui la taille de
la ram aide, mais il faut aussi dimensionner son serveur en fonction de ce
qu'on lui demande.
> >>> A Ce jour, la sauvegarde de ce client prend 36h :(
> >>
> >> Outch ... :-)
> >
> > Combien de fichiers ? Quelle taille ?
>
> A priori dans ce qu'Olivier notait dans un précédent mail, il est aux
> alentours de 10 Millions de Files pour quelque 200Go.
Cela fait beaucoup de fichier, mais cela n'explique pas les 36h. J'aimerais
bien savoir si les résultats sont meilleurs en decommentant dans
src/cats/sql_create.c ligne 946
if (bdb->changes > 100000) {
db_write_batch_file_records(jcr);
bdb->changes = 0;
sql_batch_start(jcr, bdb);
}
Cela permet de ne pas avoir une session batch de 10,000,000 de fichier. (Je
conseille quand même d'utiliser au moins 500,000 changements)
Cela doit aider les petites installations qui ont des gros besoins :)
> >>> J'avais deja lu des post de Bruno Friedmann ( bacula giving slow speed
> >>> ), tres instructif.
> >>> Pour infos, mon serveur de sauvegarde est sous CentOs en machine
> >>> virtuelle Xen avec un San iscsi en stockage ( Raid 5, LVM ). J'ai une
> >>> partition unique / pas de tmp sur un autre device sur mon serveur. La
> >>> compression est active.
> >>>
> >>> Toute vos idées sont les bienvenues afin de réduire la durée de
> >>> sauvegarde et ce Building Tree qui est assez long lors du restore.
> >>
> >> J'imagine, que le serveur mail sauvé est également sur la machine Xen ?
> >>
> >> Il y a eut un post de John et d'autres sur la ml anglaise pour la
> >> configuration Bacula avec Xen. En gros il en ressortait le fait que le
> >> SD et le DIR avait tout intérêt à être installlé sur le Dom0
> >>
> >> Il faut particulièrement faire attention à la concurrence avec les cpu/
> >> et io disque dans le virtuel. Car si le fd bosse à fond pour récupérer
> >> ses fichiers + les compresser, cela laisse d'autant moins de temps cpu
> >> pour les autres (sd stockage, et mysql), a cela s'ajoute la lenteur
> >> Raid5 (peut-être relative si raid-matériel) et LVM + le file système. Je
> >> viens de lire un article dans le linux magazine anglais N° 108 November
> >> 2009 sur l'ajustement du filesystem (ext3,xfs) et le sous-sytème raid.
> >> Des différences de 30% de perfomances peuvent exister.
> >> (www.linux-magazine.com)
> >
> > Durant mes tests, le backup des 1.5M de fichier sous ext3 prennait plus
> > de 5 heures.... Contre 5min avec reiserfs (il est très bon pour les
> > petits fichiers).
>
> Bon je ne recommanderais plus trop reiserfs au jour d'aujourd'hui.
> Des fois il faut un peu se battre avec ext3/4 ou xfs pour avoir de bons
> résultats surtout lorsqu'il y a RAID (soft ou matériel).
> Aligner la taille des blocs du fs sur celle du raid aide grandement.
Le problème vient surtout du fait que Reiserfs stocke les petits fichiers
directements dans les descripteurs de fichier, avec 1 io il peut lire le
fichier alors que ext3 utilise des redirections et il en faut 2 ou 3 fois
plus.
Et ce n'est pas la prison qui rend reiserfs3 plus ou moins stable d'un coup.
10M de fichiers pour 200Go, ça fait une moyenne de 20ko par fichier, et
surement beaucoup moins si il y a quelques ISO.
Il faut regarder le log du backup pour connaitre le temps de sauvegarde par
rapport au temps de la session batch.
> >> A vérifier :
> >>
> >> Mysql taille des bases et taille des index. Idée séparer sur 2 io/disk
> >> les tables et les index (cf docu mysql) Il y a certainement encore une
> >> grosse dose d'optimisation de mysql à réussir. Nous n'utilisons pas
> >> batch-insert dans le cas de la configuration présentée ( bacula 2.2
> >> encore ) Mais comme notre disque système n'est qu'un pauvre pata, nous
> >> avons déplacer les données mysql sur une paire de disque sata en raid1
> >> kernel.
> >
> > Je vais publier un article sur la différence avec le mode normal et batch
> > insert, et pour MyISAM le "nouveau" mode est quand même 2 fois plus
> > rapide.
>
> En fait d'après mes propres tests, tout dépend de l'environnement. si là où
> écrit mysql les tables temp (Batch) et lent, cela peut largement handicapé,
> car c'est lent à la première écriture puis ensuite il faut relire cela et
> écrire à nouveau dans les tables mysql.
Très très étrange, l'écriture dans la table batch est séquencielle, si
l'écriture séquencielle est lente, il faut changer de serveur. Un simple
disque SATA fait entre 30 et 70Mo/s. Il n'y a pas d'index, ni de journaux à
mettre à jour...
Dans le mode normal, il faut aussi faire des millions de select/insert dans les
tables Path et Filename. (environ 3 à 4 fois plus de requettes avec le mode
normal)
> Alors que le non batch, dans ce cas, n'écrit qu'une fois au fur et à
> mesure. Le vrai idéal avec Batch-Insert c'est de faire bosser toute la
> partie Batch et temp sur de l'utra-rapide (raid-0 de ssd XE-25 d'intel :-)
> )
C'est vrai qu'un disque rapide pour les espaces temporaire et de tris aide
toutes les bases de données.
> Attention, bien évidement il y a les autres avantages du batch insert (je
> le note pour Olivier, Eric sachant mieux que quiconque de quoi il retourne
> ): Un job plante, pas d'enregistrements "parasites" dans la db.... etc.
Tout dépend de la base de données, sous MyISAM, il n'y a pas d'intégrité, pas
de transaction, donc si un job plante pendant une insertion dans File, il y a
des enregistrements morts.
> >> Pour la durée : Peut-être qu'une réorganisation du jeux de sauvegarde (
> >> Accurate ? ) pourrait accélerer les choses. ce que je pense si c'est un
> >> serveur de mail imap, car les fichiers n'arrêtent pas de changer d'état.
> >> ( ou d'être déplacer de dossier en dossier ).
> >>
> >>> Le Stat dir, sous la console fait apparaitre Dir inserting Attribute
> >>> de maniere reguliere ( 3.0.2 et/ou volume en augmentation ), Le Batch
> >>> insert est il la solution ? comment savoir s'il est actif ?
> >>
> >> Pour être certain de pas raconter de bétise, puisque bacula est
> >> construit depuis les sources, récupérer le résultat du ./configure (
> >> fichier .config dans la racine des sources )
> >> Il me semble que --batch-insert est actif par défaut maintenant ...
> >
> > Il faut quand même vérifier, par exemple la détection ne semble pas bien
> > fonctionner sur Jaunty.
>
> A priori, il utilise les contrib-fschwartz sur centos.
> Là j'en sait rien, parce que je recompile mes propres rpms ( besoin
> d'options qui ne sont pas actives par défaut)
>
> >>> Voila en vrac mes soucis. meme si cela marche tres, tres bien.
> >>
> >> ça c'est bacula ( moi je l'utilise depuis la 1.34 )
> >>
> >> Je
> >>
> >>> souhaite optimiser tout cela. J'espere ne pas avoir ete trop bavard.
> >>> Merci pour tout
> >>>
> >>> Ca fait plaisir d'avoir du monde sur la liste francaise :-))
> >>
> >> itout .
> >>
> >>
> >> PS : il y a à Paris les 5 & 6 Novembre les PgDay ( www.pgday.eu ) où il
> >> y a une conférence d'Eric Bollinger sur postgresql/bacula
> >
> > J'espère bien rencontrer des utilisateurs de Bacula et discuter un peu :)
> >
> > Bye
>
> Franchement je vais me battre avec mon planning, le programme des
> conférences me fait trépigner sur place :-))) Ca serait vraiment super
> effectivement.
Et bien à bientôt alors.
bye
> A+
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Bacula-users-fr mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users-fr
