Bacula-users

[Bacula-users] restore / slow directory tree build process on 5.0.x / mysql

2010-07-16 12:16:53
Subject: [Bacula-users] restore / slow directory tree build process on 5.0.x / mysql
From: Nick Hilliard <nick AT foobar DOT org>
To: bacula-users AT lists.sourceforge DOT net
Date: Fri, 16 Jul 2010 16:48:56 +0100
Hello,

something's gone badly wrong with the directory tree rebuild sql query on
5.0.x.  I'm currently attempting to restore a single file from a disk
backup I made recently:  here's the output:

> +--------+-------+----------+----------------+---------------------+-------------------------+
> | JobId  | Level | JobFiles | JobBytes       | StartTime           | 
> VolumeName              |
> +--------+-------+----------+----------------+---------------------+-------------------------+
> | 10,087 | F     |  401,368 | 56,963,986,536 | 2010-07-04 02:05:01 | 
> Pool-Full-Office-0597   |
> | 10,178 | D     |    5,768 |  1,804,433,105 | 2010-07-11 02:05:01 | 
> Pool-Diff-Office-0009   |
> | 10,217 | I     |    3,189 |    628,898,394 | 2010-07-14 02:05:01 | 
> Pool-Increm-Office-0013 |
> | 10,230 | I     |    1,689 |    250,775,502 | 2010-07-15 02:05:00 | 
> Pool-Increm-Office-0051 |
> +--------+-------+----------+----------------+---------------------+-------------------------+
> You have selected the following JobIds: 10087,10178,10217,10230
> 
> Building directory tree for JobId(s) 10087,10178,10217,10230 ...  

At this stage, bconsole has been sitting there for 3 hours waiting for
mysql to complete the query.  the mysqld process has been pegged at 100%
all this time.

In terms of mysql config, the my.cnf file is linked to my-huge.cnf, except
that key_buffer_size is set to 1536M:

> pancake:/var/db/mysql# mysqladmin variables | grep -i key_buffer_size
> | key_buffer_size                         | 1600126976                        
>       |
> pancake:/var/db/mysql# 

The sql server is an quad core opteron 1352 with 8G memory running freebsd
8.0/amd64.  It's otherwise unloaded.  msyql 5.0.88, bacula 5.0.2.  All the
backups are to disk (zfs raidz1 on 4 x spindles), however, it's not even
getting that far.

Just in case, I ran "optimize table" on File, Filename and Path earlier today.

This used to work fine on bacula 3.x - the directory build process only
took seconds.

I'm looking angrily at commit 8bf4c85c30bac47f76415ff1f634b20efdf22048.
Not sure if it's the prime cause, but the overall SQL query looks pretty gross.

any suggestions?

Nick

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users