The Tru64 UNIX operating system sets resource limits at boot time. These limits control the size of system tables, virtual address space, and other system resources.
The default system resource limits are appropriate for most configurations. However, if your configuration has a large amount of memory or is running a program that requires extensive resources, you may need to increase the system limits by modifying subsystem attributes.
This chapter describes how to increase the following system-wide limits:
Process limits (Section 5.1)
Program size limits (Section 5.2)
Virtual memory limits (Section 5.3)
Interprocess communication (IPC) limits (Section 5.4)
Open file limits (Section 5.5)
Instead of modifying system-wide limits, you
can use the
setrlimit
function to control the
consumption of system resources by a specific process and its child processes.
See
setrlimit(2)
for information.
If your applications are memory-intensive or you have a large-memory configuration, you may want to increase the process limits. Increasing process limits will increase the amount of wired memory in the system.
The following
proc
(process) subsystem attributes
control process limits:
System algorithms use the
proc
subsystem
attribute
maxusers
to size various system
data structures, and to determine the amount of space allocated to system
tables, such as the system process table, which is used to determine how many
active processes can be running at one time.
The default value assigned to the
maxusers
attribute
depends on the amount of memory in your system.
Most systems have a
default value of 32.
If you have a large-memory system or your system experiences a lack of
resources, increase the value of the
maxusers
attribute.
A
lack of resources may be indicated by a
No more processes
or
Out of processes
message.
However, increasing the
value of the
maxusers
attribute will increase the amount of
wired memory consumed by the kernel.
To determine an appropriate value for the
maxusers
attribute, double the value until you notice a performance improvement.
You can also use the following guidelines:
| Configuration | Value of maxusers Attribute |
| 1 GB of memory | 512 |
| 2 GB of memory | 1024 |
| Internet, Web, proxy, firewall, or gateway server | 2048 |
It is recommended that you not increase the value of
the
maxusers
attribute to more than 2048.
If you increase the value of
maxusers,
you may
want to increase the value of the
max-vnodes
attribute proportionally (see
Section 5.5.1).
task-max
The
proc
subsystem attribute
task-max
specifies the maximum number of tasks that can run simultaneously.
The default value is 20 + 8 *
maxusers.
thread-max
The
proc
subsystem
attribute
thread-max
specifies the maximum number of
threads that can run simultaneously.
The default value is 2 *
task-max.
The
proc
subsystem attribute
max-proc-per-user
specifies the maximum
number of processes that can be allocated at any one time to each user,
except superuser.
The default value of the
max-proc-per-user
attribute is 64.
If your system experiences a lack of processes,
you can increase the value of the
max-proc-per-user
attribute.
The value must be more than the maximum number of processes
that will be started by your system.
If you have a Web server, these
processes include CGI processes.
If you have an Internet, Web, proxy, firewall, or gateway server,
increase the value of the
max-proc-per-user
attribute to 512.
The
proc
subsystem attribute
max-threads-per-user
specifies the maximum
number of threads that can be allocated at any one time to each user,
except superuser.
The default value is 256.
If your system experiences a lack of threads,
you can increase the
max-threads-per-user
attribute to a value that is greater than the maximum number of threads
started by your system.
For example, you could increase the
value of the
max-threads-per-user
attribute to 512.
On a very busy server with sufficient memory or an Internet, Web,
proxy, firewall, or gateway server, increase the value of the
max-threads-per-user
attribute to 4096.
Setting the value of the
max-threads-per-user
attribute to 0 (zero) will remove the limit on threads.
See Section 4.4 for information about modifying kernel subsystem attributes.
If you are
running a very large application, you may need to increase the values
of the
proc
subsystem attributes
that control program size limits.
Some extremely
large programs may not run unless you modify the default values of the
following attributes:
per-proc-stack-size
and
max-per-proc-stack-size
These
proc
subsystem
attributes control the default and the maximum sizes of a user process stack.
The default value of the
per-proc-stack-size
attribute
is 2097152 bytes.
The default value of the
max-per-proc-stack-size
attribute is 33554432 bytes.
You may need to increase these values if you receive
Cannot grow
stack
messages.
per-proc-data-size
and
max-per-proc-data-size
These
proc
subsystem attributes control the
default and the maximum sizes of a user process data segment.
The default value of the
per-proc-data-size
attribute is
134217728 bytes.
The default value of the
max-per-proc-data-size
is 1 GB.
You may need to increase the value of the
max-per-proc-data-size
attribute if you receive an
Out of process memory
message.
If you have an Internet, Web, proxy, firewall, or gateway server,
increase the value of the
max-per-proc-data-size
attribute to 10 GB (10737418240 bytes).
See Section 4.4 for information about modifying kernel subsystem attributes.
If your configuration has a large amount of memory or you are running a large program, you may need to increase the limits on virtual address space and other resources.
Table 5-1 describes the recommendations for increasing the virtual memory limits for processes and lists the performance benefits as well as tradeoffs.
| Recommendation | Performance Benefit | Tradeoff |
| Increase the available address space (Section 5.3.1) | Improves performance for memory-intensive processes | Consumes a small amount of memory |
| Increase the maximum number of memory-mapped files that are available to a process (Section 5.3.2) | Increases file mapping and improves performance for memory-intensive processes, such as Internet servers | Consumes memory |
| Increase the maximum number of virtual pages within a process's address space that can have individual protection attributes (Section 5.3.3) | Improves performance for memory-intensive processes and for Internet servers that maintain large tables or resident images | None |
The following sections describe the recommendations for increasing the virtual memory limits for processes.
If your applications are memory-intensive, you may need to increase the address space limits. Increasing the address space limits will cause only a small increase in the demand for memory. You may not want to increase the address space if your applications use many forked processes.
The following attributes determine the available address space for processes:
This
vm
subsystem
attribute specifies the maximum amount of
valid virtual address space for a process (that is, the sum of all the valid
pages).
The default is 128000 pages (1 GB).
If you have an Internet, Web, proxy, firewall, or gateway server,
increase the value of the
vm-maxvas
attribute to
10737418240 (10 GB).
per-proc-address-space
and
max-per-proc-address-space
These
proc
subsystem attributes control the maximum
amount of user process address
space, which is the maximum number of valid virtual regions.
The default value for both attributes is 1 GB.
If you have an Internet, Web, proxy, firewall, or gateway server, increase
the value of the
max-per-proc-address-space
attribute
to 10 GB (10737418240 bytes).
See Section 4.4 for information about modifying kernel attributes.
You may want to increase the maximum number of memory-mapped files in a
user address.
Each map entry describes one unique disjoint portion
of a virtual address space.
The
vm
subsystem attribute
vm-mapentries
specifies the maximum
number of memory-mapped files in a user address.
The default value is 200.
Increasing the value of the
vm-mapentries
attribute will increase the demand for memory.
You may want to increase the value of the
vm-mapentries
attribute for large-memory systems and Internet servers to increase the
limit on file mapping.
Because Web servers map files into
memory, increase the value of the
vm-mapentries
attribute
to 20000 on busy systems running multithreaded Web server
software and on Internet, proxy, firewall, and gateway servers.
See Section 4.4 for information about modifying kernel subsystem attributes.
The
vm
subsystem
attribute
vm-vpagemax
specifies the maximum
number of virtual pages that
can be given individual protection attributes
within the address space of a process.
These protection attributes
differ from the protection attributes associated
with the other pages in the address space.
Changing the protection attributes of a single page within a virtual memory region causes all pages within that region to be treated as though they had individual protection attributes. For example, each thread of a multithreaded task has a user stack in the stack region for the process in which it runs. Because multithreaded tasks have guard pages (that is, pages that do not have read/write access) inserted between the user stacks for the threads, all pages in the stack region for the process are treated as though they have individual protection attributes.
If you have a large-memory system or if a stack region for a
multithreaded task
exceeds 16 KB pages, you may need to increase the value of the
vm-vpagemax
attribute.
The default value is 16384.
You can determine an appropriate value for the
vm-vpagemax
attribute by dividing the value
of the
vm
subsystem attribute
vm-maxvas
(the address
space size in bytes) by 8192.
For example, if the value
of the
vm-maxvas
attribute is 1 GB (the default), set
the value of
vm-vpagemax
to 131072 pages
(1073741824/8192=131072).
A value of 131072 pages may improve the
efficiency of Internet
servers that maintain large tables or resident images.
See Section 4.4 for information about modifying kernel subsystem attributes.
Interprocess communication (IPC) is the exchange of information between two or more processes. Some examples of IPC include messages, shared memory, semaphores, pipes, signals, process tracing, and processes communicating with other processes over a network. IPC is a functional interrelationship of several operating system subsystems. Elements are found in scheduling and networking.
The Tru64 UNIX operating system provides the following facilities for interprocess communication:
Pipes--See the Guide to Realtime Programming for information about pipes.
Signals--See the Guide to Realtime Programming for information about signals.
Sockets--See the Network Programmer's Guide for information about sockets.
Streams--See the Programmer's Guide: STREAMS for information about streams.
X/Open Transport Interface (XTI)--See the Network Programmer's Guide for information about XTI.
You
can track the use of IPC facilities with the
ipcs -a
command (see
ipcs(1)).
By looking at the current number
of bytes and message headers in the queues, you can then determine whether
you need to tune the System V message queue to diminish waiting.
Table 5-2 describes the recommendations for increasing IPC limits and lists the performance benefits as well as tradeoffs.
| Recommendation | Performance Benefit | Tradeoff |
| Increase the maximum size of a System V message (Section 5.4.1) | Enables memory-intensive or VLM systems to run efficiently | Consumes a small amount of memory |
| Increase the maximum number of bytes on a System V message queue (Section 5.4.2) | Prevents a process from sleeping if the queue is too full to accommodate a message | None |
| Increase the maximum number of messages on a System V queue (Section 5.4.3) | Enables memory-intensive or VLM systems to run efficiently | Consumes a small amount of memory |
| Increase the maximum size of a System V shared memory region (Section 5.4.4) | Enables memory-intensive or VLM systems to run efficiently | Consumes memory |
| Increase the minimum size of a System V shared memory segment (Section 5.4.5) | Enables memory-intensive or VLM systems to run efficiently | Consumes memory |
The following sections describe how to tune some System V attributes.
See
sys_attrs_ipc(5)
for information about additional IPC subsystem
attributes.
If your applications are memory-intensive or you have a large-memory system, you may want to increase the maximum size of a single System V message.
The
ipc
subsystem attribute
msg-max
specifies the maximum size of a single System V message.
The default value is 8192 bytes (1 page).
Increasing the
value of this attribute will slightly increase the demand for memory.
See Section 4.4 for information about modifying kernel subsystem attributes.
A process will be unable to
send a message to a queue if it will
make the number of bytes in the queue greater than the limit
specified by the
ipc
subsystem attribute
msg-mnb.
When the limit is
reached, the process sleeps and waits for this condition to be resolved.
To prevent a process from sleeping if the queue is too full to
accommodate a message, increase the value of the
msg-mnb
attribute.
The default value is 16384 bytes.
See Section 4.4 for information about modifying kernel subsystem attributes.
If your applications are memory-intensive or you have a large-memory system, you may want to increase the the maximum number of messages that can be queued to a single System V message queue at one time.
The
ipc
subsystem attribute
msg-tql
specifies the maximum number of messages that can be on a System V message
queue.
The default value is 40.
Increasing the value of this
attribute will increase the demand for memory.
See Section 4.4 for information about modifying kernel subsystem attributes.
If your applications are memory-intensive or you have a large-memory system, you may want to increase the maximum size of a single System V shared memory region.
The
ipc
subsystem attribute
shm-max
specifies the maximum size of a single System V shared memory region.
The default value is 4194304 bytes (512 pages).
Increasing the value of this attribute will increase the demand for memory.
In addition, the third-level page table is shared among
processes when the shared memory region size is equal to or greater than
the shared memory segment threshold, as specified by the value of the
ipc
subsystem attribute
ssm-threshold
(the default value is 8 MB).
When this occurs, shared memory becomes
segmented shared memory.
You can set the value of the
ssm-threshold
attribute to 0 (zero) to
disable the use of segmented shared memory.
See
Section 5.4.5
for more information.
In
addition, you may want to increase the
value of the
ipc
subsystem attribute
shm-seg.
This attribute
specifies the maximum number of System V shared memory regions that
can be attached to a single process at any point in time.
The default value is 32.
Increasing the value of this attribute
will increase the demand for memory.
As a design consideration, consider whether you will get better performance by using threads instead of shared memory.
See Section 4.4 for information about modifying kernel subsystem attributes.
Page table sharing occurs
when the size of a System V shared memory segment reaches the value
specified by the
ipc
subsystem attribute
ssm-threshold.
The default value
is 8 MB (8388608 bytes).
If your applications are memory-intensive, you
may want to increase the value of this attribute.
Increasing the value of the
ssm-threshold
attribute
will increase the demand for memory.
Setting the
ssm-threshold
attribute to 0 (zero) will
disable the use of segmented shared memory.
See Section 4.4 for information about modifying kernel subsystem attributes.
The following sections describe how to increase the maximum number of open files (Section 5.5.1) and the maximum number of open file descriptors (Section 5.5.2).
The kernel data structure for an open file is called a vnode. These are used by all file systems. The allocation and deallocation of vnodes is handled dynamically by the operating system. The number of vnodes determines the number of open files.
If your applications require many open files and you receive a message
indicating you are out of vnodes, increase the value of the
vfs
subsystem attribute
max-vnodes
or the
proc
subsystem
attribute
maxusers
to increase the maximum number of vnodes
and open files.
However, increasing the maximum number of vnodes will
increase the memory demand.
The default value of the
max-vnodes
attribute is 5
percent of memory.
See
Section 5.1
for information
about the
maxusers
attribute.
See Section 4.4 for information about modifying kernel subsystem attributes.
You can increase the maximum number of open file descriptors for all processes or for a specific application.
The
proc
subsystem attributes
open-max-soft
and
open-max-hard
control the
maximum system-wide number of open file descriptors (open files) for each
process.
These attributes prevent runaway
allocations, such as allocations within a loop that cannot be exited because
of an error condition, from consuming all of the available file descriptors.
If a process reaches the
open-max-soft
limit,
a warning message is issued.
If a process reaches the
open-max-hard
limit, the process is stopped.
The default value of the
open-max-soft
and
open-max-hard
attributes is 4096, which is the maximum system-wide
value that you can set in the
/etc/sysconfigtab
file.
If you have an application that requires many open files, you can increase the open file descriptor limit only for that application, instead of increasing the system-wide limit. To enable extended (64 KB) file descriptors for a specific application, follow these steps:
Set the
setsysinfo
system call's
SSI_FD_NEWMAX
operation parameter to 1, which sets the
utask
bit,
enables up to 65,536 (64 KB) open file descriptors, and raises the process's
hard file limit to 64 KB.
This setting is inherited by any child
process.
See
setsysinfo(2)
for more information.
Set the process's file descriptor soft limit to a value that
is more than 4096 (the default value) by using the
setrlimit
function as shown in the following code fragment:
#include <sys/resource.h>
struct rlimit *rlp;
rlp->rlim_cur = 6000;
rlp->rlim_max = 6000;
setrlimit(RLIMIT_NOFILE, rlp);
This setting is inherited by any child process.
See
setrlimit(2)
for more information.
This step is required only for applications that use the
select
function's
fd_set
parameter, which points
to an I/O descriptor set, and a
FD_CLR,
FD_ISSET,
FD_SET, or
FD_ZERO
macro and can modify an I/O descriptor set.
If you meet these qualifications,
you can use one of two procedures, one that enables a static definition
of the maximum number of file descriptors or one that enables a dynamic definition:
Static definition:
Override the default value of 4096 for
FD_SETSIZE
in the <sys/select.h>
header file by specifying the maximum value of 65536.
You must specify this
value before you include the <sys/time.h>
header file (which also includes
the <sys/select.h>
header file) in the code, as follows:
#define FD_SETSIZE 65536
#include <sys/time.h>
This setting is not inherited by child processes; therefore,
FD_SETSIZE
must
be set explicitly in the code for each child process that
requires 64 KB file descriptors.
Dynamic definition:
Instead of using statically-defined
fd_set
structures, you can use
fd_set
pointers in conjunction
with a
malloc
function, which provides forward compatibility
with any future changes to the maximum file descriptor limit.
For example:
fd_set *fdp;
fdp = (fd_set *) malloc(
(fds_howmany(max_fds,FD_NFDBITS))*sizeof(fd_mask));
The value for
max_fds
is the number of
file descriptors to be manipulated.
It is recommended that you use the file
descriptor soft limit for this value.
All other keywords are defined in
the <sys/select.h>
header file.
The following code segment shows this
choice:
#include <sys/time.h>
#include <sys/resource.h>
my_program()
{
fd_set *fdp;
struct rlimit rlim;
int max_fds;
getrlimit(RLIMIT_NOFILE, &rlim;);
max_fds = rlim.rlim_cur;
fdp = (fd_set *) malloc(
(fds_howmany(max_fds,FD_NFDBITS))*sizeof(fd_mask));
FD_SET(2, fdp);
for (;;) {
switch(select(max_fds, (fd_set *)0, fdp, (fd_set
*)0,
struct timeval *)0)) {
...
}
In addition, the
vfs
subsystem
attribute
max-vnodes
must be set high enough for the needs
of any application that requires a high number of descriptors.
The
max-vnodes
attribute specifies the number of vnodes (open files), and is set to 5 percent of system memory by default.
The
recommended setting is 1 vnode for each file descriptor.
See
Section 5.5.1
for more information.
See Section 4.4 for information about modifying kernel subsystem attributes.
To disable support for up to 64 KB file descriptors for an application,
set the
setsysinfo
system call's
SSI_FD_NEWMAX
operation
parameter to 0, which disables the
utask
bit and returns
the hard file limit to the default maximum of 4096 open file descriptors.
However, if the process is using more than 4096 file descriptors, the
setsysinfo
system call will return an
EINVAL
error.
In addition,
if a calling process's hard or soft limit exceeds 4096, the limit is set
to 4 KB after the call is successful.
This setting is inherited by any child
process.