buffer Cache

[navin]

Hello All,

I have a hp server which runs hpux-11.23 on rp model. With the output of kmeminfo...we get the below detail
Buffer cache = 6291200 24.0g 50% details with -bufcache

System has total 48 GB of mem . So does this mean that out 48 ..24g is reserved for buffer cache..my clients think that this affects the performance.
please advice
thanks

[Tim Nelson · Accepted solution]

It does effect the performance sometimes good and sometimes bad.

IMHO. Big buffer cache are a burden and negate their purpose except in certain circumstances. ( e.g. big NFS file servers )

HPUX default is 50% of ram for buffer cache. That it too much !!

Depending on the type of work your system does. Reduce dbc_max_pct to about 10% or around 800MB.

If you are running a database then reduce it even further and give the RAM to the application. It can do a better job.

Once you have made a change, monitor the hit rate. If read hits are low, depending on your application, then increase some small amount and monitor again. If hit rates are at 100% or close all the time and you need memory for something else, reduce it some, and monitor again.

It depends on your usage of the system but the poorly chosen 50% default has caused a lot of issues in the past. Try formatting a large database then watch your system hang or surge while the 24GB of buffers are flushing to disk.

[melvyn burnard]

HP-UX defaults to a dbc max of 50%, but this was designed when systems had much smaller memory capacities.
You should limit it to around 600-800 MB otherwise you see performance hits.

[James R. Ferguson]

Hi:

A file buffer cache is of 50% is generally far too large. The concept of the buffer cache is that file buffers can remain in memory speeding reuse to data. Periodically (every 30-seconds) the 'syncer' daemon flushes modified buffers to disk. WHile 11.23 is far superior in its buffer cache handling than previous releases, a 50% setting (dbc_max_pct=50) is probably a waste of memory and may be an impediment to overall, constant throughput when 'syncer' runs. Something like a 5% value is probably going to give you good value.

http://docs.hp.com/en/B3921-60631/dbc_max_pct.5.html

You can use 'glance' to monitor performance before and after changing the buffer cache size.

Regards!

...JRF...

[navin]

Thanks much - how do i see the hit rate (vmstat?) is the prefered one..?
thanks

[James R. Ferguson]

Hi (again):

With 'glance' you can look at the ratio of physical versus logical I/O. If the buffer cache is begin well utilized, you should see less physical I/O relative to logical I/O.

Remember that your application and your mountpoint options can decide whether or not to involve the buffer cache in the first place. After all, one of the reasons you purchase OnlineJFS is for the use of mount options that bypass the buffer cache when buffering is done by a database engine like Oracle.

Regards!

...JRF...

[Tim Nelson]

sar and glance are both great tools to watch buffer cache hits. Remember to review over time. What happens one second of the day may not be the big picture.

sar -b 10 10

glance

[Kenan Erdey]

Hi,

look for sar -b output and check %rcache value. %90 and above is good usage. if it's %100 you can decrease dbc_max_pct kernel parameter and get more memory back to your applications.

Kenan.

[Jeeshan]

if the parameter %rcache and %wcache of sar -b outputs is respectively near abt 100% or more than 50% is good. but if its lower than that, this means your system doesn't efficently usage the buffer cache.

for this you need to tune the kernel parameters dbc_max_pct and dbc_min_pct parameters. for larger memory systems, you may decrease the dbc_max_pct value to 10.

[dirk dierickx]

it's true that the 50% comes from a time where systems had a lot less memory then these days.

but this is still the default value in hpux 11.23, COMMON HP! GET OUT OF THE STONE AGE!