On Thursday 22 June 2006 20:40, Arno Lehmann wrote:
> Hi,
>
> On 6/22/2006 1:55 PM, Kern Sibbald wrote:
> > On Monday 19 June 2006 22:11, Arno Lehmann wrote:
>
> ...
>
> >>>The Backup machine has 2 Gbyte of Ram and 4 Gbyte of swap. During
> >>>building the dir tree the phsysical Ram is only 50Mbyte and the swap has
> >>> only 50% of his capacity. With "sar -r" i followed the rising memory
> >>>allocation of bacula-dir but in the last 50 minutes it stay at 50% and
> >>>crahes.
> >>
> >>This is, unfortunately, a known issue (which obviously becomes more
> >>serious as Bacula is used in bigger and bigger installations).
> >
> > Whoa. There is NO known issue of Bacula crashing during the building of
> > the tree. Users with underpowered machines or inefficiently tuned
> > machines have experienced some excessive waits for the tree to build.
> > However, there are users with 6 Million files who are able to use the
> > restore in a reasonable time.
>
> I'm quite sure I recall reading about crashes... and even if they arise
> from a database problem it's quite related to Bacula in that case.
>
> Anyway, using the term 'issue' I didn't want to imply that there's a
> programming bug in Bacula, rather that this is a limitation that is
> known and can not easily be overcome.
Oh, there are lots of bugs in Bacula, but at the current time, I know only
about two specific crashes of the Director, which I take very seriously. One
is related to mutexes and possibly putting a laptop in sleep mode, the second
is most likely related to a user specifing too much optimization -- both are
against FreeBSD systems.
>
> I know what I'm writing about, my backup machine is also seriously
> underpowerded ;-)
>
> >>If I understand it correctly, Kern has some ideas how to handle this
> >>problem but will probably not work on it really soon.
> >
> > The most effective solution for the moment it to ensure that everything
> > is properly tuned -- especially for the SQL engine, and if I am not
> > mistaken that is documented ...
>
> Hmm. The only performance tuning hints in the manual I could find are
> rather cursory: "For MySQL, what seems to be very important is to use
> the examine the my.cnf file. You may obtain significant performances by
> switching to the my-large.cnf or my-huge.cnf files that come with the
> MySQL source code."
Yes, it is very sketchy, because I am not an SQL performance specialist, but
hopefully it points users in the right direction.
>
> While the above is definitely right, I suspect that tuning MySQL can be
> much more sophisticated. Unfortunately, I have no idea what to do with
> this goal.
Read up on it in the MySQL manual :-)
>
> Arno
--
Best regards,
Kern
(">
/\
V_V
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
