Filesystem Buffer Cache

[Andy Zybert]

Is there anyway to show the actual usage of the HP buffer cache interactively via standard unix commands i.e not requiring 'root' access, as 'Glance' & 'Gpm' do not appear to show the actual usage for a dynamic buffer cache.

Most HP systems onsite use the default dynamic settings and I would like some evidence to show the Unix administrators that the cache is either sized correctly or not.

[Santosh Nair_1]

Are you sure glance doesn't show the dynamic buffer cache usage...in glance (command line) if you hit m, there is field at the bottom of the screen that says "Buf Cache" followed by some number of MB.

-Santosh

[Carlos Fernandez Riera]

On GPM search reports->memory info-> memory report.

[Paul Spyrou]

"sysdef |grep bufpages" will give you the buffer cache usage. It's quoted in 4k pages so multiply the figure by 4096. Non root users should be able to run this command.

[Sridhar Bhaskarla]

Andy,

Try this,

$echo "print TBL_BUFFER_CACHE_USED" > rept

$/opt/perf/bin/glance -adviser_only -i 1 -j 1 -syntax rept

This will continously report the buffer cache usage. Also, you can varie the values of i and j to get the desired interval and iterations.

-Sri

[Andy Zybert]

Both glance 't' & 'm' report buffer cache usage but if the system loads with dbc_max_pct @ 50% on a 1Gb system the usage will never drop from 512Mb unless the system is under memory pressure. I cannot believe the actual usage would never vary depending on the usage of the Filesystems by the processes running.

What I need to know is how much of that 512Mb is actually in use.

[Carlos Fernandez Riera]

Caches by its own funcionality will be full always. If the minimun size for cache is 512Mb (maybe too high depending on the use of filsystems) it will contain up to 512 Mb of files, using most recent used , or more times requested algorimths.

sar -b will tell you % of hits reads in buffer cache.

GPM Reports->system info -> system tables must show the information you want.


Reduce dbc_max_pct and dbc_min_pct and check with sar -b. Values down 85% means troubles with buffer cache.

[Frank Slootweg]

> What I need to know is how much of that
> 512Mb is actually in use.

All of it. Like the name says, the Filesystem Buffer Cache is a cache and a good cache is always kept full. Like you write, *only* if the memory pressure from processes/data becomes too high, the DBC will shrink. If the DBC is at its maximum, then apparently the memory presuure from processes/data is not too high.

The process/data memory also acts like a cache, but it is not kept totally full. The system will try to keep a few perecent free in order to let small interactive processes start quickly. That is why (Glance et al) memory usage percentages of around 95 are quite normal, but anything above some 97% indicates memory pressure.

[Andy Zybert]

The point I am trying to make is that the standard HP default kernel settings for dbc_max_pct 50% dbc_min_pct are normally set too large expecially with systems over 1Gb memory, and that this memory could be more efficiently used elsewhere.

To convince Unix administrators of this fact needs evidence that a reduction will not in itself cause a performance problem. How do I provide evidence if, as indicated cache usage will always be full and read 100% and write >60% usage high.

I assume each f/s entry in the filesystem cache will take up space i.e nKB, and if there are n filesystems then could this be used to size the filesystem buffer cache correctly n x nKB. Or could another calculation be done.

[Carlos Fernandez Riera]

I think that values are too big too.

In my servers i have reduce to 2 to 5 %min and max, for large memory, and 5 to 10 for 1GB boxes, and i cant see any problems. But my database is configured to raw devices, wich avoid double cache.

If you read Fanks response carefully, he says that if cache is on its high value there is not any reason for decrease.

Of course you can reduce buffer cache and increase database cache. I think it is a good idea too.