Thank you for the response! On 10/17/05, Mark Bober <[EMAIL PROTECTED]> wrote: > > I get about ~20 MB/s from my fastest storage, so that's 1200 MB/min, or 1.2 > GB/min. You're > pulling 300MB/min, or 5 MB/s.
I thought so, thanks for verifying my sanity. > So you might be a touch slow. I have a maximum of 4 jobs running on any given > storage device, > however, and usually during fulls on the weekend I've got no more than 4 jobs > running at any > given time anyway. I was thinking of limiting the number of concurrent jobs. The project manager really wants to have them all done simultaneously, not 100% sure on the reasoning, but it is listed as a requirement. If it has a large negative impact on performance, I'm sure we can drop that requirement. > Here's my setup: > > bacula-dir: Sun v20z (dual Opt, 4g ram) running CentOS 4.1 (RHEL clone). > > Tape Storage: Either Quantum SDLT/160 Autoloader or Overland LXB SDLT/110 > changer for > large jobs, hanging off an U320 MPT SCSI PCI-X controller. > > My spool device is a set of random SCSI disks, mostly old 50 giggers, in a > striped software raid. > About 400G. They're on a PCI 33mhz controller, a Symbios something-or-other. > Nothing special. > > All gigabit to major servers. > > All in all I've got about 80 clients, Windows, Solaris, and Linux. A few > OSF/1 also. I've ran about > 3500 jobs, and have totalled about 17 TB over the past... 2 1/2 months I've > been production with > Bacula. > > (I secretly hope that wins me some sort of "Biggest Bacula" award) :) Anyone have any statistics to top it? > Suggestions: > > 1) Solaris storage-d was *very slow*. It's Solaris's fault. Try a linux > storage-d, see what happens. > My Linux clients always outpace everything else, even given the same > hardware. Go ahead and > shoot for 1.37.40 as well. OK, wasn't sure how stable that release was, but since I'm still in testing mode, it doesn't really matter. I'll give it a go. > 2) It's Virtuozzo, also. I've got a set of VMWare ESX servers, same hardware > as the director. They > go about 5 MB/s to disk, which GZIP compression on, when I'd expect 20 MB/s > from a plain Linux > install without GZIP. Not much can be done about that, really. (this is the > VMWare itself - the linux > underpinnings, not the virtual machines, backing up). If those 65 virtual > machines all have load > on each server, I'm amazed they're that fast at all. None of the clients are vps's themselves. Just hosting vps's, so I guess I could have left that out of my original message. They are the main cause of the large amount of data. > If you're backing up to disk, drop GZIP once and see how it goes. If you're > going straight to tape, > you're pretty much at the limit then. That's a lot of virtualization. Yep, to disk. I forgot about the gzip compression, thanks for reminding me. I appreciate the suggestions! Lyle ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
