On Sunday, Apr 13, 2003, at 01:10 Australia/Sydney, asr AT UFL DOT EDU wrote:
=> On Sat, 12 Apr 2003 13:34:58 +1000, Paul Ripke
<stixpjr AT BIGPOND.NET DOT AU> said:
My gut feel (and the advice from an IBM TSM support guru here in
Australia) is to have 3 or 4 volumes per spindle for database disks.
Those "spindles" may be logical RAID5 arrays as in a shark, etc.
I guess we need terms of art here to be clear. In my neck of the
woods, when
we say 'spindle', it is to distinguish one set of platters inside one
disk
from another. Really, really, I mean "spindle".
:)
Point taken. My definition of a spindle, I suppose, relates more to
heads.
And also becomes dependent on application - specifically I/O size. 5
disks
in a stripe (RAID0), where the I/Os are small enough to only hit single
disks, is 5 spindles. If the I/Os are big enough to hit more than one
disk, it's 1 big spindle. This is where the black art tuning of RAID
block
sizes comes in...
If it's a RAID construct, then it's not a spindle, it's a volume or
something.
And if it's a volume on a shark, then all bets are off: you're writing
to
remote core.
Actually, I'm more interested in reads. And from experience, the Sharks
RAID block size is small enough that, to Oracle, each RAID5 set is a
"spindle" in my terminology. That is, 6 heads must move to satisfy a
read (from memory, the last Shark I had anything to do with had 7
disks live in RAID5 with an extra hot spare - 8 disks per set total).
The reason, is to allow 3 or 4 outstanding requests to each disk,
which the
disk can then re-order to minimise over-all seek times. Since the TSM
DB is
primarily hit with random read I/O, this *should* be a win.
Which is precisely why, if you are arranging one TSM volume per
spindle, you
don't want two or more competing queues of operations, be they read or
write.
No, not necessarily - 10 I/Os processed one-by-one through one queue to
one disk should be slower than the same 10 I/Os issued fast enough such
that the disk can reorder the I/Os to minimise seek times.
This was part of the reason why some Unices have disk geometry stored
in the disk labels - they were there to optimise file system layout,
and also allowed the kernel to re-order requests to minimise seek times.
Several algorithms were used - shortest seek first, the elevator, and
one-way elevator. Try a Google search on "disk scheduling". The only way
these algorithms can come into play is if multiple I/Os are outstanding.
Any disk that supports command-tagged queuing implements one of these
algorithms.
Cheers,
--
Paul Ripke
Unix/OpenVMS/TSM/DBA
101 reasons why you can't find your Sysadmin:
68: It's 9AM. He/She is not working that late.
-- Koos van den Hout
|
