Re: [Bacula-users] how to debug a job

On 1/21/2015 6:37 PM, Dimitri Maziuk wrote:

On 01/21/2015 05:12 PM, Heitor Faria wrote:

Hey Mr. Dimitri: do you have Attribute Spooling on for this job (Job

resource, Spool Attributes=yes)? It usually improves the performance if
backing up lots of files, witch maybe causing this bottleneck.

Yes:
    SpoolData = yes
    SpoolAttributes = yes
    Spool Size = 49807360000

(Also Maximum Volume Bytes = 49807360000 -- these are disk volumes.
And Maximum Network Buffer Size = 65536)

There is likely no reason to have SpoolData=yes for disk volumes, and it could actually slow things down.

Is one of the jobs running concurrently with the failing job backing up the machine SD is running on? If so, you must check the job for backing up the machine that SD is running on and MAKE CERTAIN that it is not attempting to backup the spool directory.

The spool directory is by default in the Bacula work directory. You can use the SpoolDirectory directive in the device settings in bacula-sd.conf to place the spool data on different disk drives. Certainly, the spool directory should not be on the same disk drives that the database is on. That can cause a huge amount of read/write head movement, even with a caching RAID controller. (unless both are on SSD)

synchronous_commit = on

I might try that but I don't believe postgres is the bottleneck.

Looking at the director side, I have Max concurrent jobs = 10 and it
seems only 5 are running (there's more in the queue): 3 from Jan 19th
and 1 from Jan 21st. Is there any kind of scheduling going on that would
starve the job? -- all 5 seem to be spooling...

I might try sticking in an SSD for the spool drive to make sure that's
not the bottleneck.

"setdebug

This command is used to set the debug level in each daemon. The form of this command is:
setdebug level=nn [trace=0/1 client=<client-name> | dir | director | storage=<storage-name> | all]

If trace=1 is set, then tracing will be enabled, and the daemon will be placed in trace mode, which means that all debug output as set by the debug level will be directed to the file bacula.trace in the current directory of the daemon. Normally, tracing is needed only for Win32 clients where the debug output cannot be written to a terminal or redirected to a file. When tracing, each debug output message is appended to the trace file. You must explicitly delete the file when you are done."

Source: http://www.bacula.org/2.4.x-manuals/en/main/Bacula_Console.html

Well, that's more helpful than bacula-fd manpage: at least it mentions
the trace file. So where do the debug messages go with trace=0: syslog?
And what are the levels? -- 'cause I started bacula-fd with "-d 9" and I
got nothing in /var/log/messages.

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet

_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet

_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users