On 08/06/17 03:24, Kern Sibbald wrote:
> Hello Phil,
> Thank you for your comments, and I am pleased that you have found a 
> solution for your batch insert problem.  Unfortunately, I cannot apply 
> the patch to a released version two days before I go on vacation.  Nor 
> will I change the default.
> If you can show me solid statistics on a Linux system that for the most 
> current MySQL inserting between 20 and 50 million records in a single 
> job is slower with batch insert than without it, I will ask the authors 
> of the code to take a look at it or at least explain.  Otherwise, I 
> trust their judgment.  That said, it may well be for smaller workloads 
> and a properly tuned MySQL it could be more efficient to do normal inserts.

I can't meet that criterion because I don't have a job that large to
test against.  My largest job has just under three million files.  And
to be fair I just switched out my main NAS for a more powerful system;
that could easily be the reason for the better performance on
incremental backups.  I can say that large jobs run with steady
incremental writes to the DB throughout the job instead of the massive
choke-a-hippo attribute despool at the end of each job.

Community request:
Does anyone else here have a test environment which DOES have jobs of
that size who could perform comparison tests of the same 20-50 million
file backup job with and without batch insert?

  Phil Stracchino
  Babylon Communications
  Landline: +1.603.293.8485
  Mobile:   +1.603.998.6958

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Bacula-devel mailing list

Reply via email to