ADSM-L

Re: DB & LOG Volume layout - new

2006-01-26 13:43:02
Subject: Re: DB & LOG Volume layout - new
From: Tab Trepagnier <Tab.Trepagnier AT LAITRAM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 26 Jan 2006 12:42:44 -0600
Lloyd,

My experience matches yours.

TSM 5.1.10.0 on AIX 5.2 on 2-way 6H1.

For the last several years we've implemented our DB vols on individual
disks, relying on TSM mirroring.  The disks were 18 GB SCSI disks which
each reported 50 MB/s streaming write performance on the outer edge.  We
defined four volumes per  physical disk to allow the disk/controller to
elevator-seek based on a previous thread on this topic a couple of years
ago.

Two months ago we redeployed some SSA-80 disks from our database system to
our TSM system.  I moved the TSM DB onto two 3-disk LVM stripe sets on the
SSAs.  Individual disk performance is about the same as the SCSI disks. I
spread the DB across eight volumes on each stripe set, still allowing TSM
to do the mirroring.

Then I compared performance running Expiration.  Unlike the old setup,
where each disk was hammered individually as TSM walked its tables, now
the I/O is evenly spread across the disks of the set.
The bottom line is that I/O Wait time was cut in half.  While expiration
still takes approximately the same time as on the old setup, the reduction
in I/O Wait time means the server has more cycles for other work.  So even
with a heavy workload, the server still provides very fast response time
and can manage dozens of  client sessions while doing expiration and
reclamation at the same time.

I would estimate that the increase in efficiency added at least another
year to the productive life of our server.  Maybe more.

Tab Trepagnier
TSM Administrator
Laitram, L.L.C.




"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 01/24/2006
01:48:15 PM:

> I've been watching this thread with interest, as some of the posts
> contradicted what I thought I knew.
>
> Using nmon, I've watched a couple of systems (AIX, TSM 5.2) running
> expiration and DBbackups that have the DB vols set up according to the
> "one volume per spindle" premise that appeared to have spotty "hot"
disks,
> that is the I/O was not distributed evenly across the different volumes.
> One drive would have a lot of I/O, then another, etc.
>
> I've always striped them, in hardware if it was available, and using LVM
> if it was not.  This gave fairly even I/O, but I admit that doesn't mean
> that it was the fastest method.
>
> I'd love to have a definitive answer here, because I've heard it both
> ways, and when I've asked support, they didn't seem to know.
>
> I'd like someone "piled higher & deeper" to give a conclusive
> answer...anyone?
>
> -Lloyd
[ snip ]

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