nbuf and bufpages parameters

[Dean Johnson_10]

Hi

I have recently upgraded from 10.20 to 11.0 (yes I should have gone to 11i but it took nearly 2 years to get this project completed!)

Server is K370, 1.7 Gb memory 4 Gb swap running oracle 8.1.7

Post upgrade testing by the client highlighted "slow response" issues. Whilst trying to identify the source I noticed in glance that nbuf of 720 was 100% - this led me to investigate nbuf and bufpages (values for which are nbuf=0 and bufpages=512)
The DBA made some changes to the database and the performance has improved to the satisfaction of the client BUT I am still concerned that these kernel params are too low. I read Lorenzo's thread yesterday and realise either bufpages should be 128000 or 0 and use dbc_max_pct. I have to prove to our client that making these changes will improve things but I cant find anything to prove there is still a problem - could someone give me some pointers of where to start looking (I have evaluation copy of glance) and what benefit could be gained by making the change ?

Many thanks

Dean

[Jean-Luc Oudart]

Hi Dean,

may be yuo should read this HPUX performance cookbook ?

Regards
Jean-Luc

[Geoff Wild]

I would set nbuf and bufpages tp 0 each...

Then DBC_MIN_PCT to 5

and DBC_MAX_PCT to 35

That will give you 609 MB for Buffer Cache.

Ideally, it would be great to add some more ram - to atleast 2GB.

RGds...Geoff

[Dean Johnson_10]

Jean-Luc

Thanks for the cook book I shall work my way thru it tomorrow

Geoff

Thanks for the recommendations - I am happy to change the values but my real problem here is trying to gather evidence for the client that there is an issue to be addressed and they want proof afterwards that the changes have actually made a difference.

Any pointers as to what to look for in Glance would be most appreciated
i.e. what is the impact of too small a buffer cache

[Geoff Wild · Accepted solution]

Well, for Oracle - nothing - Oracle does it's own buffering.

You want your buffer cache to be in the 400-800 MB range...

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

[Victor BERRIDGE]

Hi Dean,
Are you connecting yourself to the kbox using X emulation? then if you exported the correct DISPLAY value just type gpm& and let it run for some time (well why not a few day)since you dont know really what you are looking for...
You will see in the main window menu bar, click Adviser- click on Alarm history and keep that window open.
If you see things accumulating here then you are for some tuning lessons otherwise you have to accept the honourable performances of your K class under HPUX11...
Not that you cant make things go faster but it will not be obvious...

All the best
Victor

[Fred Ruffet]

Have a look at this thread. It's not all about cache, but has a part on it.
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=745239

Also, have a look at this cookbook :
http://h21007.www2.hp.com/dspp/files/unprotected/database/HP3KOracle.ppt
(particularly good one)

A shortcut to all of this would be : you should bypass the cache for Oracle DB Files (and probably for other RDBMS).

Regards,

Fred

[Bill Hassell]

If nbuf and/or bufpages have been set to non-zero values, you can read the details in SAM's onine help for these parameters...but be warned, the interaction is quite complex. Note that Glance reports the current values for nbuf and bufpages and they are quite dynamic. And 100% doesn't mean that the parameter is too small--it is part of a rather complex set of algorithms that setup file data buffering.

My guess is that in SAM, you'll see nbuf=bufpages=0 which is defined as: use dbc_max_pct and dbc_min_pct. So far, so good, unless dbc_max_pct=50 which is 50% of your rather small RAM (1700 megs) for Oracle. Now DBC means dynamic buffer cache and the actual amount used will decrease automatically as processes need more RAM. Glance shows you this on the memory line as B___B.

Now reducing the dbc_max_pct value to no more than 400 megs will permanently free up about 400-500 megs of RAM but this will not improve performance. At 10.20 (and 11.00, but not 11.11), the DBC was rather slow to respond and will cause new processes and processes that ask for more RAM to page out for a while until the memory is freed.

So for 10.20, the recommendation is to keep nbuf and bufpages = 0 and dbc_max_pct to 25 (425megs). This will keep the buffercache from occasionally slowing things down. But to truly improve performance, you need to give Oracle a lot more RAM for SGA and have the DBA utilize the extra space in SGA to reduce disk I/O.

[Con O'Kelly]

Hi Dean

My recommendation would be to set a fixed buffer cache.
Check your current values using:
# kmtune |more
If your values are really bufpages=512 and nbuf=0 as you stated then your buffer cache is too low for any system.

If your system is only running Oracle then a buffer cache of 300MB-400M should be more than sufficient on 11.00 systems.
Set bufpages=102400 and nbuf=0 to give 400MB fixed buffer cache.
If you want to use Dynamic Buffer Cache set bufpages=0, nbuf=0,dbc_max_pct=25 and dbc_min_pct=10.

Oracle has its own buffers (ie as part of SGA). Often bypassing filesystem buffer cache on filesystems that house Oracle datafiles can improve performance.

I don't think there is anything that can prove the buffer cache changes will improve performance. Its very likely the improved performance was due to the DBA's re-sizing the SGA.
As long as you have 300-400MB of buffer cache there is going to no real performnace improvement for Oracle by playing with buffer cache.
Normally there is little you can do on the OS side to improve Oracle performance apart from ensuring enough memory is available (1700MB is quite low for oracle) and ensuring Oracle can access enough shared memory. This is done through sizing the 'shmmax' kernel parameter.
You can see the size of Oracle shared memory segments using the command:
# ipcs -mob.

Cheers
Con

[Sridhar Bhaskarla]

Dean,

Since your bufpages is not zero, you will not be using dynamic buffer cache. You should have both nbuf and bufpages set to 0 if you want to use the DBC. So, you have around 2MB of static buffer cache (512*4k) on the system.

As you know, with buffer cache it will be double buffering for oracle. With such a low buffer cache (2MB!!), the possibility of finding a previously read block in cache (rcache), effective read-aheads and combining mulitiple blocks to make fewer physical IOs (wcache) for writing is very less. Those are the advantages of buffer cache which your system is lacking now.

Also, setting aside 400-500MB of memory for buffer cache is costly for a system with only 1.7GB of memory. So, the best bet for you is to completely bypass the buffer cache and it will be upto the DBA to take the headache. Keep the buffer cache to around 150-200MB for system and other processes. Increase the SGA by another 200MB. Use OnlineJFS's options (convosync=direct, mincache=direct) to bypass the buffer cache for oracle's filesystems.

However, if you don't have OnlineJFS, then it's better you add more memory (say upto 3GB), have your buffer cache at 400MB and also increase the SGA little bit more. Performance is application/database driven. So, there is no 100% guarantee that you will get performance benefits with OnlineJFS options either. I tested few applications with OnlineJFS's options and found the performance actually decreased. Only the option that I found consistenly helpful is delaylog.

-Sri

[Dean Johnson_10]

Many thanks for all the responses

Geoff - I now understand what the buffer cache does - Thanks for the description

Also thanks for clarifying that Oracle and OS buffer cache are separate - I think this was confusing me originally.

I am going to look at setting bufcache to 200 Mb and also look at the OnlineJFS options.
If funds are available then I will look to recommend an increase in RAM to 3 Gb and amend bufcache to 400 Mb