RAID performance

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From: "Jeff Poulin" <jeff@nbhc.org>
Subject: Re: read cache hit rates at 0%?
Date: Fri, 12 Jan 2001 15:56:04 -0800
References: <93ii01$fqq$1@nnrp1.deja.com> <3A5E23D5.A4AD3657@ultranet.com> <93n96g$gub$1@nnrp1.deja.com> 

The RAID 5 should not be a problem.  I ran a RAID 5 on a DB server (SCO
5.0.4) for years and consistently had over 90% cache read hits.  In my case,
I had 512MB RAM and 256MB of it was for buffers (and hash buffers was set to
131072).  You don't have some background process that is constantly flushing
the cache do you?  A background "find" would make a nice culprit.  So would
a large DB file that is so fragmented, parts of it keep getting swapped in
and out of the cache.

Aside from sar, have you tested the cache any other way?  Try this:

time cat some_big_file > /dev/null && time cat some_big_file > /dev/null

some_big_file should be big, but not bigger than your cache (15MB would be a
good test size).  Assuming some_big_file is not already in your cache, the
first one should be slow, the 2nd fast.  If the time on your 2nd run is
about the same as your first run, then your system is not caching.  Let us
know what happens.

    -- Jeff Poulin


"Matt Harrell" <mhar@plex-sys.com> wrote in message
news:93n96g$gub$1@nnrp1.deja.com...
> In article <3A5E23D5.A4AD3657@ultranet.com>,
>   Dirk Hart <dhart@ultranet.com> wrote:
> > mattharrell@my-deja.com wrote:
> > >
> > > Hello,
> > >
> > > I'm one of the the sys admins and DB admins for several SCO
> OpenServer
> > > systems running Progress DB.  The systems are all at 5.0.4 or 5.0.5.
> > > Progress is version 8.2 on at least three of them.  One system has,
> > > unfortunately, a RAID 5 array for the DB filesystem (all the others
> are
> > > simple mirrors/RAID 1).  We did this a while ago before we realized
> > > that RAID 5 is bad for DB's with a lot of write activity.  On these
> > > systems, we collect sar data.  In addition, we average that sar data
> > > for every weekday for read cache hit rates, CPU utilization, WIO,
> run
> > > queue length, and paging.
> > >
> > > On the system with RAID 5, the read cache hit rates are almost flat
> > > 0%.  The only time the daily average goes much above 0% is on
> holidays
> > > when they're closed.  This would imply that it has something to do
> with
> > > DB activity, perhaps.  This server also has more RAM than any of the
> > > others.  One, for example, has 384 MB of RAM, another has 512 MB,
> and
> > > this one has 896 MB.  The DB's are all between 1 and 2 GB in size.
> > > None of the systems are paging.  I'm manually setting NHBUF and
> NBUF on
> > > all of them.  On the problem server, NBUF is 131072, and NHBUF is
> > > 32768.  They used to be the same as the other servers at 65536 and
> > > 16384, but I recently changed them, hoping read cache hits would
> > > increase.  It did not.  The other servers tend to be between about
> 70%
> > > and 90%.
> > >
> > > Why is this one server at 0%?  I can't find any other kernel
> parameter
> > > that I missed changing on that server that might cause this.  The
> only
> > > differences between this server and the others are the increased RAM
> > > and the RAID 5 array (Compaq hardware RAID).
> >
> > Here's my own speculation:
> >
> > I wonder if the raid controller has its own memory? Perhaps the
> drivers
> > are such that they go direct to the controller?
> >
> > I wonder if the boot drive is separate from the raid array - which
> might
> > explain the miniscule activity recorded.
> >
> > I wonder if the BIOS setup for write through etc. are setup correctly?
> >
>
> Yes, the boot drive is separate from the RAID 5 array.  This RAID
> controller should be very similar to the ones used on our other
> servers, except for that it's setup as RAID 5.  Thanks for the response.
>
> --
> Matt Harrell
> Plexus Systems
> mhar@plex-sys.com
>
>
> Sent via Deja.com
> http://www.deja.com/

Macworld Mac Security Superguide $9.99

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.