HPUX tunable parameters - high values

[Peyton_2]

At my company a number of HPUX serveres are running with what I consider to be high values for a number of HPUX tunable parameters. As an example: ncallout is set to 50000, nkthread is 30000, nfile is 29000, nproc is 16000 and maxfiles is 5000. I understand that having large values for these parameters may take up additional kernel memory. My question is does having large values for these parameters have any negitive performance imapcts, such as inducing extra ovehead due to large full table scans?

I think that some of the values are higher than needed, but are they doing any harm being that high? Glance seems to give me
information on the global number of proceses active, the global number of file descriptors, the number of file descriptors open for a specific process and a view of the global threads that are open.
Does anyone know how to find the number of callout table entries currently in use?

[Roger Baptiste]

hi,

<>

The three parameters which can cause performance issues are
dbc_max_pct dbc_min_pct and timeslice.
(timeslice should be 1 and the dbc values should be 10 and 5 respectively. This is in a regular case).
Other parameters take memory overhead, as you mentioned, but i don't think they have significant performance impacts. It's just wastage of resources and also there is always a dependency between parameters, so making one hight will make others high too, which may have some unintended consequences, not necessarily performance , but it could be application related too.


HTH
raj

[Scott Van Kalken]

one good place to start is:

http://docs.hp.com/hpux/onlinedocs/939/KCParms/KCparams.OverviewAll.html

This tells you how kernel parameters are related etc...

It sounds like you're running oracle on the box as well, if you check with your DBA on the versions of oracle and what oracle recommends, you can usually work out a nice balance.

[harry d brown jr]

Are any of those servers with what you call "high values" suffering from performance issues?

As for ncallout, it should be set higher than nproc, unless you know better.

http://docs.hp.com/cgi-bin/otsearch/getfile?id=/hpux/onlinedocs/939/KCParms/KCparam.Ncallout.html&searchterms=ncallout&queryid=20020925-164548
or
http://docs.hp.com/hpux/onlinedocs/TKP-90202/00/01/113-con.html

live free or die
harry

[Tracy_5]

I don't think there is a way to find the number of callout table entries currently in use, except maybe with q4.


The following may be helpful to you regarding some of your other concerns:

http://docs.hp.com/hpux/onlinedocs/TKP-90202/TKP-90202.html

I found in the Tunable Reference (Manpages) section, answers to many of your questions. For example,

ncallout:
What Are the Side Effects of Raising the Value of This Tunable?

The tunable value defines how much memory the kernel allocates, so a large value will result in additional physical memory consumption thus reducing the memory available for applications and other uses.


nproc:
What are the Side Effects of Raising the Value?

Memory usage increases largely due to second order tunables such as nfile, ninode, nkthread, and ncallout.

Setting nproc too low can cause application failures due to an inability to fork new processes.

It can be determined how many processes have been used simultaneously prior to the above message by calling pstat_dynamic and examining the psd_numprocsallocd. This field indicates the "high water" mark of the number of processes that have been simultaneously used.


Regards,
Tracy

[harry d brown jr]

So let's say we use ncallout at 50000, and let's say the structure required 128 bytes per. That's a BIg 6.1 megs. In my simple mind that squat and NOT worth my time because 6megs is less than 60 US dollars - worse case at $10,000 per 1GB!!!

live free or die
harry

[Magic_Wand]

See attached . . .

[Peyton_2]

Thanks to all that replied.

The answer from Tony indirectly pointed me to the Kernel Resource Monitor (krmond). This tool looks like it will allow me to
find out what is happening at a low level.

Thanks

Peyton