robm@ilap.com (Rob McKenzie) writes:
>You both bash RAID 5, and unfortunately the box we have has nothing but on it.
>I'd like to know what symptoms pointed you at RAID 5. This is an Alpha VMS
>box, and we seem to be I/O bound alot. Lots of cycles left, but were doing
>lots of page faulting, and at mountain of I/O in an app that has very little
>set oriented work done in it. Lots of single record reads and writes.
>
>I'll admit we still have some work to do in the DB, but I'd like to know
>whether our biggest problem may be the RAID 5 sets.
There are a few RAID Storage Arrays that perform very well. One of them
is a newer DEC array (the last one that I saw had the wierd three channel
controllers). Large caching controllers do wonders for RAID (provided you
don't have a controller failure (since most hardware implementations have
controller redundancy) or your battery backup does not fail). If you have
a "good" raid box (which is the minority from my experience) then
performance will be almost as good as fast non-raid devices.
Are you doing hard or soft faults? How much RAM does the Alpha have?
Alphas love memory (just like UNIX machines), but many VAX type people
don't think that .5 GB or more RAM could every be utilized (because the old
CISC chips seemed to manage it better). A good Sys Admin (or Consultant)
could probably probably help identify and correct specific problems.
>
>Thanks for any info you can give me,
>--
>Rob McKenzie
>Independent Ingres Consultant
Below is a dumb little program that I wrote years ago in response to a
Client who told me that "Ingres does not know how to use RAID". I tried to
explain that I/O performance was a function of the OS & hardware, but they
did not believe me until I ran a totally non-Ingres test which showed a
100% performance degradation on writes. Something like this is the best
way to determine if you have a disk performace problem (although it does
not really test the overall bandwidth).
You will need to convert the shell script to a command procedure.
::::::::::::::
putline.sh
::::::::::::::
#!/bin/ksh
! Collect runtime statistics (OS only) for filesystem test. Should run
SAR or IOSTAT
! while this test is running to look at disk write efficiency.
X=0
while true
do
X=`expr $X + 1`
# Create a 20 MB file in the current directory
timex /home/chipn/put_lines 10000 pl.out
ls -l pl.out
# break out of loop after twenty five times
if [ $X -eq 25 ]
then
break
fi
done
::::::::::::::
putline.c
::::::::::::::
#include
/* put_line.c A simple C program to write lines to a file. This was written
** in K&R C because an ANSI C
compiler is not available on all
** platforms. This program was
written to test the write
** performance of filesystems (e.g.,
internal vs. external,
** RAID vs. non-RAID). Results of
these tests are a function of
** the OS and Filesystem(s), NOT of
Ingres).
*/
main(argc, argv)
int argc;
char *argv[];
{
/* Declaration */
int num_lines, cur_line;
char line_text[2048] = "\n";
FILE *fp, *fopen();
if (argc != 3)
{
printf("USAGE: put_lines NUM_LINES FILE_NAME\n");;
exit(1);
}
/* Initialization */
memset(line_text, "X", sizeof(line_text));
num_lines = atoi(argv[1]);
/* Open the output file */
if ((fp = fopen(argv[2], "w")) == NULL)
{
printf("unable to open file %s\n", argv[2]);
exit(2);
}
/* Perform the test */
cur_line = 0;
while (fprintf(fp, line_text) != EOF)
{
++cur_line;
fflush(fp);
if (cur_line == num_lines)
{
break;
}
}
fclose(fp);
}
Chip Nickolett ChipN@Comp-Soln.com
Comprehensive Consulting Solutions, Inc. (www.Comp-Soln.com)
Phone: 262-544-9954 Fax: 262-544-1236
I could go on and on. Here are the four main points:
1) Writes are slow. Period. Cache-be-damned. Nobody can cache
enough for a database. Writes are VERY slow. Only a RAID vendor
will disagree.
2) RAID 5 is unreliable because it is too complicated and nobody
implements it correctly. Raid vendors will tell you that I
am full of ****, so listen to them if that's what you want
to believe. I've seen too many clients get burned by RAID 5.
3) RAID is WAY too expensive. You usually pay $1500/GB, after all
is said and done. Maybe more. Raid vendors can confirm this,
just ask for a quote.
4) I've never lost a byte using host-based mirroring. I get better
performance reading and only a slight hit over naked drives for
writing. The software is mature, proven, and cheap. The hardware
is generic and VERY cheap ($250/GB, max).
I went on an on about this in a previous post. You could probably
find it on DejaNews.
Cheers,
Michael Leo mleo@cariboulake.com mal@visi.com
Caribou Lake Software http://www.cariboulake.com Java/RDBMS/Ingres Solutions
>From: Michael Leo
>I could go on and on. Here are the four main points:
>
> 1) Writes are slow. Period. Cache-be-damned. Nobody can cache
> enough for a database. Writes are VERY slow. Only a RAID vendor
> will disagree.
Sorry to disagree Mikey (I don't work for a RAID Vendor, honest), but I
have benchmarked RAID 5 arrays that have exhibited a mere 5% performance
hit on writes. Unfortunately, I have only seen this twice and is the
exception (based on my experience) rather than the rule. It is possible to
get good RAID 5 performance, but it is very expensive.
Most RAID vendors will claim anything from a 0% to a 20% performance hit
on writes. From my experience the guys claiming 20% are generally in the
50%-100% range (which is terrible). Never believe marketing brochures.
Run a simple benchmark (like my earlier post) and find out for yourself. I
have never been able to prove a read performance with RAID 5 (most vendors
claim a 5%-20% read increase).
It is imortant to remember that the I/O subsystem is the slowest in the
computer. The goals for performance are to minimize I/O and then maximize
the performance of that I/O. Run 'sar -d' and analyze the overall average
response time (avwait + avserv). While a 20% performance hit sounds bad,
if you are are averaging 5 ms I/Os (seeing 4-8 ms average I/O response is
not too unusual anymore) then 1 ms more is not that terrible. If you are
averaging 20+ ms I/Os then any additional delay is bad. Everything is
relative.
>
> 2) RAID 5 is unreliable because it is too complicated and nobody
> implements it correctly. Raid vendors will tell you that I
> am full of ****, so listen to them if that's what you want
> to believe. I've seen too many clients get burned by RAID 5.
I have also seen people placing too much faith in RAID devices, which has
caused them expensive downtime. Just because you are using RAID does not
mean that backups are no longer important. Most of the failures that I
have seen fall into one of three categories: power problems (primary power
supply and backup supply), controller problems (redundant controllers not
used, or redundant channels used but both channels are on the same
controller); more than 1 disk failed at a time (or the service guy replaces
the wrong disk). Nothing is perfect. The business goal is to minimize
risk (loss of data, loss of service, etc.) and performance sometimes takes
a back seat to this reality. If a vendor promises that there will never be
a failure, get it in writing. If they are unwilling to provide this (I
would bet a lot of money that they would be), then assume that it will fail
(sometime) and plan accordingly.
>
> 3) RAID is WAY too expensive. You usually pay $1500/GB, after all
> is said and done. Maybe more. Raid vendors can confirm this,
> just ask for a quote.
>
> 4) I've never lost a byte using host-based mirroring. I get better
> performance reading and only a slight hit over naked drives for
> writing. The software is mature, proven, and cheap. The hardware
> is generic and VERY cheap ($250/GB, max).
Many sites go with RAID 5 because it is less expensive than mirroring.
These are generally sites with 80-200 GB of disk. RAID 5 only has 20%
overhead for "wasted" disk (as opposed to the 100% for disk mirroring).
The storage array (box, power supplies, etc.) usually costs as much or more
than the disk inside which can significantly increase the cost of mirroring.
Software mirroring is a lot more flexible than hardware mirroring, but
there is also more overhead. With today's fast processors this should not
be as much of an issue. My guess is that the biggest problem would be
convincing a large company that "cheap" technology is better than expensive
technology. The "you get what you pay for" mindset (which is true in a lot
of cases) is hard to change, especially if someone's job is on the line.
Chip Nickolett ChipN@Comp-Soln.com
Comprehensive Consulting Solutions, Inc. (www.Comp-Soln.com)
Phone: 262-544-9954 Fax: 262-544-1236
-
Ingres Q & A
-
Back to William's Home Page
© William Yuan 2000
Email William