Buffer Cache

[Thomas J. Harrold]

I was told (by HP) several years ago, that it was not good to have more than 3-400MB of buffer cache. Common sense tells me that it would be best to use all available memory as buffer cache. In fact, this is the model that Solaris uses.

Can I get your feedback on the use of buffer cache in HP-UX? Are there drawbacks to having 4GB (or more) of buffer cache, on a system with 8GB of RAM, assuming that memory demands are fairly low?

Any feedback/experiences are welcome. Thanks for your help.

[Rainer_1]

buffer cache up to 500MB is sufficient for most configurations.
On a system with 8GB memory i'd set the kernel parameter:

dbc_max_pct 10

[CHRIS_ANORUO]

Hi Thomas,

To set buffer cache dynamic within 10% of dbc_min_pct(value=10) and 50% of dbc_max_pct(value=50). Set bufpages and nbuf to zero. Also set swapmem_on=1 to get 75% of Physical memory for pseudo memory. These changes in jernel will require a system reboot.

[Thomas J. Harrold]

Let me clarify...I understand the buffer cache concepts, and I know how to set and tune the buffer cache. I am asking about best practices. I need to know if a "maximum recommended" amount of buffer cache still exists, and if so, why.

[John Waller]

I feel it depends on the application you are running. I have set up a system with 1Gb memory running a database application with dbc_max_pct=50 (max 500Mb) and all that happened was if memory got a bit tight the OS would reduce the amount of buffer cache it was using. For a system with 8Gb of memory, I would be inlined to agree with Rainer and keep dbc_max_pct to 10 possibly 20 maximum.

[James R. Ferguson]

Thomas:

I see no reason not to allocaate the buffer cache as you see fit if you are doing IO via LVM and a database engine isn't already managing buffering. If you have an excess of memory, you can eliminate a large fraction of physical IO by setting dbc_min_pct and dbc_max_pct a fairly large percentage.

...JRF...

[CHRIS_ANORUO]

You can check the bufpages value now from sysdef or use adb (echo "bufpages/D"| adb /stand/vmunix /dev/mem)

[CHRIS_ANORUO]

As I posted earlier, you can check the bufpages value now from sysdef or use adb (echo "bufpages/D"| adb /stand/vmunix /dev/mem).
It will be a good idea to keep dbc_max_pct at 25% so as not to put more load on the system while deactivating or flushing the buffer cache.

[James R. Ferguson]

Thomas:

I might add that on a 10.20 server with 1GB memory and and application that doesn't use a database engine, my dbc_min_pct=25 and dbc_max_pct=50.

The "downside" on larger memory systems would be the time and amount of work that the syncer daemon would take flushing the buffer cache.

...JRF...

[CHRIS_ANORUO]

Hi Thomas,

The "maximum recommended" value does not exist. It is a general consensus in this forum.


Regards

[Matt Walls]

hi,

i have a few large systems with 24 gig of memory. I too have been told conflicting reports on the "best practice" of buffer cache. I was told to keep it under 1 gig. however, i think that may have been the "old way" of thinking. Now, I have it set around 1.5 gig, and the system runs great. in fact, i may decide to increase it. Basically, in my opinion, if you have the downtime available to you to make these changes, i would just play around untill it looks good to you and more importantly, your users.

One piece of advice though, is to keep the min and max values the same. especially when you get into the larger formulas. that way the system isnt bothered with trying to be too dynamic.

Matt

[Bill Hassell]

Here are a few recommendations from real world experiences:

1. The buffer cache defaults are way out of whack for systems with large RAM (more than 4Gb). Having a buffer cache set to 5% to 50% just doesn't make a lot of sense. A 4Gb system with 2000 megs of buffer cache is overkill. Start with a range of 200 to 1500 megs of RAM.

2. Now adjust the maximum buffer cache to match your system. Start with RAM: for small RAM systems (less than 500 megs), make the buffer cache about 5-10% of RAM. If your applications are swapping a lot, it's time for a lot more RAM (multiple Gb).

3. Now 200 megs is probably fine for most systems with a read/write ratio of 50% or so. Writing is the biggest issue--when continuous writes are taking place, the buffere cache manager will have a lot of work to do in kernel mode to flush these requests out to the disk. These will be bursts of activity every time the syncer runs and if the data stream is fairly steady, the buffer cache should be smaller. Note that a fast system (CPU + I/O + disk) can tolerate a bigger cache with heavy writes.

4. For systems that perform lots of reads (more than 60%), a large buffer cache is good, the bigger the better up to a couple of gigabytes.

5. For Oracle, the rules change a bit. Your DBA can change the Oracle SGA to perform high levels of data caching, so a big buffer cache means double buffering...a waste of RAM. To avoid this and to take advantage of Oracle's data cache, you need to disable the buffer cache for Oracle data volumes. This can only be done with Advanced JFS options on vxfs filesystems:

convosync=direct,mincache=direct,nodatainlog

Use these options on Oracle data disks only. Don't use them on rollback logs, archives, etc.

6. The buffer cache is only effective for filesystems--it has no effect on raw disk access.

[Darrel Louis]

The buffer cache is used for synchronous file-system disk writes. This means that if you (or your applications) are doing lots of raw I/O, or asynchronous I/O, you have little need for buffer cache. If you are doing lots of synchronous file system disk writes, then you have to balance buffer cache with other performance considerations and come up
with something that makes sense for your system. Sometimes, coming up with this value takes a little bit of playing, testing, and gut feel.
I would recommend that you start by setting your "dbc_max_pct" to about 10%
of memory.
If you then run sar -b, it will show you your buffer cache hit rate.
A great rate is about 95% for reads, 75% for writes, but rarely will a system hit that. For example, you won't hit a rate that high if
you do lots of raw I/O, or a lot of metadata LVM queueing.

If you fave a XP, EMC or Autoraid connected to the system, it's recommended to lower the dbc_max_pct, because on those diskfarms there are loads of Cache. So why stressing the resources on the system.

Check the following url:
http://docs.hp.com//hpux/onlinedocs/os/KCparam.FilesysParmsOverview.html