Bonjour Olivier, Petite question pratique, vous recevez à priori les messages de la liste sous forme 1 message récapitulatif par jour. Lors de votre réponse à la liste, vous serait-il possible d'enlever les parties "non intéressante" ... J'ai un peu ramé pour retrouver le fil .... :-)
Voir réponse dans le message >> ------------------------------ >> >> Message: 4 >> Date: Thu, 24 Sep 2009 14:41:31 +0200 >> From: Olivier Delestre <[email protected]> >> Subject: [Bacula-users-fr] syntax Requete mysql lors de restauration ? >> To: "bacula-users-fr (francais)" >> <[email protected]> >> Message-ID: <[email protected]> >> Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" >> >> Bonjour, >> >> Voila mon Pb lorsque je fais une restauration ( rest -> choix 5 ), le >> building tree met 15 minutes a se construire. >> >> Comment savoir quel est l'ordre sql genere ? >> >> et/ou >> >> Quels indexes faut il positionner ? >> >> J'etais en bacula 2.4.4 mais depuis quelques jours en 3.0.2. >> L'upgrade_mysql_table ne doit pas mettre ce qu'il faut comme indexes. >> >> a la creation ? partir de rien , les indexes sont differents que si >> l'on part d'une ancienne version. >> >> De zero : table File = FileId, JobId, JobId+PathId+FilenameId >> ( ce qui genere in keyname a JobId_2 ) >> >> Depuis la v2.4.4 -> 3.0.2 : table File = FileId,JobId+PathId+FilenameId >> >> D'ailleurs dans la documentation officielle ( >> http://bacula.org/3.0.x-manuals/en/catalog/catalog/Catalog_Maintenance.html >> ), >> il parle de CREATE INDEX file_jpf_idx on File (JobId, FilenameId, >> PathId); >> >> l'ordre des colonnes est invers?es entre FilenameId et PathId, est ce >> important >> >> Merci de votre aide >> >> Cordialement >> Olivier >> >> ------------------------------ >> >> Olivier Delestre wrote: >>> Bonjour, >>> >>> Voila mon Pb lorsque je fais une restauration ( rest -> choix 5 ), le >>> building tree met 15 minutes a se construire. >> c'est pas forc?ment tr?s long ... > > C'etait plus rapide avant mais il est vrai que les volumes ont > augmentés ( ex : 8000000 de fichiers à plus 10000000 pour un serveur > de mail ) > >>> Comment savoir quel est l'ordre sql genere ? >>> >> mysqladmin processlist >> >> SELECT Path.Path,Filename.Name,FileIndex,JobId,LStat FROM >> File,Filename,Path WHERE File.JobId=[ici n? du jobid] >> >> > J'ai essaye cet ordre et le cpu est partie en fleche. > > sinon pour savoir les ordres générés, on peut activer les logs mysql > dans un fichier startmysql --log=/var/lib/mysql/log.txt > > Je ne joins pas ce que genere le fait de faire un restore sous > bconsole, 5 pages SQL :-( > Oui pas très étonnant avec autant de fichiers / ligne dans la table. >>> et/ou >>> >>> Quels indexes faut il positionner ? >>> >>> J'etais en bacula 2.4.4 mais depuis quelques jours en 3.0.2. >>> L'upgrade_mysql_table ne doit pas mettre ce qu'il faut comme indexes. >>> >>> a la creation ? partir de rien , les indexes sont differents que si >>> l'on part d'une ancienne version. >>> >>> De zero : table File = FileId, JobId, JobId+PathId+FilenameId >>> ( ce qui genere in keyname a JobId_2 ) >>> >>> Depuis la v2.4.4 -> 3.0.2 : table File = FileId,JobId+PathId+FilenameId >>> >>> D'ailleurs dans la documentation officielle ( >>> http://bacula.org/3.0.x-manuals/en/catalog/catalog/Catalog_Maintenance.html >>> >>> ), >>> il parle de CREATE INDEX file_jpf_idx on File (JobId, FilenameId, >>> PathId); >>> >>> l'ordre des colonnes est invers?es entre FilenameId et PathId, est ce >>> important >> tout ceci ( les index suppl?mentaires ) ne servent qu'? acc?lerer >> les op?rations de db_check. >> > Je confirme au moins que le fait d ajouter des indexes ralenti le > traitement bacula. effectivement, des indexes ralentissent les > ecritures au profit des lectures. je suis donc revenu avec les indexes > de depart + un autre pour la table File. > > mysql> show indexes from File; > +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ > | Table | Non_unique | Key_name | Seq_in_index | Column_name | > Collation | Cardinality | Sub_part | Packed | Null | Index_type | > Comment | > +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ > | File | 0 | PRIMARY | 1 | FileId | A > | 42248816 | NULL | NULL | | BTREE | | > | File | 1 | JobId | 1 | JobId | A > | 733 | NULL | NULL | | BTREE | | > | File | 1 | JobId_2 | 1 | JobId | A > | 733 | NULL | NULL | | BTREE | | > | File | 1 | JobId_2 | 2 | PathId | A > | 1362865 | NULL | NULL | | BTREE | | > | File | 1 | JobId_2 | 3 | FilenameId | A > | 42248816 | NULL | NULL | | BTREE | | > | File | 1 | idxJFP | 1 | JobId | A > | 733 | NULL | NULL | | BTREE | | > | File | 1 | idxJFP | 2 | FilenameId | A > | 3840801 | NULL | NULL | | BTREE | | > | File | 1 | idxJFP | 3 | PathId | A > | 42248816 | NULL | NULL | | BTREE | | > +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ > 8 rows in set (0.05 sec) > > 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. 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. > >> Est-ce que le serveur mysql a ?t? param?tr? correctement ? Au >> minimum une base de configuration depuis un my-huge.cnf >> >> > Je suis effectivement partie du fichier my-huge.cnf. Voila le mien, a > ce jour : > > > # The following options will be passed to all MySQL clients > [client] > #password = your_password > port = 3306 > socket = /var/lib/mysql/mysql.sock > > # Here follows entries for some specific programs > > # The MySQL server > [mysqld] > port = 3306 > socket = /var/lib/mysql/mysql.sock > skip-locking > key_buffer = 512M > max_allowed_packet = 2M > table_cache = 1024 > sort_buffer_size = 8M > read_buffer_size = 8M > read_rnd_buffer_size = 16M > myisam_sort_buffer_size = 128M > thread_cache_size = 8 > query_cache_size = 128M > # Try number of CPU's*2 for thread_concurrency > thread_concurrency = 4 > > # Replication Master Server (default) > # binary logging is required for replication > log-bin=mysql-bin > > # required unique id between 1 and 2^32 - 1 > # defaults to 1 if master-host is not set > # but will not function as a master if omitted > server-id = 1 > > #server-id = 2 > # > # The replication master for this slave - required > #master-host = <hostname> > # > # The username the slave will use for authentication when connecting > # to the master - required > #master-user = <username> > # > # The password the slave will authenticate with when connecting to > # the master - required > #master-password = <password> > # > # The port the master is listening on. > # optional - defaults to 3306 > #master-port = <port> > # > # binary logging - not required for slaves, but recommended > #log-bin=mysql-bin > > # Point the following paths to different dedicated disks > #tmpdir = /tmp/ > #log-update = /path-to-dedicated-directory/hostname > > # Uncomment the following if you are using BDB tables > #bdb_cache_size = 384M > #bdb_max_lock = 100000 > > # Uncomment the following if you are using InnoDB tables > #innodb_data_home_dir = /var/lib/mysql/ > #innodb_data_file_path = ibdata1:2000M;ibdata2:10M:autoextend > #innodb_log_group_home_dir = /var/lib/mysql/ > #innodb_log_arch_dir = /var/lib/mysql/ > # You can set .._buffer_pool_size up to 50 - 80 % > # of RAM but beware of setting memory usage too high > #innodb_buffer_pool_size = 384M > #innodb_additional_mem_pool_size = 20M > # Set .._log_file_size to 25 % of buffer pool size > #innodb_log_file_size = 100M > #innodb_log_buffer_size = 8M > #innodb_flush_log_at_trx_commit = 1 > #innodb_lock_wait_timeout = 50 > > [mysqldump] > quick > max_allowed_packet = 32M > > [mysql] > no-auto-rehash > # Remove the next comment character if you are not familiar with SQL > #safe-updates > > [isamchk] > key_buffer = 256M > sort_buffer_size = 256M > read_buffer = 2M > write_buffer = 2M > > [myisamchk] > key_buffer = 256M > sort_buffer_size = 256M > read_buffer = 8M > write_buffer = 8M > > [mysqlhotcopy] > interactive-timeout > > 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 # The MySQL server [mysqld] port = 3306 socket = /var/lib/mysql/mysql.sock #skip-locking max_allowed_packet = 16M table_cache = 512 tmp_table_size = 1024M key_buffer = 1024M key_buffer_size = 512M read_buffer_size = 2M read_rnd_buffer_size = 8M bulk_insert_buffer_size = 16M sort_buffer_size = 256M read_buffer_size = 128M myisam_sort_buffer_size = 128M myisam_max_sort_file_size = 2G myisam_max_extra_sort_file_size = 2G myisam_repair_threads = 1 myisam_recover thread_cache_size = 8 query_cache_size= 164M query_cache_limit = 64M # Try number of CPU's*2 for thread_concurrency thread_concurrency = 4 character-set-server=utf8 default-collation=utf8_general_ci > > A Ce jour, la sauvegarde de ce client prend 36h :( > Outch ... :-) > 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) 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. 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 ... > 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 ------------------------------------------------------------------------------ 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
