Thanks a bundle, Troy, you definitely gave me plenty to start with. > I suspect the list guru's probably will want more info as this output > doesn't give any real indication of where the problem might lie.
I suspect you're right. > For starters, I'd provide the output from a completed full job. > The output you provided is for an incremental, and indicates that your > system took 28 minutes to search your entire server (the size of which > we have no idea) to locate just under 30Mb of data that was eligible for > backing up. I'm guessing most of this time was taken in the search not > the backing up. What rates are you getting for full backups? Hmm...You're probably right about this. I'd noticed that the Full backups got a generally better speed, but I'd never connected it with searching for data to back up. I actually have not run a full backup of any considerable size since I upgraded, so I'll have to get back to you on Sunday for this. > The best way to track down bottlenecks is try and narrow the search. > Whilst a backup is running use something like 'top' to keep an eye on > the director, storage daemon, and database processes and see if any of > them seem to take significant CPU hits. Also, check your iowait (It > should be shown in the top header lines, probably as 'io%' or similar) - > if that's high, it's an indicator your disk writes are the issue. Good advice, I'll take a look at it. > Are you backing up multiple jobs at once? This can hammer your disk IO. No. > What sort of speeds do you get from backing up the director/storage > daemon? If these are faster, you might have networking issues. I'm not doing much backup of the machine with the director/storage daemons; just the catalog. For that, I see speeds around 7.8MB/s whereas for the incremental backups of my file server the speeds range from 10-2000KB/s, depending of the file set. This is probably the search issue you mentioned above. Looking at the previous full backups of the file server (using 2.0.3) I'm seeing speeds of around 6.9MB/s. > Is the database server and storage daemon using the same disk at the > same time? I don't believe so. I think the database lives on a different disk. > Are you using data spooling, or at least attribute spooling. I'm > probably wrong, but suspect the new batch insert code only works if the > attributes are being spooled first. I've not managed to upgrade yet, and > dont have any way to test this theory tho so hopefully someone else on > the list can confirm or deny this please. I'm not doing data spooling, and I don't believe I'm doing attribute spooling unless it's turned on by default. > And finally, what spec are your servers? Both director and client ones. > Oh and Storage and database if they're separate beasts as well. What > database server are you using? My server is a Gentoo Linux box with a single 2.8GHz Pentium 4 processor. It's connected to a hardware RAID5 by fiber channel and the network by gigabit ethernet. The storage disk (the RAID is done in hardware) is set up with evms. The client is the same except the disks being backed up are hardware RAID configured as three separate disks through evms. > If you provide this information, you have a much better chance of > someone on the list being able to help you, or at least of being able to > point you in the right direction. Thanks again, Troy, you've been a big help. ~Kyle Marsh ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
