1833796 Members
4520 Online
110063 Solutions
New Discussion

dbc_max_pct

 
Timothy P. Jackson
Valued Contributor

dbc_max_pct

I have a rp7400 with 4Gig of ram. After looking at my memory usage I found that I was extremely low on memory for users. I looked at my dbc_max_pct setting and it was set to 50. I know that this means that I was using 50% of my memory for buffcache which is not really recommended depending on the situation. I changed the kernel parameter to 13% and all my processes took longer.

I was running and capturing a sar report so that I could see if the change had done any good and it looks like I went the wrong way with my dbc_max_pct .

although my %rcache went down about 10% my bread/s went through the roof.

Is this normal?

Any comments or recommendations?

Any input would be greatly appreciated.
3 REPLIES 3
A. Clay Stephenson
Acclaimed Contributor

Re: dbc_max_pct

Note that you were getting 100% read-cache hit rates with dbc_max_pct at 50%. This means that you were doing almost no physical reads. When you reduced the buffer cache to more reasonable values then number of physical reads increased. When you do a ratio of a moderate number to what was a very small number, that change becomes very large but it does not necessarily mean anything is wrong. It's very difficult to make meaningful comparisons without knowing the sampling interval. You numbers may simply be a small sample set. Gather your metrics over a period of at least a few minutes and make sure that you are comparing apples to apples.

One thing that really strikes me is the very high number of logical i/o's with a ralatively small number of physical i/o's. This means that your code is rereading data that it really already "knows" and suggests that better algorithms are needed. If this is SQL then some better coding should be done.

The "correct" value for your buffer cache size is "it depends" but if you can't better tune your code then your perform,ance metrics indicate that you should bump the buffer cache up to perhaps 25% but I strongly suggest that you have a look at youir application code.
If it ain't broke, I can fix that.
Peter Godron
Honored Contributor

Re: dbc_max_pct

Timothy,
sadly, tuning is a slow and delicate process.

Please read:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=252307
It has a few tuning links as well.

What is your dbc_min_pct set to ?

Note: The timestamp is the same on your sar output ?
Timothy P. Jackson
Valued Contributor

Re: dbc_max_pct

Thank you all for your quick response!

My polling on the sar -b 1 is 60. Not very long but I really didn't expect this big of an inpact on the processing time. I know that the code is in most places poorly written, but there is no way to rewrite it.

So, I guess my best option is what Clay recommended and increase my dbc_max_pct up to 25% and see what happens. If this does not help I will have to go back to 50%. This of course would only be until I can get some more memory in the machine.

Thanks again for your input!

Tim