T.R | Title | User | Personal Name | Date | Lines |
---|
1537.1 | Sounds good to a layperson | IOSG::TALLETT | Arranging bits for a living... | Thu Oct 01 1992 09:52 | 10 |
|
I don't see why it wouldn't improve performance. I would expect
striping to give you more than shadowing, and both to give you more
than either one. I suppose it depends on whether that is their
bottleneck.
Maybe a performance expert will give you a better answer.
Regards,
Paul
|
1537.2 | For the uninitiated... | SCOTTC::MARSHALL | Do you feel lucky? | Thu Oct 01 1992 10:41 | 3 |
| ...what is disk striping please?
Scott
|
1537.3 | Striping (not to be confused with Stripping! :-) | IOSG::TALLETT | Arranging bits for a living... | Thu Oct 01 1992 10:53 | 21 |
|
Over simplified, you bind a set of disks (say 3) together,
then write consecutive blocks on different disks. So block 1 on
disk 1, 2 on 2, 3 on 3, 4 on 1 etc... That way you have a logical
disk 3 times as big, and you can simultaneously post 3 reads (or
writes) when you want 3 blocks and it will (theoretically) complete
in a third of the time on average.
The VAX/VMS striping driver just sits on top of the regular disk
drivers and splits the I/Os.
It has been used for years on Crays with washing machine sized
disks, but is gaining popularity with small diameter hard disks.
Its also one of the RAID levels. WNT has it too. You can also build
in redundancy by adding a redundant disk which allows any one
disk to fail, and its data can be recreated from the remaining
members.
Regards,
Paul
|
1537.4 | | MRKTNG::SLATER | Marc, ASE Performance 264-6309 TTB1-1/E09 | Fri Oct 02 1992 05:35 | 41 |
| For striping to be successful, you must evaluate the following:
1) Is disk I/O limiting system performance? If not, it will
not be beneficial.
2) Can any I/O problems be resolved through RMS tuning (bucket
sizes, private and global buffers, block size)? This is
the first skirmish line in dealing with any I/O performance issues.
3) If striping is being considered to due to the size of SDAF
(to spread SDAF over 2+ disks), it is probably cheaper to buy
one larger disk than to use two+ disks, two+ controller
channels.
4) New disk technologies (RF35, RF73, and RA?? coming soon) offer
large capacity, really hot performance, at very competitive
prices (The customary 'throw hardware at the problem' answer).
5) The more disks involved in a stripe set, the lower the mean time
between failures (more inter-dependent components, more failures).
Stripe sets can be shadowed, if you've got the disks or money.
6) Striping performance is sensitive to the disk geometry, striping
chunk size (striping uses chunks, not blocks), and disk controller
layout. The premise is that striping allows multiple parallel
I/Os to be directed to multiple members of the stripe set. In
order to be effective, the disks should reside on multiple
controller channels. For reads, this may provide lower seek times,
and for reads or writes, higher bandwidth.
7) Striping is most effective when I/O sizes are large. Most I/Os
to interactive time-shared systems are small. I/Os to SDAF fall
into the small category.
In summary, striping is not a magic bullet, but can be useful in solving
I/O or space problems after careful consideration.
Regards,
Marc
|
1537.5 | Disk Space | AIMTEC::BUTLER_T | | Fri Oct 02 1992 19:35 | 16 |
| Just to re-inforce what Marc wrote.
In April I worked with Pacificare Health Systems and last week I
did a follow-up call with them.
They have had no problems (small ones at the begining with MCI mail)
and have seen no increase in overall response time.
What they are happy about is "disk space." They are a large cluster
with a large number of ALL-IN-1 users. Heavy mail, etc..
They had tunned their buckets, and I/O was attribited to spindle
disk space problems. We went throuh lots of discussions on what
disk stripping would give them and the one perception they had going
in was I/O size.
Tim
|
1537.6 | | MRKTNG::SLATER | Marc, ASE Performance 264-6309 TTB1-1/E09 | Fri Oct 02 1992 21:17 | 30 |
| Ken Bates' comments:
<<< COOKIE::DISK$SYSTEM_3:[NOTES$LIBRARY]STRIPING.NOTE;1 >>>
-< >-
================================================================================
Note 305.6 Disk STRIPING and ALL-IN-1 6 of 6
EYLAK::BATES "Ken Bates" 21 lines 2-OCT-1992 07:19
-< Slight correction >-
--------------------------------------------------------------------------------
> 6) Striping performance is sensitive to the disk geometry, striping
> chunk size (striping uses chunks, not blocks), and disk controller
> layout. The premise is that striping allows multiple parallel
> I/Os to be directed to multiple members of the stripe set. In
> order to be effective, the disks should reside on multiple
> controller channels. For reads, this may provide lower seek times,
> and for reads or writes, higher bandwidth.
The disks only need to be on different controller channels if the I/O sizes are
large. For "typical" I/O sizes, the contention caused by multiple outstanding
transfers is negligible.
> 7) Striping is most effective when I/O sizes are large. Most I/Os
> to interactive time-shared systems are small. I/Os to SDAF fall
> into the small category.
Actually, the main benefit of striping is load balancing. Load imbalance
usually occurs with applications that have many small requests outstanding.
Data rate may be increased with *very* large I/O's, but this is very atypical.
- Ken
|
1537.7 | Throw hardware at it | IOSG::TALLETT | Arranging bits for a living... | Mon Oct 05 1992 20:40 | 7 |
|
I think "Buy faster disks" rather than stripe is good advice. It
reminds me of my VMS tuning days where "Buy a faster VAX" was
usually better advice than tuning.
Regards,
Paul
|