Le Thursday 08 October 2009 15:45:02 Olivier Delestre, vous avez écrit : > > ------------------------------ > > > > 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.
Effectivement, on peut même dire que c'est pas trop mal, en théorie, ça peut monter quand même a 8MB/s, mais faut être tout seul sur le tuyau. > 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 ;) www.bacula.org -> Blog ou bien http://sourceforge.net/apps/wordpress/bacula/ Si vous trouvez Bacula utile, prennez 5 min pour le dire sur www.bacula.org -> Testimonials Bye ------------------------------------------------------------------------------ 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
