"Cook, Dwight E" <cookde AT BP DOT COM> writes:

> due to the way adsm/tsm internally manages "stuff" it is best to have one
> logical file/device per physical device.

I've currently been trying to find bottlenecks in our database. When
we do a restore from a rather large filesystem (about 25,000 home
directories at the top level), our ADSM server thrashes the db disks
for a long time (20-40 minutes). During this time, the client appears
hung (won't redraw in X, etc.). Eventually, the server finishes
building its list, and the restore completes quickly (appears limited
only by the ability of the tape library to mount and unmount tapes).

There is no problem with restores on smaller filesystems. These
proceed quite quickly.

This message jumped out at me, becuase we have multiple db volumes on
each disk. We've just been adding new volumes in smaller chunks as
we've needed more db space. Have we been shooting ourselves in the
foot? Would we be likely to see much of a performance improvement by
moving to one db volume per physical disk?

> if you want to get really anal you can start splitting things (db, log, &
> data files) across adaptors, making db & log files the first device out on
> an ssa loop, then put the db & log mirror files out on a different adapter
> (on maybe a different buss within the processor)
> ok, I'll shut up now ;-)

How much benefit can be derived by throwing SCSI controllers and/or
disks at the problem? We're looking "down the road" at a
replacement for the current ADSM server, and this is one of the
questions -- how much SCSI do we need?

The traditional answer of throwing lots of disks at the problem seems
rather silly these days, when a small disk is 9GB and you have a 5GB
database.

Geoff

--
Geoff Allen, geoff AT wsu DOT edu, <http://www.wsu.edu/~geoff/>
Geoff Allen, geoff AT wsu DOT edu, <http://www.wsu.edu/~geoff/>

It's happy music for happy people. If you like bluegrass you gotta be in
a good mood.  -- Dave Winer