Solaris Resource Manager 1.3 System Administration Guide

Chapter 7 Memory Limits, Process Memory Limits, and Process Count Limits

Solaris Resource Manager allows an administrator to control:

Attributes for Control of Virtual Memory (Total)

The system attributes used to record virtual memory usage and assign limits to it are:

memory.myusage

The memory.myusage attribute of an lnode is equal to the sum of the virtual memory usage of all processes currently attached to the lnode.

memory.usage

The memory.usage attribute of an lnode is equal to the sum of its memory.myusage attribute and the memory.usage attributes of its child lnodes.

memory.limit

The memory.limit attribute is applied to the memory.usage attribute; it limits the combined memory usage of all processes attached to the lnode and all member lnodes.

Attribute for Control of Process Memory (Per-Process)

The system attribute used to record process usage and assign limits to it is:

memory.plimit

The memory.plimit attribute of an lnode is a per-process limit that is applied separately to the memory usage of each process attached to it or to any of its members.

Technical Description of Memory Limits

Whenever a process attempts to increase its memory size, it is subject to the memory limits (total and per-process) of the lnode to which it is attached. There are five means by which a process can attempt to increase its memory size:

  1. Calling an allocation routine, such as malloc(3C), which results in an invocation of the sbrk(2) system call. If a memory limit is exceeded, the call will return an error with errno set to ENOMEM.

  2. Expanding the stack and causing a stack fault, which would normally cause an extra page of memory to be given to the process. If a memory limit is exceeded, the process will be sent a SIGSEGV signal.

  3. Using mmap(2).

  4. Using fork(2). The child address space is duplicated while it is still owned by the parent process. During duplication, the new address space will not exceed the memory.plimit since the parent must already be within this limit; however, the allocation is subject to the memory.limit.

  5. Using exec(2). During an exec, memory usage first decreases as the old address space is discarded. However, if the address space of the new program is larger, and causes a limit to be exceeded, the exec can fail.

Dynamic Reconfiguration and Virtual Memory Limits

The dynamic reconfiguration (DR) feature available on the Enterprise 10000, Sun Fire 15K, and Sun Fire 12K systems has limited impact on the virtual memory limits imposed on lnodes. Specifically, DR makes it possible to add or remove physical memory from the system while the system is up and running. (The system's pool of virtual memory includes all of the physical memory, plus the swap space configured into the system.) Additionally, the swap(1M) command can be used on any Solaris system to add (-a) or delete (-d) swap space from the system. Thus, the total amount of virtual memory can grow or shrink during operation.

This has an indirect impact on the virtual memory limits imposed by Solaris Resource Manager. Because virtual memory is managed in absolute units (rather than shares), the effective limits do not change when the system's resources change during operation. (Note that this behavior is different from the dynamic reconfiguration of processors, as discussed in Dynamic Reconfiguration.)

Attributes for Control of Process Count

The system attributes used to administer process usage (the number of processes) are:

process.myusage

The process.myusage attribute of an lnode is equal to the number of processes attached to the lnode.

process.usage

The process.usage attribute of an lnode is equal to the sum of its process.myusage attribute and the process.usage attributes of its child lnodes.

process.limit

The process.limit attribute is a limit that applies to the process.usage attribute of an lnode; it limits the number of processes that can be attached to the lnode and all member lnodes concurrently.

Technical Description of Process Count

The fork(2) and vfork(2) system calls are used to create new processes. If this would cause the process limit to be exceeded, the system call fails, returning an EAGAIN error. Most programs interpret EAGAIN as meaning a temporary shortage of system resources and try the fork again, perhaps after a short sleep. If the fork failure is due to a Solaris Resource Manager limit, this can lead to looping for an indefinite amount of time because EAGAIN will be returned on each retry until the limit is fixed for the affected lnode.