topic Re: dbc_max_pct general question in Operating System - HP-UX

dbc_max_pct general question

Mauro Livi — Mon, 11 May 2009 14:34:19 GMT

Hi,
I have an RP4440 with 4 processors and 32GB RAM. Current dbc_max_pct is set at 15. The system is running fine, no complaints from users and folks are generally happy with the performance.
If I do sar -b I notice that my %rcache in usually in the 90s, but my %wcache is usually low in the 40s 50s or so. I can't help but think that if I lower my dbc_max_pct to say about 10 or so, that would help.
However, given that things are ok and memory/performance have not been problematic, something tells me to leave well enough alone.
What do you guys think...am I asking for trouble by tinkering with things when they may not need tinkering?

Many thanks
Mauro

Re: dbc_max_pct general question

James R. Ferguson — Mon, 11 May 2009 14:50:46 GMT

Hi Mauro:

There's never any harm in tweaking given the time and the ability to empirically measure the results of your change. In your case, it looks like the buffer cache is serving you fairly well.

Regards!

...JRF...

Re: dbc_max_pct general question

Pete Randall — Mon, 11 May 2009 14:54:30 GMT

The standard recommendation is to set dbc_max to yield somewhere around 400 to 700 MB of cache. You currently have about 5GB. I would say you can safely lower it t0 5%.

Pete

Re: dbc_max_pct general question

Matti_Kurkela — Mon, 11 May 2009 15:12:35 GMT

It is not always possible to get a perfect write cache hit ratio. It depends on the access pattern of your applications.

For example, if your application writes data out in reasonably large chunks and never needs to revise any data it has already written, the filesystem metadata updates will be about the only source of write cache hits.

On the other hand, if the application keeps re-writing one particular spot in one file very often, that will be a source of write cache hits. For example, if a data field on disk is originally A, then updated to B, then C, and then D in rapid succession, the cache can get two write hits by delaying the physical write a little. On the logical I/O level, the whole A -> B -> C -> D sequence is seen, but at the level of physical I/O, A is updated directly to D.

I don't quite follow why *reducing* the maximum size of the buffer cache would improve the write hit ratio? I would expect it would make cache hits less probable.

Your numbers look good to me. Don't fix what isn't broken.

MK

Re: dbc_max_pct general question

Mauro Livi — Mon, 11 May 2009 15:13:26 GMT

Thanks for your reply.
Sounds as though the best (and safest) avenue for me on this would be to lower it to 10 (or so) measure/compare to current setting. Then lower again if needed.

Thanks
Mauro

Re: dbc_max_pct general question

Mauro Livi — Mon, 11 May 2009 15:21:16 GMT

What I mean is I may look into "tweaking" this by small increments and see how things are affected. I'm thinking that such small "tweakings" would NOT adversely affect the system (much...I hope).
My paranoia is simply tinkering with something that isn't broke as Matti mentioned.

Thanks Again
Mauro

Re: dbc_max_pct general question

Steven E. Protter — Mon, 11 May 2009 15:23:26 GMT

Shalom,

Sometimes tweaking does cause problems.

Slight adjustments to the buffer cache can open up more memory for other things, or improve performance.

The key thing is to have a plan. You need to know what you change and measure performance fairly.

http://www.hpux.ws/?p=6

That script set, originally created by HP and upgraded by me, might help.

SEP

Re: dbc_max_pct general question

Mauro Livi — Mon, 11 May 2009 15:31:22 GMT

Point well taken guys.

SEP, I already have the script, so I'll utilize it and take measures. Based on those measures, I'll see if lowering dbc_max_pct is warranted. Even then, I would only lower that in small increments as I mentioned, then measure again.

Thanks all

Mauro

Re: dbc_max_pct general question

Mauro Livi — Mon, 11 May 2009 17:54:06 GMT

Thanks again to all who replied. Points have been allocated accordingly.

Mauro