decreased dbx_max_pct - system seems sluggish

[Jason Youzwak_1]

Hi,

I'm using an HP 9000 box, with 16 processors, and 32 Gig Ram.
I noticed that buffer cache was using 16Gig of the ram.
So, I modified some kernel parameters.

The original values were:
dbc_max_pct 50
dbc_min_pct 5

The new values are:
dbc_max_pct 3
dbx_min_pct 1

The buffer cache is now using 982Mb.
However, the system seems to slowdown from time to time. (ie) I type a character, and it takes up to 30 seconds to see the character).

Could I have set these values too low for my machine?
I am running two Oracle instances, about 12 java processes, and between 1-12 single threaded C processes that are CPU-intensive.

Thanks for any help,
jason

[John Poff · Accepted solution]

Hi,

I wouldn't think that trimming down your buffer cache would slow down your system. Do you have Glance/Measureware on the box? If so, can you pull some stats for the system during the times it gets slow? Did you change any other kernel parameters?

JP

[doug mielke]

It sounds like it.

check sar -b for % on r+w to see the hit rate. If less than 50%, cache might need to be raised. Also, check sar -d, look for access times (last column 0n right) for times over 100ms to check that a disk is not slow or rereading (it could have been slow before, but condition hidden by the large cache)

[Jason Youzwak_1]

Hi,

Thanks for the quick responses!

I have used glance, but did not see anything suspicious:

Total VM : 7.09gb Sys Mem : 1.92gb User Mem: 4.33gb Phys Mem: 32.0gb
Active VM: 6.69gb Buf Cache: 982.1mb Free Mem: 24.8gb

Swap Device Type Avail Used Priority
--------------------------------------------------------------------------------
/dev/vg00/lvol2 device 4.0gb 0mb 1
/dev/vg00/lvol9 device 4.0gb 0mb 1
pseudo-swap memory 25.8gb 682mb na

I did change another kernel parameter:

Original value:
maxdsiz 1073741824
maxdsiz_64bit 1073741824

New value:
maxdsiz 2147483648
maxdsiz_64bit 2147483648

However, according to "top", the processing are taking up 800Mb memory or less. So, I don't think that this should be causing any problem.

I have also noticed that "du" is taking a longer time than usual. (Seems like a candidate for the buffer cache.)

According to sar, it seems like my reads are okay, but the writes may be an issue:

shell: sar -b 1 10

12:51:01 bread/s lread/s %rcache bwrit/s lwrit/s %wcache pread/s pwrit/s
12:51:02 0 52 100 2 3 33 0 0
12:51:03 0 0 0 5 5 0 0 0
12:51:04 0 4 100 7 1 0 0 0
12:51:05 0 11 100 0 6 100 0 0
12:51:06 0 385 100 3 16 81 0 0
12:51:07 0 3 100 7 3 0 0 0
12:51:08 4 12 67 4 10 60 0 0
12:51:09 2 19 89 4 4 0 0 0
12:51:10 5 61 92 6 0 0 0 0
12:51:11 2 0 0 0 6 100 0 0

Average 1 54 98 4 5 30 0 0

(It's not slowing down a terrible amount currently.)

I'm assuming that I should probably increase my buffer cache. Perhaps to max 20%, min 5%.

Does this sound like a good idea?

Thanks,

--
jason

[Helen French]

To completely clarify the doubt, I would defenitely increase the value of dbc_max_pct to 10 or 15% and will observe the performance. Increasing or decreasing this kernel parameter is depend up on your application and processes buffer cache usage. Set it to the optimal value for your environment.

[Steven E. Protter]

Perhaps use this sar script to collect some performance data.

Attached.

SEP

[Lee Huei]

with
dbc_max_pct 3
dbx_min_pct 1

About 960Mbytes is allocated for dynamic buffer.

If you were to tune dbc_max_pct to 15, about 4.8Gybte max will be allocated to buffer cache

In fact anything greater than 250 megs of memory allocated to buffer cache in
most environments is excessive. As you have been informed the buffer cache will take memory much easier than it gives it back so it's better to properly tune the buffer cache so that it can't take more than it
needs to be efficient.

check with sar -b, it is desirable to see %rcache >=90% and %wcache >=90%

ideally, we want to see average %wcache of 95% or greater. If the system is consistently showing %wcache less than 75% it would be adviseable to lower the value of dbc_max_pct.

[Norman_21]

Hello,

Please find attached a good cock book for tuning performance! Here is a cut and paste:
Keeping the default values for systems with a large amount of RAM can have a negative impact on performance, due to the time the lower level routines that check on free memory in the cache take.

To monitor the use of the buffer cache run the following command :

sar -b 5 30

You will see output similar to :

bread/s lread/s %rcache bwrit/s lwrit/s %wcache pread/s pwrit/s
0 95 100 1 2 54 0 0


Ideally we want to see an average %wcache of 95 or greater. If the system consistenly shows %wcache less than 75 it would be advisable to lower the
value of dbc_max_pct.

[Alan Turner]

Apologies if this is a stupid question, but why
should we REDUCE dbc_max_pct if %wcache is
below 75% (desired value being >= 95%)?
I know the cook book says to reduce dbc_max_pct
if %wcache is too low, but I'd have thought
you'd get more cache hits if the cache was
bigger, rather than smaller.

[Joe Short]

Alan,

Simply put, buffer cache takes up physical memory. The more memory it takes, the less there is available for other uses. So, by using 95% as a target, you can trim it down to it's most efficient size. This allows you to leave as much memory as possible for other uses.

[Tony Horton]

Hi Alan,

I was thinking exactly the same thing. The only reason I can think of is maybe it assumes that if you are using too much memory for buffers you will be getting excessive paging (which I guess isn't buffered), hence skewing the cache hits.

Regards,

Tony.

[Alan Turner]

Tony, Joe

Thanks for your responses - sounds like a consensus of "don't know".

Jason - apologies for diverting your thread. Did you make any changes? What effect did they have?

regards

Alan

[Jdamian]

Jason

I think setting dbc_min_pct value to 1 is too small. It's smaller than the minimum value.
Browse the following URL

http://docs.hp.com/hpux/onlinedocs/939/KCParms/KCparam.DBCminPct.html

[Jason Youzwak_1]

All:

Thanks everyone for the help - I appreciate the valuable insight, suggestions and discussions.

I have changed the parameters to:

dbc_min_pct 5
dbc_max_pct 25

This seems to have helped - now 8Gig is being assigned to the buffer cache.
This seems too big at first, but realize that the machine has 16 processors - which means more possible disk activity than a 4 processor machine.

Thanks again,

--
jason