> Message: 2 > Date: Wed, 07 Oct 2009 07:08:07 +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 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 .... :-)
Desole, mauvaise utilisation de la liste et j'ai plein de trucs sur le feu. >>> > >>> 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] >>> >>> > Que devrais me donner cet ordre ? car en prod, c'est trop long. ca met a genoux la machine. il faudrait que j'essaye en test. mysql> select count(*) from File; +----------+ | count(*) | +----------+ | 42314148 | +----------+ mysql> select count(*) from Path; +----------+ | count(*) | +----------+ | 361991 | +----------+ 1 row in set (0.00 sec) >> 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. > > Effectivement, je pense que le traitement risque d'etre long. J'ai lu qq part que l'on pouvait l'automatiser par cron ?? > >> >>> 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 ... :-) je n suis pas expert en optimisation de base. Donc, j'essaierais de m'inspirer de ces parametres. tmp_table_size que je n'ai pas a priori > >> 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 ? > Non le serveur de mail est une machine complètement autonome. Mais au vue, de son activite, il est en permanence sollicité. le cpu idle est à 100 % tout le temps, cpu user 20-25% et le serveur de sauvegarde tourne en virtuel avec xen sur des Dell 1950 i-quad core Xeon avec un San MD 3000 et MD 1000 (raid materiel bien sur). Le tout dans une architecture cluster. Mais sur le noeud ou se trouve le serveur de sauvegarde , il y a peu de machine et d'activite (la nuit ). > 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 ). > > Je n'ai pas chercher mais qu'est ce que Accurate deja ? >> >> 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 ... > Pour une fois, je n'ai pas recompiler a partir des src-rpm mais j'ai utiliser les rpms-contrib-fschwarz . Aurais je fait un mauvais choix ? >> 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 > > je re lirais ce post a tete reposer afin d'en tirer des informations. Je remercies les personnes qui passent de leur temps a me lire (ca doit pas etre facile ;)) ). Et je tiendrais au courant de mes actions. Merci Olivier Delestre ------------------------------------------------------------------------------ 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
