As with any "cached" I/O subsystem technology (i.e. RAID-S, NetApps, etc),
please visualize a water tank. The water tank represents the cache, the
drain from the tank represents I/O throughput rates from the cache to the
hard-drives, and the faucet filling the tank represents the I/O volumes from
the server to the I/O subsystem. The faucet filling the water tank is on a
valve, so that when the tank is full, it does not overflow. Let's say that
the water tank holds 100 gallons (about 400 liters???). The faucet filling
the water tank can vary its rate, anywhere from 1 gal/min to 30 gals/min.
The drain from the water tank operates at 5 gals/min and can not be blocked
or closed.
Got that pictured in your mind? Now for some scenarios...
1) What happens when the faucet is filling the water tank 24x7 at a rate
of 1 gallons/minute? No problem -- the tank never fills, so the flow into
it is never impeded...
2) What happens when the faucet is filling the water tank 24x7 at a rate
of 5 gallons/minute? Still no problem -- the tank never fills, so the flow
into it is never impeded...
3) What happens when the faucet is filling the water tank 24x7 at a rate
of 6 gallons/minute? Uh oh. In less than two hours, the water tank will
fill, causing the flow of water to be limited to the output rate of 5
gals/min. Too bad, because we really need to move 360 gallons/hour, or 8640
gallons/day, through this system...
4) What happens when the faucet is filling the water tank for an hour at
10 gallons/minute for 15 minutes, then at 1 gal/min for the next 45 minutes?
Not a problem -- the capacity of the tank was able to hold the excess input
rate during the first 15 minutes, and whatever accumuated was drained off
before the next "spike" or surge...
5) What happens when the faucet tries to run for an hour at 30 gals/min,
then 11 hours at 1 gal/min? Uh oh again. We were only able to run at 30
gals/min for about 4-5 mins, and then the flow rate got cut back to 5
gals/min for the rest of the hour. We really wanted 1800 gals to go through
the system during that hour, but it actually took 6 hours to get all 1800
gallons through; too bad...
Sorry for the silly analogy, but that's how my brain works...
----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Tuesday, October 29, 2002 9:58 AM
Russ:
We're using EMC Clariion disk arrays. These are using EMC's version
of RAID-5; they call it RAID-S. There is 2GB of cache if front of
the disks. They claim that the cache is write guaranteed so that
we'll never lose an update. So far, so good, and the performance
has been acceptable, except (you knew this was coming, huh?) when
we do large file moves from one tray to another, or when doing a
refresh of our SAP stage system. This activity kinda buries the
internal bus as well as the fiber, so that other users suffer.
I guess to make a short answer even longer, this RAID-S technology
seems to work a lot better than RAID-5 used to.
Remember, though, YMMV.
Cheers,
Mike
-----Original Message-----
Sent: Monday, October 28, 2002 5:24 PM
To: Multiple recipients of list ORACLE-L
Hi,
I just got forwarded a whitepaper from Hitachi and Oracle, that compairs
raid 5+ and raid 1 using the TPC-C benchmark test suite. The claim is that
raid 5 is as fast or faster. While I'm waiting for a comparison or raid 5+
with raid 0+1, I thought I'd take a poll with the list. The benchmark is
using the Hitachi 7700E.
Has anyone heard other recommendations attributed to Oracle that are
pushing raid 5+ as the configuraton for "unrivaled performance"? Has new
disk technology changed the general conception that raid 0 or 0+1 provides
better performance than other raid levels?
Thanks,
Russ
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Brooks, Russ
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Vergara, Michael (TEM)
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Tim Gorman
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
