On Fri, Jun 22, 2012 at 11:22:32AM -0400, Phil Stracchino wrote:
> 
> That.  Way too many people just run with the default config file that
> the package installed.  Or they go to the example configs and pick out
> the "large server" configuration example and use that.
> 
> The problem is, that "large server" example config was written back when
> a "large server" was one that might have as much as 32MB of RAM, and
> hasn't been significantly updated since.

I had a similar issue a while ago with the "building directory tree"
taking four hours, which incidentally was the same time mysql needed
for a 

repair table File; 

statement. After repairing the table, dirtree building was back to
being rather snappy again. 

On the topic of mysql optimization, what variables should I be looking
at? As I've mentioned recently, recycling my on-disk Friday volume
takes about five hours, not terribly long but also I wouldn't cry it
this could be sped up a bit ;-) 

I've tried increasing the key buffers to 1,6G (18GB RAM in the bacula
server), max_temp_table and heap_size to around 800MB, so far without
any significant improvement. I'd be glad for some more recommendations
on how to reduce recycle times. I'm in the process of splitting up the
jobs to go into separate volumes (not into a single giant one for
Friday), but still I find the idea of creating a separate device /
storage / pool config for each of my 120 clients a bit overkill. 

All the best, Uwe 


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users