Buffer Cache, I need a better understanding

[Matthew Couper]

Looking into memory I've seen that the buffer cache is at 1.50GB constantly and total is over 55% during idle times. Looking more into this I have found that the kernels dbc_max_pct=30 (5GB System memory and 4GB swap)

Digging around the forums here it appears that dbc_max_pct is recommended to be 20 or less (300-500MB ideally). All of these examples state this is with an Oracle database, we are using Progress on this system. Not sure if that makes a difference.

Checking buffer hits, rcache and wcache are constantly at 100%. I am not sure if the database is using this buffer at all or using it's own (or using the db cache in the buffer cache).

There are no page outs.

My question is, is this OK? They system seems to be running fine, but if we can gain a gig back into memory without negative effects...
Should I look at decreasing the dbc_max_pct?

Typically what is the buffer cache for? Is it memory caching in general or does it cache specific system memory?

[doug mielke]

100% hit rate, being as good as it get's would indicate that you could trim the buffer cache some, and gain some memory, as well as speed access to the data in cache.

This is definitly a trail and error area. While you can make some educated guesses and logical comparisons, the proof will only come from giving tuning changes a try.

I'd pick a static number, representing a reduction of a few % of you dbmax, and make both dbmax and dbmin the same, and let it run for a week, as a start.

[John Dvorchak]

Buffer cache is RAM where read and write requests look before actually doing an I/O to the physical disks. All disk reads and writes are cached.

Now look at what you have. Our Oracle guys and platform specialist/tuners have come up a recomendation of no more than about 300MB of buffer cache. So we figure out how much physical memory we have and adjust the dbc_max_pct kernal parm to get about 300MB, in your case 5 GB would be about 16 percent for 300 MB.

The reason being that with such a large cache, over 1.5GB, it actually takes longer to look in cache than to just do the I/O so your performance is almost certainly suffering because of such a large cache.

Hope this helps.

[Patrick Wallek · Accepted solution]

rcache and wcache hit rates of 100% are incredibly good!! No PO's is good as well.

1.5GB does seem to be a bit high, but it seems to work for you.

The big question about reducing dbc_maxpct is: Are you having a memory problem? How much of that 5GB is being used? If you are not hitting 100% memory usage and not paging out, then I wouldn't worry about it for now. Freeing up a gig or so of RAM won't do you a lot of good if there is nothing there to use it. :)

In simplistic terms, buffer cache caches I/O to and from the disks. Buffer cache hit rate of 100% on rcache is great because all of your data read requests are getting fullfilled from the buffer cache and not having to go to disk because the info wasn't available in the buffer cache. Think of the buffer cache as a read-ahead buffer. Data is read in anticipation of it being needed at some point.

Since you are using the Dynamic Buffer Cache (dbc_min and dbc_max parameters) if you did happen to run into memory pressure then the buffer cache would be automatically reduced in size until it gets down to theh dbc_min value, thus freeing up RAM. I'm not sure how well this worked at 10.20, but is supposedly has been improved at 11.0 and even more so with 11.11.

I hope this helped.

[Sridhar Bhaskarla]

Hi,

Buffer cache is to cache the IO from the disk. When a IO read request is issued, the system will perform read aheads and perform additional IO than is already requested and keeps them in cache. It may be that another process may want to read the same IO. This way if the process performs more requests, they may already be there in the cache and doesn't need to go to disk again. Similary when an asynchronous write is done, it will be kept in buffer cache for sometime. Or that particular block may already be there in the cache due to a previous operation. Subsequently when the syncer process flushes the data from the buffer cache to the disk, multiple IOs can be clubbed together as a single IO. Ideally you don't want to go to the disk often. That's where you look at rcache and wcache hits.

%rcache is the percentage of IOs read from the cache to that from the disk. If %rcache is near 100%, that means very less is being read from the disk. Similarly wcache.

The reason why people suggest to keep buffer cache low for databases is that the database already does buffering with it's own SGA. Adding another pool will be an extra overhead for the system.

In your cache, you can reduce the buffer cache to around 700-800MB if it is a 11i system. Particularly you don't need too much if you have faster IO cards and a disksystem with cache.

However, a point to remember is that the cache will be used irrespective of it's size if the filesystem is mounted for caching.

As long as there are no page outs, the system is fine in terms of memory.

-Sri

[Geoff Wild]

How the Buffer Cache Grows:

As the kernel reads in files from the file system, it will try to store data in the buffer cache. If memory is available, and the buffer cache has not reached its maximum size, the kernel will grow the buffer cache to make room for the new data. As long as there is memory available, the kernel will keep growing the buffer cache until it reaches its max size (50% by default).

For performance reasons, you want the buffer cache hit ratio on reads to be higher then 90%.

sar -b and watch %rcache

Now what should you set your to? That depends on what you are running on the box. If Oracle, then you want to shrink it as Oracle has its own buffer cache.

You could also mount file systems that you don't want buffer cache by:

-o mincache=direct

That will bypass the buffer cache all together - good option for Oracle on LVM.

Rgds...Geoff

[Matthew Couper]

Thanks for the replys, very helpful!
I'm going to start stepping down the max by 5% and once I start seeing non-100% I'll figure it from there.