ADSM-L

Re: Slow restoratoins when large backups are happening?

2005-10-25 09:50:00
Subject: Re: Slow restoratoins when large backups are happening?
From: Leigh Reed <L.Reed AT MDX.AC DOT UK>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 25 Oct 2005 10:40:55 +0100
Matt,

I'm in agreement with Troy's posting below. If you are seeing high i/o
wait on your TSM database volume(s), then this is a good contender for
the root of some/all of your problem. The interesting point is your post
says 'volume' singular.

I would be a good idea to get your database spread across as many
physical disks as possible and preferably on a different controller and
different bus to that which is handling your diskpool and tape
operation. If your server is from the Unix world, then consider using
raw disk for your DB volumes instead of a filesystem. Try to configure
TSM db volumes the same size as you have configured the raw disk. If you
can afford 15Krpm disk then go for this.

A 'possible' configuration for TSM database disk layout could be a
separate SCSI attached chassis of 12 x 18GB 15Krpm disks. Only configure
each disk with a raw partition of 4GB starting from the outermost sector
(ie limit the head movement). Configure TSM for 12 x 4GB db volumes. If
using TSM s/w database mirroring, consider duplicating the above
arrangement on a separate controller.

I appreciate that there is wastage here but it IMO it's worth it, if
better performance is required. The main thing is to get your DB spread
over as many physical spindles as possible, if RAW disk is an option,
use it. Configure TSM db volumes equal to your physical partitions and
use the outer most sectors of the disk where possible.



Leigh


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Troy Frank
Sent: 24 October 2005 21:35
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Slow restoratoins when large backups are
happening?

What's the layout of the db volumes?  ie. how many dbvol's do you have,
and how many arrays/spindles/controllers are they spread out across?
The other thing I forgot to ask before was what OS the tsm server is on.
Another thing to look at is what your db cache-hit percentage is.  Could
be there's a lot of disk contention due to insufficient db buffering.


Troy Frank
Network Services
University of Wisconsin Medical Foundation
608.829.5384

>>> matthew.glanville AT KODAK DOT COM 10/24/2005 2:58 PM >>>

> There's also performance internal to the tsm server to consider.
> The large server backups could be monopolizing your network
> throughput, scsi card throughput, pci/pci-x bus throughput, or some
> combination of all the above.
>

System performance monitoring shows hardly any network I/O during this
situation.
After all there is incremental backups running, it's not backing up
much.
On the restorations, it was 10,000 files for 8 GB.  again not much.

One issue I have seen is high i/o wait on the TSM database volume, which
is why I know I have a database I/O issue, but, cancelling the larger
backups should not cause the restoration to suddenly jump from sending a
few hundred mb per hour to a gig every 5 minutes.  Which is why I think
it's an internal TSM issue and not a hardware performance issue.  But
maybe it is. I Just need more input into what to look for.

Matt Glanville



Confidentiality Notice follows:

The information in this message (and the documents attached to it, if
any)
is confidential and may be legally privileged. It is intended solely for
the addressee. Access to this message by anyone else is unauthorized. If
you are not the intended recipient, any disclosure, copying,
distribution
or any action taken, or omitted to be taken in reliance on it is
prohibited and may be unlawful. If you have received this message in
error, please delete all electronic copies of this message (and the
documents attached to it, if any), destroy any hard copies you may have
created and notify me immediately by replying to this email. Thank you.

<Prev in Thread] Current Thread [Next in Thread>