> ------------------------------ > > Message: 2 > Date: Wed, 7 Oct 2009 09:26:16 +0200 > From: Eric Bollengier <[email protected]> > Subject: Re: [Bacula-users-fr] syntax Requete mysql lors de > restauration ? > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > 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. > >> 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). > >> > A Ce jour, la sauvegarde de ce client prend 36h :( >> >> Outch ... :-) > > Combien de fichiers ? Quelle taille ?
A ce jour : Elapsed time: 1 day 11 hours 54 mins 45 secs Priority: 10 FD Files Written: 11,099,679 SD Files Written: 11,099,679 FD Bytes Written: 547,221,461,084 (547.2 GB) SD Bytes Written: 548,699,808,033 (548.6 GB) Rate: 4232.7 KB/s Software Compression: 42.0 % J'ai oublé de préciser que le lien du client est en 100Mb donc au final avec l'activité de la machine, cela parait normal. je vais voir avec les gars du reseau pour passer avec une patte giga. Mais cela m'aura permis d'aller un peu plus loin dans l'optimisation. ( et ce n'est pas fini ) > >> > 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). > >> 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. > Je peux avoir l'adresse ;) >> 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, si j'ai pu voir DIR inserting attribute lors d'un stat dir sous la console, c'est que le batch insert est actif dans les paquets contrib-fschwartz. Dites moi si je me trompe ? car j'ai pas cherche a savoir quelles options de compil sont utilisés dans ces rpms. > >> > 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 > > > > ------------------------------ > > Message: 3 > Date: Wed, 07 Oct 2009 10:16:07 +0200 > From: Olivier Delestre <[email protected]> > Subject: Re: [Bacula-users-fr] syntax Requete mysql lors de > restauration ? > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" > > Pour infos, le dernier ordre sql ( buildind tree ) emis lors d'un > restore->choix 5 sous la console : > > SELECT Path.Path, Filename.Name, File.FileIndex, File.JobId, File.LStat > FROM ( SELECT max(FileId) as FileId, PathId, FilenameId > FROM ( SELECT FileId, PathId, FilenameId > FROM File > WHERE JobId IN (4032,4072)) > AS F GROUP BY PathId, FilenameId ) > AS Temp JOIN Filename ON (Filename.FilenameId = Temp.FilenameId) > JOIN Path ON (Path.PathId = Temp.PathId) > JOIN File ON (File.FileId = Temp.FileId) WHERE File.FileIndex > 0 > ORDER BY JobId, FileIndex ASC > > A+ > > > > ------------------------------ > > Message: 4 > Date: Wed, 07 Oct 2009 20:37:55 +0200 > From: Bruno Friedmann <[email protected]> > Subject: Re: [Bacula-users-fr] syntax Requete mysql lors de > restauration ? > Cc: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=UTF-8 > > 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. > Quelle est la différence de la faire avec mysql plutot que dbcheck ? dbcheck cree des index qui alourdisse les insert ? Avec mysql, Vous faites comment ? >> >>> 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. repondu plus haut, mais en gros 11Millions de fichiers pour 548 GB compressé > >> >>>> 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 >>> Pas possible, mais on va revoir notre infra pour sortir les machines virtuelles ( Xen-citrix ? ) et ainsi utilisé notre SAN que pour la sauvegarde ( Work in progress ) >>> 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. > Je vais regarder comment sont tailles les blocs. >> >>> 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. > Je pense effectivement garder le batch insert. >>> 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) > Pourrais savoir la commande utilisées pour recompiler vos votre rpms ( rpmbuild ?) >> >>>> 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+ Perso, je ne pense pas y aller, faute de temps et j'ai bien peur d'etre larguer. A+ Et merci de vos nombreuses remarques. :-)) > > -- > > Bruno Friedmann > > > ------------------------------------------------------------------------------ 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
