Getting current utilization value of tunable kernel parameters

[Tom Krocak_1]

I would like to be able to find out high water values for a number of kernel parameters NOT included in glance/gpm. There must be a counter that is kept in HPUX for parameters that have max values and that is the counter that I need to query to monitor how close to the maximum the current usage is. Does anyone know how to do this, hopefully usable in a script or other programmatic way?

[Ivan Ferreira]

Is it kmtune -l what you are looking for?

For example:


Tunable vxfs_bc_bufhwm
Description VxFS metadata buffer cache high water mark
Module vxfs
Current Value 0 [Default]
Value at Next Boot 0 [Default]
Value at Last Boot 0
Default Value 0
Constraints vxfs_bc_bufhwm == 0 or vxfs_bc_bufhwm >= 6144
Can Change At Next Boot Only

[Dave Hutton]

Which version of hpux?

11.23 you can use kcusage to see the current values and probably could parse out the information you want.

[Tom Krocak_1]

No, kmtune only returns the current value of the parameter (i.e. max value) not the current utilization of the parameter. For example, for "nfile", we have a parameter value of 70732. Glance and MeasureWare report the current utilization towards this max value. For the nfile, we see utilization of 51682 (for example), well below the max kernel parameter, so we know we are OK for now. We have also looked at "sysdef" and "tuneinfo", but these provide similar information as kmtune and not the utilization values at the time of measurement.

[Tom Krocak_1]

We are on version HPUX 11.11. I couldn't find a "kcusage" on our system.

[A. Clay Stephenson]

sar -v will report the number of files in use but to do this on a tunable by tunable basis is a far from trivial exercise --- and is not even meaningful of possible with a number of tunables. Probably your least evil approach is running Glance in -advisor_only mode looking for a number of parameters.

[Sundar_7]

Tom,

you can use adb to get some of this information

# adb64 -k /stand/vmunix /dev/kmem
$> /tmp/something
$e
$q
#

# grep nfile /tmp/something

- Sundar

[Tom Krocak_1]

Sundar,
I tried the "adb64" command as you gave it and searched the output file. For nfile and nflocks, the values given were the same as the max parameter (in hex), not the current usage value. This file doesn't appear to have actual usage towards the max values.
------------
Clay,
I would need a quick primer on how to use glance in "advisor_only" mode, but doesn't this just report on actual metrics recorded by measureware? The only related metrics in MW are those beginning with "TBL_" and there are only 8 of these for HPUX, the same ones reported by "glance -t".

[Don Morris_1]

It's going to vary widely by what tunable you're talking about and unless you use supported APIs [not adb to guess kernel variables] it can change with patches.

For nfile, you want pstat_getdynamic(). psd_activefiles is the field within there which is the current number of active file table entries (which is what nfile bounds). Similarly, nproc's usage is reflected in psd_activeprocs, etc.

[Tom Krocak_1]

Don,
I checked the adb log file and there were no such variables (xxx.psd_activefiles, etc) in there. We don't have any of the special API's installed, so perhaps we are barking up the wrong tree using this approach.

[Don Morris_1 · Accepted solution]

Those aren't global kernel variables, they are fields in the structure passed to/from the user space pstat_getdynamic() system call.

Trust me, you have pstat(). Read pstat(2) for more details.

Here's an example (ignore the horrid formatting -- I'm not going to figure out how to get this web interface to tab nicely... :) ):
# cat nfile_usage.c
#include
#include
#include
#include

int
main(int argc, char **argv)
{
struct pst_dynamic psd;
int rv;

rv = pstat_getdynamic(&psd, sizeof(struct pst_dynamic), 1, 0);

if ( rv > 0 ) {
printf("Number of files in use: %ld.\n",
psd.psd_activefiles);
} else {
printf("pstat_getdynamic failure: %d.\n", rv);
}

exit(0);
}

Compiled with:
# cc +DD64 -D_PSTAT64 -o nfile_usage nfile_usage.c
# ./nfile_usage
Number of files in use: 307.

Not every kernel tunable usage can be easily determined -- a list of the ones you want would be helpful.

[Tom Krocak_1]

Don,
GREAT! It works (needed to tweek code since we must have a gnu C compiler rather than an ANSI compiler).

Our Progress DBA wanted to know high water usage values for the following kernel parameters in addition to those reported in glance/MW:
shmseg, shmmax, semmsl, semmns, semmnu, msgmap, msgmax, msgmnb, msgmni, msgseg, msgssz, msgtql.

Thanks - Tom

[Jeff Schussele]

Hey Tom,

That was a pretty elegant solution.
Throw the guy bone - assign points.
It's the right thing to do.

Jeff

[Raymond Kelly]

Don,

This looks like a very useful script, unfortunately, I am not able to compile it.
Apparantly, my compile does not like the following line:
main(int argc, char **argv)

Is there no other way to get this info?

I am not sure which compiler we are using (I'm pretty new to this).

Any help would be appreciated.

Raymond

[Tom Krocak_1]

As I noted, I also had to make a few changes in the "c" code to make it work - in the same area you had problem. The changes I made are below and them I was able to compile and run the program:

int
main ( argc, argv )
int argc;
char **argv;

(The code before and after are the same)

Unfortunately, most of the kernel highwater values are not available under HPUX 11.11. I found this out when I called HP. They said that more of these are available under 11.23

[Bill Hassell]

> Our Progress DBA wanted to know high water usage values for the following kernel parameters in addition to those reported in glance/MW:
shmseg, shmmax, semmsl, semmns, semmnu, msgmap, msgmax, msgmnb, msgmni, msgseg, msgssz, msgtql

Many of these parameters are limits or fences so they are not 'consumed' like nfile or nproc. Therefore, there is no concept of a highwater mark. If a program asks for a shared memory segment that is less than shmmax, then the program works. If it asks for more than the limit, the call fails. The best solution is to use ipcs (with lots of options) to monitor IPC metrics.