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
|
