On 29/09/2018 04:00, George Anchev via Bacula-users wrote:
On Fri, 28 Sep 2018 14:47:46 +0100 Martin Simmons
wrote:
This is not Bacula-specific: producing debugging
information is useful, just in case you need it.
And an end user generally does not need it. Also AFAIK
adding debugging info to binaries makes them slower.
>
This has not been true for decades.
The debugging information is useful in Bacula because when a Bacula
binary crashes it tries to run the btraceback.{dbx,gdb} script to help
find out what has gone wrong.
You appear to be suffering from what one of my lecturers back at
$GOSHWHATTAUNIVERSITY called "Premature Optimisation." (That was back
in the 1980s, and he had worked on CSIRAC :-) )
If you think about what the three major components of Bacula do, very
little is dependent on the CPU.
- Reads data from disk.
- Transmit data across the network.
- Write data to disk (if you are spooling).
- Write data to tape/disk.
- Send data to a database server.
Most of the time the various Bacula programs are waiting for I/O
operations to complete, the only time the CPU gets heavily involved is
if you are running compression.
Just use the defaults. You won't save enough CPU, memory, or time to
justify your efforts, and if you optimise at a level that triggers some
pathological behaviour in Bacula you may not find out that critical
parts of your back-ups are garbled until it is too late.
Cheers,
Gary B-)
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
