There are several reasons why attribute spooling is the way to go: 1. When spooling is enabled and the SD is on the same machine as the DIR, the spool file is not sent over the "wire"; it is read directly by the Director (i.e. zero transmission cost).
2. Spooled attributes are inserted in big blocks (25,000 I think) with a commit. None spooled attributes are inserted one at a time, each time there is comm line traffic and each time the DB must be locked and unlocked. If you have a small number of files the difference might not be noticeable on a well tuned DB backend, but with lots of files (attributes) the speed difference will be more pronounced. Best regards, Kern On 12/12/2016 02:45 PM, Josh Fisher wrote: > On 12/9/2016 3:22 PM, Kern Sibbald wrote: >> On 12/09/2016 09:15 PM, Josip Deanovic wrote: >>> On Friday 2016-12-09 07:47:03 Josh Fisher wrote: >>>> Also, pay some care to the physical disk drives that the db is using. >>>> Having the catalog db on the same physical disks that are also being >>>> used for Bacula's spool area can be very detrimental to performance. >>> Of course. >>> However in case of file storage the spooling option should be switched >>> off (IMHO) as it will yield significant decrease in performance. >>> >>> I doubt that there are many cases where data is coming at a rate that >>> would justify spooling in case of file storage (I don't think I have >>> ever stumbled upon such case). I would of course like to hear different >>> experiences on the matter if there are any. >>> >> Yes, that is very true. >> >> Ah, and something I completely forgot: always have Attribute Spooling >> turned on. If Attribute Spooling is not turned on putting the metadata >> in the catalog will be *very* slow. > Could you elaborate on that a bit as to why? Some time ago, I discovered > that I had jobs for which attribute spooling was inadvertently not > enabled. After enabling, I discovered that, while faster, it was not so > drastic a difference for the affected clients. I did not pay much > attention as to why at the time. It could be simply slow clients or it > could be the DB is "fast enough". (Postgres on Intel DC3600 SSD) > >> Best regards, >> >> Kern >> >> >> ------------------------------------------------------------------------------ >> Developer Access Program for Intel Xeon Phi Processors >> Access to Intel Xeon Phi processor-based developer platforms. >> With one year of Intel Parallel Studio XE. >> Training and support from Colfax. >> Order your platform today.http://sdm.link/xeonphi >> _______________________________________________ >> Bacula-users mailing list >> Bacula-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bacula-users > > ------------------------------------------------------------------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today.http://sdm.link/xeonphi > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
