=> On Wed, 3 Nov 1999 14:21:17 -5, "Richard L. Rhodes" <rhodesr AT
firstenergycorp DOT com> said:
> On 3 Nov 99, at 16:31, John Schneider wrote:
>> For some of our smaller client backups, we could send the data to a
>> disk pool, then migrate it to tape, but that doesn't really cure the
>> problem, since then a disk pool volume reading at 9MB/sec is trying to
>> drive a 36MB/sec drive, which can't keep it busy. [ ... ]
> The only way I know of to increase the speed of a disk subsystem for
> sequential i/o is to strip the data across multiple drives. [ ... ]
And keep in mind, this does not have to be a true striped filesystem. To
refine your statement, "To increase the speed of a disk subsystem, use more
spindles"..
Now, you can do that very simply in ADSM: define your filesystems and storage
volumes in such a way as to guaruntee which spindle gets each volume. Then
assign volumes to stgpools in such a manner as to use many spindles.
For a concrete example:
My ADSM storage pool disk is 6 9G SSA drives. I tossed them all into an AIX
logical volume. Then I defined filesystems, one per spindle. I named them
for the hdisk in question, so I have (for instance)
/export/data/02
/export/data/07
.
.
/export/data/13
(Don't ask about the skips. :)
Then I defined several storage volumes on each filesystem.
A - 4G
B - 2G
C - Whatever was left ( ca. 1.7G )
Then, I assigned each stgpool such that there were never two volumes in one
stgpool on the same spindle.
If I had wanted to be amazingly anal about it, I could have analyzed my disk
needs in advance, and then made N volumes, N=stgpools, each proportional to
the need. I decided this was overengineering. (sigh... I _like_
overengineering)
>> And we nightly back up a 400GB database, so we have to go directly to tape
>> for that backup, we can't throw 400GB of intermediate disk pool at it!
>> Would even a small amount of disk pool help?
If you've got a 400G stream you toss to tape every night, nothing less than a
400G disk pool will really help you. You _really_ want to avoid writing to a
disk pool at the same time you're migrating off it (because, for instance you
filled it up); contention city.
I'm confident I wasn't saturating a 3590C with a single stream from DB/2, but
I did get faster performace when I set up two streams. Have you really really
proven that there's not some other bottleneck?
Allen S. Rout
|
