Metric to use to watch throughput

[Dan_173]

Hello.

I'm looking to reduce my buffer cache from 1G to 500M (on a 3.75G host) because we're seeing fairly high pageouts.

In reducing the cache, we should see pageouts fall (or disappear) at the expense of the buffer hit ratio, but is there any way (any metric) I can monitor to determine if indeed overall throughput of the host as improved as a result of the change?

Thank-you
Dan

[Donny Jekels]

use glance, its the only tool that I know of that can do this for you.

[Bill Hassell]

Standard question: What do you mean by throughput? The hit ratios for the buffer cache are found using sar. What that means to your application(s) must be measured by the applications themselves. The buffer cache has undergone MAJOR changes between 11 and 11i so for 11.0, a very large buffer cache can be costly (system overhead) to manage, not to mention slow to respond to memory pressure. Generally, pageouts will try to be avoided until the buffer cache has been reduced to the min value, but for 11.0, this can be a slow process.

Use sar to see if the hit ratio is dropping significantly or just a bit and use the added memory to better advantage for programs (that know how).

[Dan_173]

Thanks Bill.
In this context, what do you consider to be "very large"?

[Sridhar Bhaskarla · Accepted solution]

Hi Dan,

One thing I keep track of the system is to look just "sar 5 20" and observe the %wio column. While it is not necessarily 100% indication of disk IO itself, but is a good approximation. I would like to see it less than 10% all the time.

buffer hit ratio (sar -b) is really dependent on your application. If your application does a lot of synchronous I/O, you cannot expect it to be 100% all the time. In that case, having a large buffer will be of less use.

The size of buffer cache is dependent on your application. While it is a good practice to keep around 300 MB , I had systems with 25% of memory spent for buffer as those applications did benefit from the buffer cache. But those cases are rare.

If yours is 11.0, a good figure is 300MB. You can go upto 600-800MB for 11i as 11i seems to do a better than 11.0 with respect to managing buffer cache.

Look at your "swapinfo -tam" and observe the 'mb used' column on your "dev" areas. That is the amount of memory paged out. The page outs in 'vmstat' alone may not be an indication of memory pressure. Memory mapping acitivity is showed as paging and is often mistaken as memory issue.

-Sri

[Bill Hassell]

A large buffer cache is generally anything over 500 megs. As mentioned, a huge buffer cache (800 to 2000 megs) can be helpful in primarily sequential operations, not likely in most query-based database activities. A large buffer cache (at 11.0 and earlier) requires a lot of serial searches due to the design, which translates to system overead. The faster the CPUs, the faster the searches but the search is still a kernel task which means overhead.

So there is likely an optimal point for the cache size that balances the benefit (lower I/O) against the overhead based on CPU speed. This point is very much dependent on the access profile of your applications.

[Caesar_3]

Hello!

Check the glance plus, you have option to
view hd and cache work and problems.

Caesar