RAID i/o performance

Running Solaris 2.4 on Sparc-20.
We have a situation where our RAID array on sd8 which is Fast and Wide SCSI, is very very slow,
here is output from iostat.

#iostat -xtc
                                 extended disk statistics       tty         cpu
disk      r/s  w/s   Kr/s   Kw/s wait actv  svc_t  %w  %b  tin tout us sy wt id
sd15      0.2  5.2    0.2  237.4  0.0  0.1   19.9   0   9    0   96 19 25 52  4
sd16      0.0  0.0    0.0    0.0  0.0  0.0    0.0   0   0
sd17      0.2  6.2    0.6  346.9  0.0  0.2   33.6   0  21
sd3       1.8  0.0    8.0    0.0  0.0  0.0   14.0   0   3
sd8      17.2  9.4  577.7  292.4  1.8  2.3  156.2  62  85

##This is an entry in our /etc/system file
set ufs_ninode=5000
set ncsize=10000
set sd:sd_max_throttle=10
set scsi_options=0x178

Now heres the question.
Why does the Kr/s added to Kw/s not add up to the expected 20-40 megs per second. also what are the "set" options doing? and what impact do they have on the performance
of the Raid.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.


The RAID is a secured solution, not a performant one.

Using RAID, the system has to compute parity bits each time it access disk.
It has also to distribute data on several disks when it writes, and
to read on several disks.
If your raid system has no memory cache, it can't be performant.
rickyrAuthor Commented:

The raid has 32mb memory cache. It is a 108gig unit. The speed of the i/o is very very low, and our RAID suppliers are looking into this for us.

Meanwhile could you answer the second part of the question, about the /etc/system file, Are the entries relevant to the RAID? What do they mean?
Your problem may be much deeper than this, but to achieve greater than 20 M bits a second transfer rates your SCSI cabbling must be
as short as possible. I have seen performance loss in cables as short as 1 1/2ft. With an array as large as yours, your cable may be pretty long.

Unfortunately, RAID problems can be very difficult to trace.
Cloud Class® Course: CompTIA Healthcare IT Tech

This course will help prep you to earn the CompTIA Healthcare IT Technician certification showing that you have the knowledge and skills needed to succeed in installing, managing, and troubleshooting IT systems in medical and clinical settings.

rickyrAuthor Commented:
OK so the RAID problem may be a too deep to get into here. Our suppliers are looking into this for us anyway, so we'll forget about that. I'll bring up cable quality with them though, (Thanks for that).

Any ideas about the "sd" statements in the "etc/system" file. Do these have an impact on performance?

rickyrAuthor Commented:
We stripped out the set scsi options, and thru-put is now around 4 megs a second (sum of reads and writes). As we are getting closer to the solution, can anyone now state the correct scsi options to attain the full potential of the i/o (8-10 megs a second, I am told). This is a mission critical setup and we have a couple of running theories, so could anyone help here PDQ, before this solution is found by ourselve or our suppliers.
rickyrAuthor Commented:
Running theory no. 1& 2 were...
set scsi_option=0x100 and...
set scsi_option=0x200 but...
neither worked, they just took the i/o perf back to how it was in the first place.

rickyrAuthor Commented:
I get the feelin, "ain't nobody here but us chickens"!
I've seen a similar problem where one (or both!) of the SCSI terminating resistor packs were wrongly fitted or missing - it's worth a check, tho' this does tend to give intermittent other SCSI faults (typically tape drives 'going away' until a reboot) as well. Also make sure there are no hardware configuration contention problems with your SCSI controller and another device - e.g. do you have a 2nd SCSI controller ?
rickyrAuthor Commented:

Our RAID suppliers have sorted this out for us. We had to serial link into the RAID from a PC then enabled write cache and a the blocking size.

Thanks everyone
I'm posting the solution so it can be saved in the PAQ.

                          Our RAID suppliers have sorted this out for us. We had to serial link into the
                           RAID from a PC then enabled write cache and a the blocking size.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
rickyrAuthor Commented:

Just to add.......

WARNING!!!!! Enabling write thru cache will corupt your data if there is a power outage, unless the RAID has an internal backup battery for it's cache'ing, or the whole system is on a UPS (Uninterupptable Power Supply). this is so that the data held in cache can be written back to disc.

Thanks for adding the warning rickyr.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Unix OS

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.