Changing Kernel Upper Limits

[Michael Tully]

Hi,

I am being asked to change the upper limit
of kernel parameters, to enable an application
to run. I am concerned about being led down
the garden path by a bunch of developers
without them presenting evidence that this
is an actual requirement.

My question is basically has anyone out there
had to change the uppers limits on kernel
parameters before and what ramifications were
encountered. I know how this is done, I just
want to get feedback on the subject.

The parameter in question is 'maxfiles_lim'
and there could others. The upper limit is
listed as 2048, and they wish to make it 4096.
The application is PeopleSoft 8.1.4
Informix version 9.21h3c (5 instances)
HP-UX 11 on L class

TIA
-Michael

[Patrick Wallek]

What exactly do you mean "...change the uppers limits on kernel parameters..."?

Check out this site:
http://docs.hp.com/hpux/onlinedocs/os/KCparams.OverviewAll.html

And here is the page for maxfiles_lim http://docs.hp.com/hpux/onlinedocs/os/KCparam.MaxfilesLim.html

The absolute maximum imposed by HP-UX is 60,000 so you should have no problem whatsoever changing the parameter to 4096.

All kernel parameters have an absolute maximum that is imposed by the HP-UX operating system. There is absolutely no way (other than changing the code of HP-UX - and I doubt you have the access to do that :) ) to change those maximum values.

I do commend you for questioning the developers and trying to figure out what they really need.

[Bill Hassell]

Well, the last time I saw a database application that needed THOUSANDS of files was UniData and UniVerse. As a sysadmin, I cannot see any justification for a single program to open even 500 files, much less 5,000 files. I remember this type of a design was used as a bad example for many database concept classes.

But there is help, even for a poor design: HP-UX 10.20 and 11.00+ allow this limit to be raised to as high as 60,000 (I don't want to associated with any design that tries to use even half that number in a single program).

Although the /usr/conf/master.d/core-hpux file contains the following lines:

*range maxfiles<=2048
*range maxfiles_lim<=2048

the kernel can still be compiled manually with values for maxfiles and maxfiles_lim larger than 2048. As explained in unix document
UNX1010203, 60000 is the upper bound for these parameters in HP-UX 10.20 and above.

At HP-UX 11.0 SAM relies on the /usr/conf/master.d/* files to set the
upper and lower values for kernel parameters. At HP-UX 10.20 the /usr/sam/lib/kc/params.tx file was used. To allow SAM to support setting either maxfiles or maxfiles_lim to larger than 2048, the above lines in the /usr/conf/master.d/core-hpux file must be changed to:

*range maxfiles<=60000
*range maxfiles_lim<=60000

After making the change, SAM may still have stored the old values within the /var/sam/boot.config file. The boot.config file can be renamed to have SAM to recognize the changes made to the core-hpux file and rebuild SAM's tables. After moving the boot.config file, restaring SAM should cause this file to be rebuilt using the new values.

/usr/sam/lbin/getkinfo -b can also be used to recreate the boot.config file.

Similarly, if maxfiles or maxfiles_lim have been set manually to values larger than 2048, the above steps can be used to prevent SAM from
erroring on the parameter's values when entering the Configurable Parameters menu item within SAM. Without making the above changes, SAM will typically reset the "Pending Value" for these parameters back to 2048 anytime SAM is used.

[linuxfan]

Hi Michael,

I was wondering why did you want to use such a high value?

After Bill gave such a clear and precise explanation, i am sure i don't need to go into the details of how to do it, but what i am wondering is why do you need to do it?

Are you running multiple ERP (in this case Peoplesoft) application as the same user?
Multiple versions of peoplesoft? Are you developers running into a problem right now that they are asking you to incrase this value?

-Regards
Ramesh

[Michael Tully]

Hi,

Thanks guys for the feedback so far. What I am
trying to avoid here is people going off
half cocked without having the correct type
of information to begin with. Developers
will be developers unfortunately, blaming
anything and anybody before admitting that
there just might be a possibility that there
is something wrong with their own coding.....

The particular comments made by gentlemen
such as yourselves in this post backs what
what I already thought and is greatly
appreciated. This more or less gives me the
right ammunition to go back to these
developers with opinions other than my own.
Perhaps they may listen when more than one
voice is spoken.

I will keep this post open for a few more days
to see if others wish to have their say...

Again thanks!!