Re: I/O wait question/scenario

Actually, the vendor is about right ;-) if they burn more cpu- cycles on something else, the io-wait percentage is going to go down.

not that this makes the application any faster, or the users any happier, but on paper they will look better, i.e. reduce i/o wait percentage.

Karsten

Connor McDonald <hamcdc_at_yahoo.co.uk> wrote in message news:<403C7E63.413D_at_yahoo.co.uk>...
> bordenm_at_methodisthealth.org wrote:
> >
> > Ok, here is the scenario. We have an application, clinical, that the
> > db server is having pretty high I/O wait. It can be as high as 50 to
> > 60%, but it is not consistently like this. It is more consistently
> > around 30 to 40 during busy times. This is running on a p690 regatta
> > attached to a shark. The partition is set up with 7procs and 16gig of
> > ram. After the vendor has researched this a little, they have said the
> > the I/O wait will go down once we add more users to the application.
> > They are saying that the I/O wait is high because the processesors are
> > so fast that it processes the transactions faster than what it can
> > handle. Like I said, they say that the I/O wait will go down once we
> > make the runqueues go up by adding more users to the application. To
> > me, this doesn not sound correct.
> >
> > My question is, could this theory be correct? If it is correct,
> > doesn't that mean that we have an I/O bottle neck period and it should
> > be resolved? In my mind,since this application is on a SAN that we
> > should have almost no I/O wait and maybe more run queues than anything
> > period, no matter how many users are on the box.
> >
> > Thanks for you comments and opinions.
> >
> > Mike
>
> Its an interesting proposition..."There might be a problem in area X,
> but we can resolve it by introducing problem Y, thus making X look
> insignficant"
>
> :-)
Received on Wed Feb 25 2004 - 12:20:30 CST