Re: Oracle performance and swapping on Tru 64

Rob F wrote:
> The reason I posted the 'during the day' results was that they seemed
> to indicate to me that there were problems due to memory constraints
> even during periods of low activity. I'll post an excerpt from the
> overnight stats as well. I've done quite a lot of analysis of the
> processing over the last few weeks. One of the problems is that a
> commit is issued after every row inserted and I'm currently trying to
> persuade the application team that batching the commits would give some
> benefit. Aside from this, despite the fact that I've managed to reduce
> the consistent gets peformed via various pieces of the code by over
> 90%, with no significant increase in disk reads, the run time for the
> job remains fairly static. I've used the statspack analysis tool at
> Oraperf.com and it recommends that 'tuning the internal write batch'
> would dramatically improve performance. Unfortunately all the
> documentation I've seen regarding this issue seems to indicate that
> this is not possible from 8.1.6 and above. I tried upping the number
> of database writers to 1 per physical disk but got no benefit from that
> either.
> Regards,
> Rob

Your pout numbers ( page outs ) seem to be consistently low or zero.

Your free pages seem ok, not great but not bad. As far as I remember from Tru64 you have a problem if you go below 128 consistently.

While some of the vmstat numbers look at little different I don't see anything shouting that adding memory would help drastically.

The machine seems mostly idle from the cpu side.

Are we just slow on IO due to the commits on every change?

What does iostat show during your busy slow times?

I think a 10046 trace that includes wait events is going to give you the most bang for your buck in deciding what to do next. Received on Mon Mar 20 2006 - 08:52:20 CST