Re: [Bacula-users-fr] syntax Requete mysql lors de restauration ?

[Bruno F. <br...@io...>]

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.

> 
>> 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 ... )
> 
>>> 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.

> 
>>> 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.

> 
>> 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.
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 :-) )

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.

>> 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.

A+

-- 

     Bruno Friedmann