Re: Oracle on RAID - IOwait problem

Hi everybody,

Thanks for the tips, we're still working at it. Currently having the SA check on the stripe size.

I'm no RAID guru, but here's what our SA is telling me, and i'm just repeating that.

The RAID box comes with a 512M solid state disk (SSD) built in. For read access, the box uses RAID 5, it hits the disk only if the data isnt available on the SSD cache. For write access, the box uses RAID 0+1 onto the SSD then RAID5 onto the disk packs. This is suppose to be some adaptive RAID technology optimized for RDBMS read/writes. See http://www.seek.com

Currently, we have 4 channels configured for the SSD and a pack of 7 disks. 1 channel for OS and 3 for Oracle. Its supposed to be a black box algorithm how data is spread eventually across the disks from the SSD. Parity information is stripped across the disks.

Does this make sense?

Regards,
Calvin

"Louie, Steven (SBCSI)" wrote:
>
> need to check the database config - esp the sga size compare to the physical
> ram (is the sga swapping), check buffer hit ratio, if the app has lots of
> writes then raid5 is a poor choice, what's the strip width - compare to db
> block size, may need to move redo log, temp table, to non-raid disks
> how many disks you have on each scsi channel, what's size of the cache on
> the raid device (are they config properly)
> there are lots of issues, but start with the nature of the app (perl/dbi is
> not very effective) and physical config of the database - ie see if they are
> config for each other
> cheers and good luck
>
> > ----------
> > From: Calvin Lim[SMTP:calvin-lim_at_mediaring.com]
> > Reply To: ORACLE-L_at_fatcity.com
> > Sent: Thursday, May 04, 2000 11:55 PM
> > To: Multiple recipients of list ORACLE-L
> > Subject: Oracle on RAID - IOwait problem
> >
> > Hi,
> >
> > We've just put a 8.1.5 on a 2CPU Sun Solaris into production.
> >
> > The machine is hooked on to a RAID5 storage device by Seek.
> > Oracle datafiles are spread across 3 channels on the RAID.
> > What i'm noticing is that the disk iowait is reaching incredible
> > levels and top is reporting 0.0% idle for CPU states and 100M
> > swaps.
> >
> > We're currently suspecting that it could be 1. the RAID
> > configuration thats giving problem, 2. some cron driven perl/DBI
> > jobs that is pounding the Database too often too hard with
> > inefficient queries.
> >
> > Could 2. be a reason for extensive iowaits thats always hovers
> > round the 85% mark. I need some advise on how one would go about
> > troubleshooting such iowait related problems? Thanks very much.
> >
> > Regards,
> > Calvin
> >
> > --------------------
> >
> > load averages: 0.39, 0.43, 0.46 22:19:30
> > 74 processes: 71 sleeping, 1 running, 2 on cpu
> > CPU states: 0.0% idle, 5.2% user, 8.5% kernel, 86.3% iowait, 0.0% swap
> > Memory: 1024M real, 16M free, 100M swap in use, 1900M swap free
> >
> > PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND
> > 2359 root 1 59 0 1944K 1080K sleep 0:03 2.40% sshd1
> > 29216 oracle 1 58 0 832M 799M cpu0 1:50 2.12% oracle
> > 2383 oracle 1 58 0 2000K 1360K cpu2 0:00 1.24% top
> > 29214 mrurl 1 53 2 13M 4840K run 0:54 0.98% ifmxTrigger
> > 10591 oracle 1 60 0 834M 798M sleep 102:23 0.95% oracle
> > 27178 oracle 1 38 0 2000K 1160K sleep 0:55 0.51% top
> > 10360 oracle 1 60 0 832M 798M sleep 113:10 0.50% oracle
> > 10362 oracle 1 60 0 832M 797M sleep 112:00 0.49% oracle
> > 10366 oracle 1 60 0 832M 797M sleep 111:50 0.42% oracle
> > 10364 oracle 1 60 0 832M 798M sleep 112:27 0.41% oracle
> > 10368 oracle 1 60 0 832M 797M sleep 112:16 0.38% oracle
> > 2389 oracle 1 60 0 831M 799M sleep 0:00 0.19% oracle
> > 10338 oracle 1 59 0 833M 794M sleep 3:01 0.15% oracle
> > 10340 oracle 1 58 0 832M 794M sleep 4:40 0.14% oracle
> > 9341 oracle 1 48 0 8960K 2352K sleep 9:34 0.13% tnslsnr
> >
> > ----------------
> > --
> > Author: Calvin Lim
> > INET: calvin-lim_at_mediaring.com
> >
> > Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> > San Diego, California -- Public Internet access / Mailing Lists
> > --------------------------------------------------------------------
> > To REMOVE yourself from this mailing list, send an E-Mail message
> > to: ListGuru_at_fatcity.com (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).
> >
> --
> Author: Louie, Steven (SBCSI)
> INET: slouie_at_pacbellwireless.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (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).

-- 
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGPfreeware 6.0.2i

mQENAziIKPcAAAEIAMOziD1YcgivJCdmdMaQftSrMhnL6uXjz9Fh6c2FjDbEwLb1
gHAYk8bdlaWLPspacuwo5mjzCc5uUvNualORP+tLxGNY9GiMdHMUfUdNLxv7EU4+
6WxaXwyzz5DZUQiwLsvg12+ZSLOuOL4BLu8oJH9MBSPa/9aaYGDpQ845L6JJP5t1
uDDsG26k6gnenOfT+ZaEgFTFpYQbfXN7X16dc726AcEuSG8NUjK3thA3ol9m8768
cCELkc82w55HNH5b4TeF9obapJrXgOLqnf2pi4mUodao5dFewW/U46zPcz2giRp4
gVPAmJFs+s8OjKY74D3aXH7QWg7bLrLOrBG3pkUABRG0L0NhbHZpbiBMaW0gU3dl
ZSBLaGlhbmcgPGNhbHZpbl9saW1AaG90bWFpbC5jb20+iQEVAwUQOIgo9y6yzqwR
t6ZFAQFrTAf+Lw6aI0wSfOooU1n9qw0zdL4o0U4ZH+XAgzn8BoVcv0U1bA0U1ckg
pDY5TVfR0hQg7DQyUvh1AKxeD9D6OTFpg/TE3BPD49iq/LS3uuUbfIGmhsE6AmM1
SiRwwmA5n5IZTWDYHrocBJegV5Hk3iHJeDjCKvX/CZCZH4CGJ/2y/THfa6I9eDfF
kmZ8f90cM4hZ9YiqLSslNf5hztJZzEfBuSs7Zz6tHRQFlCucn5mlKPNM+ig4FBdS
f6ISUMxQxZB2xbFwYDn+qjB6eF8HianPP7XCQUSQNJeWKQ9pkJ7QOZeEKvRYZHp2