ServiceGuard and dbc_min_pct

[Chuck Ciesinski]

To all,

One of our Basis Admins is proposing reducing the dbc_min_pct to 3%, from 5% on a system which is both an app server andf the fail-over database server. Primary database server is 13 cpus, 56GB memory and dbc_min_pct set to 5%. Currently the fail-over server is 5 cpus, 32 GB of memory and also set to 5%. Ignoring the fact that we would experience performance degradation ( short term) and a CCMON discrepancy, would this change be detrimental to our ability to use ServiceGuard and not fail-over? Or should I not be concerned?

Chuck Ciesinski

[Geoff Wild]

You could drop to 2% for min as well as max with 56GB of ram if you wanted to.

All this effects is the buffer cache for non Oracle file systems.

With 56 GB of ram - are you exhibiting memory pressure? That would be one of the few reasons to lower the size of the buffer cache...

Rgds...Geoff

[David Bellamy]

It will have no effect on ServiceGuard or fail-over,all kernel parameters on systems do not have to be the same for ServiceGuard to work.

[Patrick Wallek]

This change should not affect SG at all. I also don't see any way it could affect you ability to fail-over from the primary node.

Reducing dbc_min_pct will only reduce the MINIMUM amount of buffer cache used (from 1.6 GB to 960 MB). This minimum probably will not be in effect for very long after a reboot. As usage increases, buffer cache size will increase to dbc_max_pct.

Speaking of dbc_max_pct, what are you doing with that? If you are leaving as is, then you buffer cache will eventually grow to dbc_max_pct size.

I see no real harm here, but I see no real benefit, other than a short term RAM gain right after a reboot.

[A. Clay Stephenson]

This falls under the heading of "Big Woo" --- assuming this is 11.11 and up. The performance difference between a min_dbc_pct setting of 5% and 3% is going to difficult to observe on any sort of repeated basis. I doubt that I would bother with this change.

I'm usually more concerned with an asymmetric main/failover arrangement with database tuning and application tuning. For example, shared memory usage that is perfectly reasonable on a box with 56GiB of memory may bring a box with 32GiB to its knees --- unless those configurations change with the host. If you are using identical database and application tunings on the main and failover boxes then if anything I would take the production box in the opposite direction (ie, increase dbs_min_pct and dbc_max_pct so that the actual memory left after caching more closely resembles that of the failover).

[Chuck Ciesinski]

Geoff,

The memory pressure is on the App server(s) and the Basis Admins are worried about page swapping. I've added a .doc file with last weeks charts. Also added the second app server which is also 15 cpus and 14 GB of memory. Basis is proposing change on both app servers to save memory.

Chuck

[Patrick Wallek]

Chuck,

Please see my reply above. Changing the dbc_min_pct value is not going to help. That is the absolute MINIMUM that is starts GROWING from.

You would be better served looking at dbc_max_pct as that is the MAXIMUM size that buffer cache can ever get to. You haven't mentioned what that variable is set to.

Decreasing dbc_max_pct will DECREASE the MAXIMUM size, thus having a potentially larger impact on RAM usage.

You don't mention what version of HP-UX you are on, but starting with 11.11 buffer cache behavior has been greatly improved.

When the server is under memory pressure buffer cache usage will decrease automatically.

It really sounds as if messing with the dbc_*_pct parameters is not really going to "fix" your problem. I think you would be much better served by upgrading the RAM on these machines.

[Steven E. Protter]

Shalom,

dbc_max_pct may need adjustment. On 11.11 there is no evidence that increasing that parameter improves oracle performance, better to lower it to help your oracle db.

Some folks have seen it help with 11.23 and Oracle.

SEP

[Bill Hassell]

According to the graph titles, there is indeed a lack or RAM and therefore page-out is occurring. The only question is what is the rate. vmstat will show the page out rate. If this column (during peak loads) is 3 digits or more, 56GB is far too small for your applications. 64GB might help but you probably need 72GB for comfort and growth. Large scale systems can be crippled by excessive page outs. The proposal (dbc% changes) is far, far too little to help.

As far as SG, you can fail over just fine as long as there is plenty of swap space *and* users can be extremely patient due to the very slow system. Since you have SG, it is imperative to failover once in a while, and in this case, to actually see the impact that removing 24GB will have. There is no substitute for RAM when performance is important.