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:

  1. A page is marked as unused.

  2. 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:

• Enough pages have been found to satisfy the memory shortfall.

• The planned number of pages have been looked at.

• Too much time has elapsed.

If a memory shortfall is still present when pageout finishes its scan, another scan is scheduled for 1/4 second in the future.

The configuration mechanism of the paging subsystem has changed in the Solaris 9 release. Instead of depending on a set of predefined values for fastscan, slowscan, and handspreadpages, the system determines the appropriate settings for these parameters at boot time. Setting any of these variables in the /etc/system file can cause the system to use less than optimal values.

---

Caution - We recommend that all tuning of the VM system be removed from /etc/system. Run with the default settings and determine if it is necessary to adjust any of these parameters. Do not set either cachefree or priority_paging. They have been removed from the Solaris 9 release.

---

Beginning in the Solaris 7 5/99 release, dynamic reconfiguration (DR) for CPU and memory is supported. The behavior of the system in a DR operation involving the addition or deletion of memory is to recalculate values for the relevant parameters unless the parameter has been explicitly set in /etc/system. In that case, the value specified in /etc/system is used unless a constraint on the value of the variable has been violated, in which case the value is reset.