At 2004-11-06T19:16:13+1300, Steve Holdoway wrote:
> As you can see, a huge amount of time seems to be spent in iowait. Any
> ideas as to how to tune the server up to improve this? I expect that
> the problem is in the cpqarray module, but don't have enough device
> driver experience to delve in that code.
Why do you assume that there's a problem? It's not unusual to see high
I/O wait times for a database performing many updates.
In any case, it's very unlikely to be a problem with the array driver.
What's the particular workload showing this behaviour, and why do you
think performance is worse than you expect?
Has the Oracle instance been tuned properly? Make sure your caches are
tuned so that as many reads as possible are serviced from cache.
Are you using Oracle's asynchronous I/O support? It's not enabled by
default, and I don't know how well supported it is, but it may be worth
experimenting with.
Does your server's array controller support battery-backed write
caching? It sounds like the array controller is fairly low end, so I
suspect that it won't. Enabling write caching (e.g. setting the
read/write cache ratio to 50/50%) on the controller will significantly
reduce I/O wait time, but there is a considerable data integrity risk in
failure situations if you do so. I certainly wouldn't recommend it for
a production system.
> So I'm stuck with the latest version of 2.4.20 that's on offer by the
> WB boys.
Well, the RHEL kernels include a lot (but not all) of the 2.6
functionality anyway. Red Hat, for better or worse, have backported a
huge amount of functionality. The rework of the block I/O layer was one
of the things that wasn't backported. It's quite possible that your
workload will perform better with a current 2.6 kernel.
Cheers,
-mjg
--
Matthew Gregan |/
/| [EMAIL PROTECTED]
