maxfiles & maxfiles_lim kernel parameter

[Nikhil Dubey]

maxfiles - Soft limit on how many files a single process can have opened or locked at any given time.

maxfiles_lim - Hard limit on how many files a single process can have opened or locked at any given time

As per the definition, maxfiles_lim >= maxfiles..Is this correct ??

Is there an HP document to support this statement .

Thanks for the assistance.

[Mel Burslan]

I am not sure if you can find any "proper" hp documentation but the definition of the two kernel variables should be documentation enough in my opinion.

Also, unless you mocked with manual kernel compilation and forced it to do somethings unheard of, unless the condition you stated is satisfied, you can not successfully compile a new kernel.

Hope this helps

[Nikhil Dubey]

Thanks for the reply...I asked this because in our environment the maxfiles > maxfiles_lim i.e maxfiles is set to 2048 whereas the maxfiles_lim is set to 4096.

Thanks.

Nikhil

[Nikhil Dubey]

oops...I wrote opposite..maxfiles is set to 4096 whereas maxfiles_lim is set to 2048.

Thanks and Regards.

Nikhil

[A. Clay Stephenson]

Actually, in HP-UX 11.11 and up, maxfiles_lim is dynamic while maxfiles is static. Surprisingly, maxfiles_lim can be set below maxfiles although why one would ever want to escapes me.

[Steven E. Protter]

Another one to think about.

maxuprc

Max users for a single user.

The default is 75 and some oracle servers need more than that.

Most Oracle shops bump it up to 200.

SEP

[Bill Hassell]

You can set the values incorrectly (maxfiles greater than maxfiles_lim) and the kernel silently enforces the lower limit. maxfiles is simply a starting point, normally set quite low (60 to 120) for ordinary users. Power programs that really need hundreds of files open at the same time will call setrlimit() to change the limit higher. maxfiles_lim is the absolute limit for the number of open files in a single process. Or you can change the limit (just for your shell environment) using ulimit -n.

NOTE: ksh does not implement all the options in ulimit (no options at all for the last 19 years) but with a recent patch now adds ulimit -a and the options listed, but not ulimit -n. Now as far as the actual values: you really have programs that open as many as 2000 files at the same time? Not one at a time, but all of them open at once? The Universe database system can be setup for something like that (it uses thousands of files) but *every* instance of the database program requires that many aditional file handles. If you run 100 copies with 2000 files open at the same time for each process, your nfile kernel parameter must be increased by 20,000.

Mnay, many vendors publish rather simplistic instructions like: maxfiles=maxfiles_lim=2048, probably created by a newbie sysadmin that couldn't figure out which parameter to change and just took a whack at all of them. There is a specific purpose in having maxfiles smaller than maxfiles_lim. By making them both large, any user can write a stupid program that loops around creating thousands of files, eventually using all the kernel's file descriptor slots. At that time, no one login (including root!) or do anything new. It's called a denial of service.