Well, our old tape library have four DLT7000 drives and it perfomed
differently in various OS. It can backup Unix in 15G/hour, Novell
10G/hour and Win just 4G/hour. I think the file number also play a big
role.
___________________________________________________________________
Shinn Wu | Email: shinn AT ssc.ucla DOT edu
UCLA Social Sciences Computing | Phone: (310) 825-4001
2041 Public Policy BLDG | Fax: (310) 825-4936
LA, CA 90095-1470 | Http://www.sscnet.ucla.edu/~shinn
_______________________________|____________________________________
On Thu, 18 Oct 2001, Anthony Soprano wrote:
> I have gotten 18GB/hr on DLT 7000 (over a very good 100MB/Full Duplex
> link-CAT5000 Switch)... So a local backup should meet this speed, IMHO.
>
> Try:
> 1. cleaning the drive a few times
> 2. tweaking NUMBER_DATA_BUFFERS & SIZE_DATA_BUFFERS (check this list and
> support site for more info on this)
> 3. If the data lives on more than one mount point, try enabling
> multistreaming and multiplex for this storage unit and this client. Change
> the class to allow_multiple_datastreams and increase the jobs_per_client
> (either globally or for this client specifically). Use a directive like
> "ALL_LOCAL_DRIVES" and DISABLE cross-mount-points, OR use explicit path info
> for each mount point you want backed up with the NEW_STREAM "keyword" in the
> directives list between each path listed.
> 4. Try new blank media, it could be your tapes are old or worn.
> 5. Make sure your SCSI cables are all VERY tightly connected on both the
> tape and SCSI Card sides.
> 6. Use shorter SCSI cables if possible
> 7. If disk stripping is setup with multiple volumes per disk-head-group,
> limit active jobs per client to 2 or 3 max. The disks with start thrashing
> and you'll worsen perf if you go higher...
> 8. You may also want to tune your Solaris system memory allocation in
> conjunction with #2 above. Veritas Support Site has info on this too.
> 9. Are you using a SCSI Differential Controller to connect the Tape Drive?
> 10. SCSI/FCAL Card placement on the systems bus(es) can affect performance
> if not properly distributed. I have mostly Compaq experience and it is
> recommended that RAID, Network, FCAL, etc, controllers get evenly spread
> across the buses so that the backplane can be fully utilized... In a white
> paper on their site, they mention performance improvements of up to 100%
> depending on the configuration (before and after). Similar tuning on a Sun
> box might help.
> 11. Make sure DEBUGGING is NOT turned on for this machine, which is acting
> as a media server, as well as on the master... This will add a HUGE
> overhead to the backups. The directories under /usr/openv/netbackup/logs
> should be removed, you can keep ./user_ops and ./admin I think, but ones
> like bpdbm, bptm, bprd, etc, should be removed or renamed.
> 12. To isolate the tape drive from the equation, you may want to play with
> the touch file that enables BACKUP_TO_DEV_NULL, so you can test system
> performance minus the drive... Be sure to set it back to the default after
> testing or backups will happen and NOTHING will get written to tape.
>
>
> My hunch is either debugging is on, the drive is dirty or you need to tweak
> Solaris system memory setting.
>
> Please let us know if any of these helped...
>
> A.S.
>
>
> -----Original Message-----
> From: veritas-bu-admin AT mailman.eng.auburn DOT edu
> [mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu]On Behalf Of
> benr AT cuddletech DOT com
> Sent: Thursday, October 18, 2001 3:36 PM
> To: erbilgic.ym AT pg DOT com
> Cc: veritas-bu AT mailman.eng.auburn DOT edu; benr AT cuddletech DOT com
> Subject: [Veritas-bu] RE: DLT 7K speeds
>
>
> No LAN here, this is direct connect. All the disks (6xA5200 FC) are very
> quick, and data is on striped volumes that are very very fast.
> Your right, my 401G is a database, and the database is DOWN so the files
> aren't changing and there is little activity to its disks outside the
> backup. We're getting ready to whack a database for good, but want a solid
> backup before we do.
> One of the concerns I have is, when I see that I'm getting "1500k/s" to the
> drive, that makes me think this is a throttle somewhere. If that number was
> based on disk-to-tape performance I'd get an akward number that would keep
> changing, eg 2433k/s. The perfectly rounded number makes me think that
> something is limiting. And there is no "Limit" type statement in my bp.conf
> or vm.conf.
> There are no real bottlenecks (I designed the system with that in mind), and
> certainly none that would slwo the tapes to 1500k/s, but I'm a disk guy, not
> tape.
> And yes, this is a 3day backup. At 1500 today, we'll be moving into day 3
> of the backup. It should be done in roughly 30hours. Now that is lame.
>
> benr.
>
>
> > Hi Benr,
> >
> > DLT 7000 speeds should be about 15 gigs/hour. 4-5 megs/sec. I would
> > like to ask you if you are using a drive that is attached to this 400
> > gig server or if you are actually going trough a network.
> >
> > If network, then I would check the network utilization. (E.g. is the
> > bandwith shared etc? )
> >
> > With the speeds you are seing (it would take 3-4 days to backup the
> > data), if this is a production database and backed up trough the same
> > network as production data uses, this could explain your problem.
> > If this is on a different lan segment, then I would check the switch
> > speed and duplex settings (Auto negotiate on-off etc) and match them
> > with my server.
> >
> > Also there is a way to slow down your backups with a bo.conf parameter
> > limit badwith or something like that.
> >
> > If this is over SSO e.g. direct connect tape drive, I would check my
> > subsystem utilization v.s. backup speed, if there is no bottle neck
> > there, try scsi connections, and drive it self (we have had drives that
> > were slow until they were replaced). (perhaps do a direct tar to the
> > drive and see what speed you get, compare it with the netbackup speed
> > etc).
> >
> > I hope this helps,
> >
> > Yucel
> >
> > ---------------------------------------------------------
> > Yucel M. Erbilgic
> > erbilgic.ym AT pg DOT com
> > (513) 945-1859
>
>
>
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
|
