Buffer cache is fully utilised when there is no filesystem I/O

[Ganesan R]

Hi,

We have a two node cluster where there is one DB package is running on first node. The other node is running idle without any load or application.

We set the dbc_max_pct to 30% on both nodes since it may require when the package is running in any of the node.

But idle(second) node also utilising the 30% of cache memory when there is no filesystem I/O. It is not released the buffer cache. As far as I know there was a package failover and failback for patching work. Other than that there was no activity carried out on second node.

Why is it so? how do we release this buffer cache memory on second node? or is there any improper tuning had been done?

Thanks in advance.

[Steven E. Protter]

Shalom,

Depending on the OS and database, the dbc_max_pct setting may simply be a waste of memory.

Practical experience shows that before 11.23 HP-UX there is no benefit to Oracle filesystem based databases from the buffer cache. Better to reduce the setting and give memory to the Oracle SGA.

The passive node will use its buffer cache if there are no other demands to buffer files the OS needs to use for normal system operations. There is no problem with it being utilized, on a seemingly idle system.

I'd consider decreasing the dbc_max_pct on both nodes, definitely the passive node depending on the actual OS and database in use. I'd test failover before walking away from the settings.

SEP

[Hein van den Heuvel]

Why would you want to release the buffer cache?
'looks better' ? That just creates extra work.
Does it bother / slow down the system?

On the idle system there is supposedly no pressure on the data buffer cache to release anything, and everything eveer touched is still there. Boot stuff, log files, libraries, man pages, everything.

If on the active node the DBC is less than the max, then there are two possible reasons.
- There was not enough io to ever fill it.
- There is pressure for the memory (DB needs it!)

So now you have the choice to trust the dbc code to freely and quickly return memory if needed, or decide that you are smarter then the OS and reduce dbc_max.

It is not unreasonable to reduce dbc_max in your case.

However, it might not make much difference either, notably on hpux 11.31 (you failed to indicate a specific hpux version /patch level used). It'll be hard to measure!

hth,
Hein.

[Hein van den Heuvel]

Btw... the hpux performance cookbook has a reasonable dbc_max write up.

[ I don't like the focus on hit rate. That can be deceptive ]

http://vgwh5proc.cce.hp.com/portal/download/files/unprot/devresource/Docs/TechPapers/UXPerfCookBook.pdf

Hein.

[Tim Nelson]

If I understand your question correctly.

The buffer cache will allocate all that is available to it up to the dbc_max_pct unless other processes need the memory. At that time it will reduce to dbc_min_pct.

So, idle system will always show full buffer allocation.

I second the response for low buffer cache allocations for database servers. Either hard set to a fixed number 100-200MB or set dbc_max_pct to 2% and dbc_min_pct to 1%. Let Oracle use the memory in its SGA.