Bacula-users

Re: [Bacula-users] Job transfer rate

2014-10-30 11:19:41
Subject: Re: [Bacula-users] Job transfer rate
From: Bryn Hughes <linux AT nashira DOT ca>
To: bacula-users AT lists.sourceforge DOT net
Date: Thu, 30 Oct 2014 08:17:18 -0700
On 14-10-30 07:50 AM, Jeff MacDonald wrote:


Tips/Suggestions?

Jeff.

What is the content of your backups?  Some things (ie thousands of tiny 
files) will cause a lot of seeks on the machine to be backed up.  If you 
aren't using attribute spooling then each backed up file also causes a 
record to be inserted in to the database, which may take time depending 
on your DB environment.

The 'suggestions' for tuning will be different if you are backing up a 
few dozen 10GB files versus backing up a million 10kb files.

Its mostly a windows os, with all its sundry smaller files and a few larger database dumps etc.

I guess what I have to accertain is the slow part getting the data FROM the servers or the slow part putting the data TO the storage.

I’m not sure which value the rate is in the job report, or if rate is somehow encompassing both.

jeff

The job report rate will be the final average rate of the job, it doesn't know/specify the difference between the 'input' rate and the 'output' rate.

Yep, you're going to need to do some investigation on the storage side of the VM machine you are backing up, the director itself, the storage daemon itself (though I'm guessing it is on the same system as the director for you) and the final storage.

Also it's not quite clear from your description, is the final storage on a different NAS all together from your VMs? (hoping so!)  What virtualization platform are you running?

Finally the question about attribute spooling is a big one - if you are backing up a lot of small files and you do not have attribute spooling turned on, you will have abysmal performance especially if the director is running on the same disks that you are backing up. 

Database writes are (almost) always synchronous writes, meaning the system will stop and wait for the storage layer to say "yes the data is ACTUALLY committed to disk" before proceeding.  If you are seeking all over backing up a bunch of small files, then trying to do a whole ton of tiny DB writes at the same time to the same spindles your hard drive heads are going to be flying around like crazy.  An array of 7200 RPM disks in any sort of parity RAID configuration will not be able to handle more than 50-90 random IOPs (Operations per Second) at best in real life, with a DB write or a file read counting as an IOP.  If you are backing up lots of small files randomly distributed around the storage you are quite likely hitting an IOP wall - an IOP to read the file and an IOP to write the DB record means not more than 25-45 files per second.  4kb files = 100-180kb/sec and a completely maxed out storage layer.

Even WITH attribute spooling enabled you are still going to be in a less-than-ideal position since the spooled attributes still need to be written to the same spindles with the hardware configuration you've described. 

Bryn


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