Original post below. The problem was how to modify the kernel parameter
nlock_record as it doesn't exits in dxkerneltuner on 4.0F. Thanks to Dr.
Thomas Blinn, Stuart Hartley, Bryan Lavelle and Chris Bryant.
Recommendations were to do a dbx patch, or to edit the kernel config file.
I ended up doing the dbx patch command:
(dbx) patch nlock_record = 20000
Dr. Blinn also provided the name of the file with the source level
defination which has comments describing the parameter.
Best Regards, Blake
>>>>>ORIGINAL POST
> Tru64UNIX 4.0F pk3
>
> We have been advised that there is a kernel parameter, "nlock_record",
which
> is part of "options"???, that we are to increase for our application:
>
> #: dbx -k /vmunix
> dbx version 3.11.10
> Type 'help' for help.
> (dbx) p nlock_record
> 10000
>
> We were also told that this requires a rebuild of the kernel, as it is not
> of the run-time parameter type. I'm unable to find it in dxkernertuner,
and
> any documentation on it.
>
> Preferably, I'd like to avoid the kernel rebuild, but will if necesary.
Is
> there a way to up this parameter to 20000 within kerneltuner?.....or some
> other way outside of kerneltuner?
<<<<<<<<<
>>>>>>>Dr. Thomas Blinn
Hmm... That's a totally new one on me.. The source level definition
is in a file called "vfs_conf.c" which lives in /usr/sys/vfs and the
default value is 10000 ; the comments in the file say
/*
* Allow adjustment of the maximum number of locks that may be held.
* The space required is allocated as necessary but is limited so a
* wayward program can't eat up all of kernel memory with lock structures.
* nlock_record may be overridden by something like
* "options nlock_record = 20000" in the config file.
*/
So, since the value is apparently stored in a global variable you could
in theory just use dbx to patch the value in your kernel file on disk,
and then reboot. For that matter, the only use I can find in the source
is this:
if ( flckinfo.reccnt >= nlock_record )
in this broader context:
/* XXX
* The intent of nlock_record was to prevent a wayward process from
* chewing up too much kernel memory. A global limit helps, but
* still allows a single process to prevent others from allocating
* file locks. This is probably best addressed with a process
* resource limit.
*/
if ( flckinfo.reccnt >= nlock_record )
return( NULL );
so it looks like you can patch it in the RUNNING KERNEL and then you'll
have a higher limit. Of course, patching the running kernel is risky,
and I'm not going to try to explain how to do it. But you could..
The kernel tuner knows NOTHING about this limit. So you have to do it
with dbx or by building a new kernel.
<<<<<<<<<
>>>>>>>Stuart Hartley
We had a similar need and could not find a way to do it except by putting it
into the kernel (NLOCK_RECORD)
I think that on later versions of the OS (v5.0 or highrer) it is possible to
put it in sysconfigtab, but we have not found a way to do it under v4
<<<<<<<<
>>>>>>>>Bryan Lavelle
You might be able to use the dbx "patch" command, which will keep
nlock_record at your chosen value until the next reboot, or the dbx "assign"
command which would keep the value until the next kernel rebuild, at which
time you'd need to reassign.
dbx> patch nlock_record=20000
OR
dbx> assign nlock_record=20000
I think that is the correct syntax.
<<<<<<<<
Chris Bryant>>>>>>>>
Look in the kernel config file ( /usr/sys/conf/HOSTNAME ) there should be a
line that say's "options NLOCK_RECORD = some_number" if it is not in the
file then you will need to add this line and rebuild your kernal with the
doconfig command. I hope this helps.
<<<<<<<<<
Received on Thu Jun 07 2001 - 23:43:09 NZST