Re: [Bacula-users] Creating directory tree on 5.0.3 takes a long time

2011-10-26 Thread Uwe Schuerkamp
On Thu, Oct 20, 2011 at 05:41:14PM +0200, Uwe Schuerkamp wrote:
 Hi folks,
 
 as you may remember I've recently set up a brand new bacula server
 with version 5.0.3 compiled from source. I copied over the mysql
 settings (mysql-server-5.1.52-1.el6_0.1.x86_64) from the
 old machine and inquired here for optimized mysql settings to use with
 the setup (backup size  volume is the same as it was on the old
 server which had less ram, cpu and diskspace). 
 
 However, when I try to run a restore job from a decent-sized full
 backup, it takes forever to build the directory tree where on the old
 machine this has been quite a speedy process. 
 
 I've checked the faq and the indices for the file table: 
 
 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
 |   154262958 | NULL | NULL   |  | BTREE  | |
 | File  |  1 | JobId|1 | JobId   | A
 |NULL | NULL | NULL   |  | BTREE  | |
 | File  |  1 | JobId_2  |1 | JobId   | A
 |NULL | NULL | NULL   |  | BTREE  | |
 | File  |  1 | JobId_2  |2 | PathId  | A
 |NULL | NULL | NULL   |  | BTREE  | |
 | File  |  1 | JobId_2  |3 | FilenameId  | A
 |NULL | NULL | NULL   |  | BTREE  | |
 +---++--+--+-+---+-+--++--++-+
 
 (sorry for the long lines) which look ok to me, so I was wondering
 what could cause this huge difference in restore run times before I
 get to the file marking part of the restore process. 
 
 This operation: 
 Building directory tree for JobId(s) 759 ...
 +
 1,629 files inserted into the tree.
 
 took over three minutes where I seem to recall it being much faster on
 the old setup.
 
 I used the standard create_bacula_tables script that comes with 5.0.3
 to set up the database. The major difference seems to be moving from a
 CentOS 5.6 to a 6.1 environment (both were 64bits, btw). Bacula DB
 size is 26GB (MyISAM tables). 

Hi folks,

I've turned on the slow query log and it's come up with the following
result (dirtree build for an incremental job that contains 41 files): 

http://pastebin.com/rNDivjHg

when I quit the restore function and immediately try the same job
restore, the tree builds instantly, so I guess it's a mysql
problem. I've tried running mysqltuner and have increased the key
buffer size, however the total index size is 10G where the server only
has 6GB RAM ;-) Anything else I could try to speed up the dirtree
generation? 

All the best  thanks in advance, 

Uwe 

-- 
NIONEX --- Ein Unternehmen der Bertelsmann AG



--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users


[Bacula-users] Creating directory tree on 5.0.3 takes a long time

2011-10-20 Thread Uwe Schuerkamp
Hi folks,

as you may remember I've recently set up a brand new bacula server
with version 5.0.3 compiled from source. I copied over the mysql
settings (mysql-server-5.1.52-1.el6_0.1.x86_64) from the
old machine and inquired here for optimized mysql settings to use with
the setup (backup size  volume is the same as it was on the old
server which had less ram, cpu and diskspace). 

However, when I try to run a restore job from a decent-sized full
backup, it takes forever to build the directory tree where on the old
machine this has been quite a speedy process. 

I've checked the faq and the indices for the file table: 

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
|   154262958 | NULL | NULL   |  | BTREE  | |
| File  |  1 | JobId|1 | JobId   | A
|NULL | NULL | NULL   |  | BTREE  | |
| File  |  1 | JobId_2  |1 | JobId   | A
|NULL | NULL | NULL   |  | BTREE  | |
| File  |  1 | JobId_2  |2 | PathId  | A
|NULL | NULL | NULL   |  | BTREE  | |
| File  |  1 | JobId_2  |3 | FilenameId  | A
|NULL | NULL | NULL   |  | BTREE  | |
+---++--+--+-+---+-+--++--++-+

(sorry for the long lines) which look ok to me, so I was wondering
what could cause this huge difference in restore run times before I
get to the file marking part of the restore process. 

This operation: 
Building directory tree for JobId(s) 759 ...
+
1,629 files inserted into the tree.

took over three minutes where I seem to recall it being much faster on
the old setup.

I used the standard create_bacula_tables script that comes with 5.0.3
to set up the database. The major difference seems to be moving from a
CentOS 5.6 to a 6.1 environment (both were 64bits, btw). Bacula DB
size is 26GB (MyISAM tables). 

Thanks in advance for any pointers, 

Uwe 

-- 
NIONEX --- Ein Unternehmen der Bertelsmann AG



--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Ciosco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users