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