Re: Keep Pool Question

Thanks for your reply. Tuning the application would be a great help. At the moment the developers are swamped. In the meantime, I try to tune the db to compensate. It will take years to remodel the data and rewrite millions of lines of code that does not use bind variables.

You bring up a good point: 3.3G is large. The thing is, one db writer with asynchronous io works fine. OS does not swap, load average is <2 most of the time, statspack has never reported 'buffer busy waits', check pointing is problem free, the BCHR (for what it's worth) is decent. So whatever extra work is being placed on the system by having large LRU queues is not an issue (as far as I can tell).

I recently added 600M to buffer cache because of disk i/o issues. Before this statspack was reporting very high i/o wait times (> 2000 buffer waits in the tablespace io stats section). iostat was reporting high awaits. Tablespaces were moved off hot disks, tuned sql and I did the standard DBA stuff. To make a long story short, I figured out that there is a controller problem because it only is able to sustain a max i/o rate of 10M/sec when it should be 80M/sec.

So as a last resort I increased the buffer cache by 600M. Then statspack reported great io times with buffer waits < 10. I checked and rechecked. The extra 600M took a huge load off the disks. Buffer busy waits remained fine.

Adding another gig is probably over kill. As I mentioned no one is having any issues. I kind of wanted to push the cache until I saw some kind of performance problem and then back it down. If the box has a total of 8Gig ram, what would the problem if I went to a 4.3G cache and a keep pool? The pool will have it's own LRU queue, the box won't swap, if buffer busy waits is an issue then I'll add another db writer. Am I missing something? There is 130G of data sitting in the datafiles. The nodes always have at least 2G sometime 3G of free memory. Received on Mon Mar 07 2005 - 17:14:02 CST