reserved_procs
| Description | Specifies number of
system process slots to be reserved in the process table for processes with
a UID of root (0). For example, fsflush.
| | Data Type | Signed integer
| | Default | 5
| | Range | 5 to MAXINT
| | Units | Processes
| | Dynamic? | No. Not used after the
initial parameter computation.
| | Validation | In the Solaris 8 or 9
release, any /etc/system setting is honored.
| | Commitment Level | Unstable
| | When to Change | Consider increasing
to 10 + normal number of UID 0 (root) processes on system. This setting provides
some cushion should it be necessary to obtain a root shell during a time when
the system is otherwise unable to create user-level processes.
|
pidmax
| Description | This parameter specifies
value of largest possible process ID. Valid for Solaris 8 and later releases.
pidmax sets the value for the maxpid
variable. Once maxpid is set, pidmax
is ignored. maxpid is used elsewhere in the kernel to determine
the maximum process ID and for constraint checking.
Attempts to set maxpid by adding an entry to the /etc/system file have no effect.
| | Data Type | Signed integer
| | Default | 30,000
| | Range | 266 to 999,999
| | Units | Processes
| | Dynamic? | No. Used only at boot time
to set the value of pidmax.
| | Validation | Value is compared to
that of reserved_procs and 999,999. If less than reserved_procs or greater than 999,999, the value is set to 999,999.
| | Implicit | max_nprocs
range checking ensures that max_nprocs is always less than
or equal to this value.
| | When to Change | Changing this parameter
is one of the steps necessary to enable support for more than 30,000 processes
on a system.
| | Commitment Level | Unstable
|
max_nprocs
| Description | Maximum number of processes
that can be created on a system. Includes system and user processes. Any value
entered in /etc/system is used in the computation of maxuprc.
This value is also used in determining the size of several other system
data structures. Other data structures where this variable plays a role are:
Determining the size of the directory name lookup cache (if ncsize is not specified).
Allocating disk quota structures for UFS (if ndquot is not specified).
Verifying that the amount of memory used by configured system
V semaphores does not exceed system limits.
Configuring Hardware Address Translation resources for the
sun4m and Intel platforms.
| | Data Type | Signed integer
| | Default | 10 + (16 x maxusers)
| | Range | 266 to value of maxpid
| | Dynamic? | No
| | Validation | Compared to maxpid and set to maxpid if larger. On Intel
platforms an additional check is made against a platform-specific value. max_nprocs is set to the smallest value in the triplet (max_nprocs, maxpid, platform value). Both platforms
use 65,534 as the platform value.
| | When to Change | Changing this parameter
is one of the steps necessary to enable support for more than 30,000 processes
on a system.
| | Commitment Level | Unstable
| | Change History | For information,
see max_nprocs (Pre-Solaris 8 Releases).
|
maxuprc
| Description | Maximum number of processes
that can be created on a system by any one user.
| | Data Type | Signed integer
| | Default | max_nprocs
- reserved_procs
| | Range | 1 to max_nprocs
- reserved_procs
| | Units | Processes
| | Dynamic? | No
| | Validation | Compared to max_nprocs - reserved_procs and set to the smaller
of the two.
| | When to Change | When you want to
specify a hard limit for the number of processes a user can create that is
less than the default value of however many processes the system can create.
Attempting to exceed this limit generates the following warning messages on
the console or in the messages file: out of per-user processes for uid N |
| | Commitment Level | Unstable
|
Paging-Related Tunables
The Solaris environment is a demand paged virtual memory system. As
the system runs, pages are brought into memory as needed. When memory becomes
occupied above a certain threshold and demand for memory continues, paging
begins. Paging goes through several levels that are controlled by certain
variables.
The general paging algorithm is as follows:
A memory deficit is noticed. The page scanner thread runs
and begins to walk through memory. A two-step algorithm is employed:
A page is marked as unused.
If still unused after a time interval, the page is viewed
as a subject for reclaim.
If the page has been modified, a request is made to the pageout thread
to schedule the page for I/O and the scanner continues looking at memory.
Pageout causes the page to be written to the page's backing store and placed
on the free list. When scanning memory, no distinction is made as to the origin
of the page. It may have come from a data file, or it might represent a page
from an executable's text, data, or stack.
As memory pressure on the system increases, the algorithm
becomes more aggressive in the pages it will consider as candidates for reclamation
and in how frequently the paging algorithm runs. (For more information, see fastscan and slowscan.) As available memory
falls between the range lotsfree and minfree,
the system will linearly increase the amount of memory scanned in each invocation
of the pageout thread from the value specified by slowscan
to the value specified by fastscan. The system uses the desfree variable to control a number of decisions about resource
usage and behavior.
The system initially constrains itself to use no more than 4% of one
CPU for pageout operations. As memory pressure increases,
the amount of CPU time consumed in support of pageout operations
linearly increases until a maximum of 80% of one CPU is consumed. The algorithm
is to look through some amount of memory between slowscan
and fastscan, and stops when one of the following occurs:
|
Previous