system very slow

[Hisham Ahammed_1]

Hi all,
i am facing a problem in a development server.without much load it self, the system is very slow.here is the details of the machine
model -D250
OS- HP-UX 10.20
Physical mry 128MB
Swap 196MB
from sar reports ( using sadc) it is found that
1-sar -b gives
%rcache value mostly 0%. very rarely it gave 86,98,93,33 values and it just 5-6 times
2-sar -w gives
swpin/s=0.00
swpot/s=0.00
pswch/s gives the values from 9-14-11-55-112-11 at an avg of 38
3- sar -u gives high %wio
%usr is btw 0-3
%sys is btw 0-5
but %wio is 92-97

doubting about the buffer cache, i went through the Kernel parameters
the o/p of sysdef shows
buffpages=16384 ( 64MB)
nbuf =8436
dbc_max_pct and min_pct carrying the default values (50 and 5)
when i go via sam and Config parmscurrent value fount to be
buffpages=0
nbuf=0
dbc_max_pct=50
dbc_min_pct=5
the pending value is also same.

these are my douts
1-what is the right values for the sar output.if sombody have some docs/links related to that it will gratel appreciated.whether above values are normal?
2. why this much %wio is coming without any load.
i went thru sar -d , but none of the disks fount to be more than 10% busy.

3- in my knowledge sysdef will give current utilisation of Kernel prms, but how sam is giving some diff value

the system is used for COBOL related development it is having Object COBOL/UX developers bundle and Object COBOL runtime Bundle.
here r some Kernal parameter
values


pls help me to come out this problem

TIA

hba

[Patrick Wallek]

Are you having any problems with any of your disks? It sounds to me like it is waiting to write something to disk and the disks are being slow in responding.

[Tom Geudens]

Hi,
Just of the top of my head I would say that you should definitely lower dbc_max_pct (to 15% or even lower) ... the default value is way to high.
Otherwise I would advise you to take a look at http://h21007.www2.hp.com/dspp/files/unprotected/devresource/Docs/TechPapers/UXPerfCookBook.pdf and see if that gets you any further. It's a very good document that helped me several times already ...

Hope this helps,
Tom Geudens

[Hisham Ahammed_1]

dear patric
there is no bottleneck coming from any disk system. max busy coming only on on disk and that also only 10%

dera tom,
i told u that i am really confused becoz sysdef is saying that dynamic buff cache is not enabled ie non zero value is there for both buffpages and nbuf but sam is saying that dynamic buff cache is enabled ie defaul valuesfor dbc_max_pct ,min_pct and
buffpages,nbuf is zero

rgds

hba

[Steve Steel]

Hi

Tom is certainly correct with the memory you mention and the setting of dbc_max_pct.

If you look at swapinfo -t you will see a large slice of your memory being used as
buffer cache while there is insufficient left for your processes.

This could cause excessive swapping when cobol is used giving a low speed and high wio.

Go to between 10 and 20% for dbc_max_pct and
it will improve.You also seem to be a little on the low side for swap.

When the machine is slow check
/var/adm/syslog/syslog.log for messages and
look at swapinfo -t for memory use.

Also recommend that you get a copy of glance which makes this sort of testing much easier.


Steve Steel

[Hisham Ahammed_1]

hi

do you fell this is only a buffer cache related probs.
that means i have to see only the sam values not the sysdef values.
can anybody pls give some idea what exactly should be the values of varous sar output.
i will assign you points once become free from this probs

rgds

hisham

[Trond Haugen]

Trust the kernel values for buffpages nbuf dbc_max_pct & dbc_min_pct.
When using dynamic buffer cache sysdef WILL report values for buffpages & nbuf.

I agree that dbc_min_pct=50 is too high.
10-15 is probably better.
There has been some discussion about is but my recommendation is also to set swapmem_on=0.

[Hisham Ahammed_1]

hi trond
swapmem is on ie 1
i doubt if am changing dbc_max_pct to lesser value whether it will give more problem.lesser value means lesser amount of memory for buff cache. already %wio is very high (92-98).if i am again decreasing the memory for buff cache?am i right? if not pls correct me in that.

rgds
hba

[Ruediger Noack]

Hi,

there is definitively a i/o bottleneck on your system how %wio parameter of sar shows!
I/o bottleneck don't only occurs on a special disk. May be your bus or controller isn't able to serve the nessasary throughput. How man disks do you have on your scsi controllers? How much is the sum of %wio of all of this disks.
Reducing of dbc_max_pct is a good idea generally but I don't believe it is a solution for your bottleneck.

Ruediger

[Rita C Workman]

Hi Hischam

You seem to misunderstand what dbc_max_pct is doing...

put simply that parm is taking 50% of your cache off the top for the system to use. That is 50%...and what is the operating system doing with it..nothing..just holding onto it like a hungry little mouse.
If you have pseudo swap enabled (which I believe you mention you do) and you have nbuff set to 0 (which means the buffer cache is set for dynamic caching, which you need)...than give it the buffer cache it need to run processes.

LOWER YOUR DBC_MAX_PCT....

If your so nervous, try lowering it to 25...then monitor...then try 20..monitor and when you see you can go lower...than do it. You don't want to cheat the O/S out of what it needs...but you don't need to overdress it either !! And that is what 50 is doing...so TUNE THAT PARM...
that is what the job is all about..

Rgrds,
Rita

[Hisham Ahammed_1]

hi Rita and Noack,
thanks Rita to clear me about dbc_max_pct. i will do the necesory changes and getback to you all. this possible only on Monday till time i have to wait

rgds

hba

[Nagarathinam]

Hi,
I feel that
a) dbc_max_pct to be reduced to 15%
b) Kindly check for some the runaway process

A.Nagarathinam

[T. M. Louah]

here's a situation you might be interested to check:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,11866,0x997cabe92dabd5118ff10090279cd0f9,00.html

t++

[Bill Hassell]

Unless your COBOL developers are writing short programs (a few hundred lines), the system is being strangled by a lack of RAM. 128 megs is so small that just running SAM requires several dozen pages to be page out to the swap area. I would add 1000 megs of RAM to allow the COBOL activities to proceed at normal speed.

While additional RAM may seem to be expensive, you must compare the very, very slow response (caused by serious page-out rates) time and how much labor is being wasted waiting for large compiles and other tasks to complete.