Increase maximum per-process open files in 4.1.2? (summary)
2007-12-25 8:23:00
>Is it possible to increase the per-process number of open files in a
>SunOS 4.1.2 system (running on an IPC)? [ beyond 64 ]
>...
I got answers from
Jim Davis <jdavis@cs.arizona.edu>
Mario Nigrovic <mario@wdc.sps.mot.com>
Eckhard Rueggeberg <eckhard@ts.go.dlr.de>
Guy Harris <guy@auspex.com>
Thank you all. Guy's was (of couse :-) the fullest answer, so I
include that below.
Presumably where the sysconf(2) man page says
The value does not change during the lifetime of the calling
process.
it should add
...unless the process calls setrlimit.
Sigh.
-----
Return-Path: <guy@auspex.com>
Received: from AUSPEX-GW.AUSPEX.COM by relay.pipex.net with SMTP (PP)
id <07694-0@relay.pipex.net>; Wed, 21 Jul 1993 22:50:16 +0100
Received: from auspex.com (auspex.auspex.com)
by auspex-gw.Auspex.COM (4.1/SMI-4.1) id AA13308;
Wed, 21 Jul 93 14:50:01 PDT
Received: from bootme.auspex.com by auspex.com (4.1/SMI-4.1) id AA22394;
Wed, 21 Jul 93 14:49:58 PDT
Date: Wed, 21 Jul 93 14:49:58 PDT
From: guy@auspex.com (Guy Harris)
Message-Id: <9307212149.AA22394@auspex.com>
Received: by bootme.auspex.com (4.1/SMI-4.1) id AA07657;
Wed, 21 Jul 93 14:50:50 PDT
Subject: Re: Increase maximum per-process open files in 4.1.2?
>Is it possible to increase the per-process number of open files in a
>SunOS 4.1.2 system (running on an IPC)?
Yes.
>I've tried changing NOFILE in /sys/sys/param.h, and also NOFILE_IN_U
>in /sys/sys/user.h before rebuiling the kernel, but to no avail.
Neither of those will help.
The first governs the size of a data structure in the kernel, so to
change it successfully, you'd need to recompile from *full* kernel
source and *also* rebuild any user-mode code that depends on the layout
of the U area (the "-lkvm" library, etc.).
The latter is used in compiled-in code in a kernel module source to
which is not supplied.
However, you presumably noticed that NOFILE is greater than NOFILE_IN_U,
and that the limit you're currently seeing is NOFILE_IN_U:
>sysconf(_SC_OPEN_MAX) and getdtablesize() both continue to report 64
>(correctly: open()s fail after fd 63).
so:
>I can't find anything in the documentation on this.
Check out "GETRLIMIT(2)"; you'll find
Limits on the consumption of system resources by the current
process and each process it creates may be obtained with the
getrlimit() call, and set with the setrlimit() call.
The resource parameter is one of the following:
...
RLIMIT_NOFILE one more than the maximum value that the
system may assign to a newly created
descriptor. This limit constrains the
number of descriptors that a process may
create.
so:
>Is it possible,
Yes.
>or is 64 hardwired in?
No.
The default "soft limit" for RLIMIT_NOFILE is 64 (NOFILE_IN_U); the
"hard limit" is 256 (NOFILE).
If you crank the "soft limit" up above 64, you get more than 64 file
descriptors. You can do that in a program with "getrlimit()" and
"setrlimit()"; you can do it from the C shell with the "limit" command:
limit [ -h ] [ resource [ max-use ] ]
Limit the consumption by the current process or
any process it spawns, each not to exceed max-use
on the specified resource. If max-use is omitted,
print the current limit; if resource is omitted,
display all limits.
-h Use hard limits instead of the current lim-
its. Hard limits impose a ceiling on the
values of the current limits. Only the
super-user may raise the hard limits.
resource is one of:
...
descriptors Maximum value for a file
descriptor.
You can't raise the hard limit above 256 in SunOS 4.1[.x] without the
aforementioned complete recompile from source, except by getting Sun's
DataBase Excelerator, or whatever "DBE" stands for, product, which
cranks it up to 1024.
In SunOS 5.x, the hard limit is 1024, and the Bourne and Korn shells let
you get and set the limit with the "ulimit" command. (The latter should
be true of all SVR4 systems; dunno what the hard limit is in other SVR4
systems.)
-----
Tim.
--
Tim Goodwin | tim@pipex.net or | Usenet will also be converted to OSI-based
PIPEX Ltd | tim@unipalm.co.uk | services in the long term - B Plattner et al.
Comments
Got something to say?
You must be logged in to post a comment.
