dbc_max_pct kernel parameter

[Fabrizio_10]

Hello again,

I've installed oracle and all works fine. Unique doubt is about dbc_max_pct kernel parameter. I set it to 50. My machine have 4 Gb of ram.
Actually, with kcweb (web interface for tuning kernel parameter)I see it at 100% of usage.
In an old doc find on web, someone speak about this parameter indicate the percentage of main memory to which the dynamic filesystem buffer cache is allowed to grow.
Could someone suggest me a fine tune for this parameter ?
Any help would be apprecieted.

[Victor BERRIDGE]

Hi,
400Mb should be enough...
So lets say set the param at 15-20?

All the best
Victor

[G. Vrijhoeven]

Hi Farbizio,

dbc_max_pct is a parameter that sets the high wather mark for the buffercache usage of real memory. So in your case that is 2 GB.
This real memory usage of the buffercache can vary between dbc_min and dbc_man. The problem is that HP-UX is not to fast freeing up memory used by the buffercache so you do not want to set it up to big. 400MB normally is enough. so in your case 10 is a good setting.
To view how it works you can use a tool like glance and view the %hit ratio metric of the buffercache. You can decraese the parameter until this drops. 10 is a good start for max. and i would set min to 5.


HTH,

Gideon
Gideon

[Steven E. Protter · Accepted solution]

Problems can arise if dbc_max_pct and dbc_min_pct are too far apart.

It is very expensive in cpu terms to shift that value.

I'm running databases in the 11 GB range, four or five on one machine and my settings are 5 for min and 7 for max.

You need to pic figures that work for you and have the two nubmers close together for good performance.

Oracle tuning is more than one parameter. You need data, for that, see the script I'm attaching, it collects it for you. Here is an article on performance written by one of HP's top Oracle tuning gurus.


http://www2.itrc.hp.com/service/cki/search.do?category=c0&docType=Security&docType=Patch&docType=EngineerNotes&docType=BugReports&docType=Hardware&docType=ReferenceMaterials&docType=ThirdParty&searchString=UPERFKBAN00000726&search.y=8&search.x=28&mode=id&admit=-1335382922+1077636608384+28353475&searchCrit=allwords

SEP

[Fabrizio_10]

Ok guys,

Here's my parameter:

root@fab01 $ kctune |grep -i dbc
dbc_max_pct 50 Default Immed
dbc_min_pct 5 Default Immed
root@fab01 $
Now I put dbc_max_pct to 15...
Thanks a lot!

[Jean-Luc Oudart]

Hi,

we fix our number of pages (bufpages)
See the attachment UX Performance cookbook

regards,
Jean-Luc

[Steven E. Protter]

Jean Luc,

GREAT cookbook. Where have you been hiding this all of my life? Magnifique.

Set dbc_max_pct to 7
set dbc_min_pct to 5

build a kernel, restart your system and see what happens.

My performance is awesome with those settings and was miserable when I had the default max at 50.

SEP

[Mark Landin]

Unless you are running a dedicated NFS server, 50% is way too high. After about 400MB of buffer cache, you really get diminishing returns ... you may save time by having files cached in RAM, but you increase the likelihood that your processes will be paging to disk because you put so much memory into buffer cache. 400MB or so seems to be the "sweet spot" especially for random-access I/O like that seen in database systems.

NFS servers aren't running a lot of processes, so there's no practical penalty in devoting most of memory to buffer cache.

[Mike Stroyan]

There can be performance penalty from having dbc_max_pct different than dbc_min_pct. The dynamic buffer cache has a tendency to use 4K pages which are scattered around physical memory. That can interfere with applications which are trying to use large pages. A large page setting such as "chatr +pd 1M" or "ld +pd 1M" can really improve the performance of programs that jump around accessing data in a large memory region. It reduces the number of TLB misses.

If you are running large processes you should consider using a fixed buffer cache size, and possibly setting the chatr +pd attribute on programs which do not already have it set. (Large pages can increase the amount of RAM a program needs by rounding up to bigger pages, so don't go too far with it.)

[Jakes Louw]

Dynamic buffer cache can be good, and it can be bad.
I would (in a perfect world) use dbc min/max to get close to what an app requires for buffer cache, and then set this value as static using bufpages/nbuf.

But this isn't a perfect world, so unless you are sure about the type of filesystem I/O that an app or database would typically require, dynamic buffer cache provides a flexible solution.

Have a look at vxfs_max_ra_bytes and vxfs_ra_per_disk as well.