Contidos dentro
Localizar Mais Documentação
Destaques de Recursos de Suporte
| Fazer download desta apostila em PDF (772 KB)
Chapter 2 Solaris Kernel Tunables
This section describes most of the Solaris kernel tunables.
For information on NFS tunables, see Chapter 4, TCP/IP Tunable Parameters. For information
on TCP/IP tunables, see Chapter 3, NFS Tunable Parameters.
General Parameters
This section describes general kernel parameters relating to physical
memory and stack size.
physmem
- Description
-
Modifies the system's
idea of the number of physical pages of memory after the OS and firmware are
accounted for.
- Data Type
-
Unsigned long
- Default
-
Number of usable pages of
physical memory available on the system—not counting the memory where
the core kernel and data are stored.
- Range
-
1 to amount of physical memory
on system
- Units
-
Pages
- Dynamic?
-
No
- Validation
-
None
- When to Change
-
Whenever you want
to test the effect of running with less physical memory. Note that because
this parameter does not take into account the memory
used by the core kernel and data as well as various other data structures
allocated early in the startup process, the value of physmem
should be less than the actual number of pages that represent the smaller
amount of memory.
- Commitment Level
-
Unstable
lwp_default_stksize
- Description
-
Default value of size
of stack to be used when a kernel thread is created, and the calling routine
does not provide an explicit size to be used.
- Data Type
-
Integer
- Default
-
8192 for all 32-bit SPARC
and IA based platforms
16,384 for 64-bit sun4u platforms
- Range
-
0 to 262,144
- Units
-
Bytes in multiples of the
value returned by getpagesize(3C).
- Dynamic?
-
Yes. Affects threads created
after the variable is changed.
- Validation
-
Must be greater than
or equal to 8192 and less than or equal to 262,144 (256 x 1024) and must be
a multiple of the system page size. If these conditions are not met, the following
message is displayed:
Illegal stack size, Using N
|
The value of N is the default described above.
- When to Change
-
When the system panics
because it has run out of stack space. The best solution for this problem
is to determine why the system is running out of space and make a correction.
Increasing the default stack size means that almost every kernel thread will
have a larger stack, resulting in increased kernel memory consumption for
no good reason, because that space will generally be unused. The increased
consumption means that other resources competing for the same pool of memory
will have the amount of space available to them reduced, possibly decreasing
the system's ability to perform work. Among the side effects will be a reduction
in the number of threads which the kernel can create. This solution should
be treated as no more than an interim workaround until the root cause is remedied.
- Commitment Level
-
Unstable
logevent_max_q_sz
- Description
-
Maximum number of system
events allowed to be queued waiting for delivery to the syseventd daemon. Once the size of the system event queue reaches this limit,
no other system events will be allowed on the queue.
- Data Type
-
Integer
- Default
-
2000
- Range
-
0 to MAXINT
- Units
-
System events
- Dynamic?
-
Yes
- Validation
-
The sysevent framework
checks this value every time a system event is generated via ddi_log_sysevent(9)
and sysevent_post_event(3).
- When to Change
-
When error log messages
indicate that a system event failed to be logged, generated, or posted.
- Commitment Level
-
Unstable
- Changes From Previous Release
-
See logevent_max_q_sz for more information.
fsflush and Related Tunables
This section describes fsflush and related tunables.
fsflush
The system daemon, fsflush, runs periodically to
do three main tasks:
Frequency of invocation, whether the memory scanning is executed, whether
the file system data flushing occurs, and the frequency with which it will
occur are configurable.
For most systems, memory scanning and file system metadata syncing are
the dominant activities for fsflush. Depending on system
usage, memory scanning can be of little use or consume too much CPU time.
tune_t_fsflushr
- Description
-
Specifies the number
of seconds between fsflush invocations.
- Data Type
-
Signed integer
- Default
-
5
- Range
-
1 to MAXINT
- Units
-
Seconds
- Dynamic?
-
No
- Validation
-
If the value is less
than or equal to zero, the value is reset to 5 and a warning message is displayed.
This check is only done at boot time.
- When to Change
-
See autoup below.
- Commitment Level
-
Unstable
autoup
- Description
-
Along with tune_t_flushr, autoup controls the amount of
memory examined for dirty pages in each invocation and frequency of file system
sync operations.
The value of autoup is also used to control whether
a buffer is written out from the free list. Buffers marked with the B_DELWRI flag (file content pages that have changed) are written
out whenever the buffer has been on the list for longer than autoup seconds. Increasing the value of autoup
keeps the buffers around for a longer time in memory.
- Data Type
-
Signed integer
- Default
-
30
- Range
-
1 to MAXINT
- Units
-
Seconds
- Dynamic?
-
No
- Validation
-
If autoup
is less than or equal to zero, it is reset to 30 and a warning message is
displayed. This check is only done at boot time.
- Implicit
-
autoup
should be an integer multiple of tune_t_fsflushr. At a
minimum, autoup should be at least 6 times tune_t_fsflushr. If not, excessive amounts of memory will be scanned each time fsflush is invoked.
(total system pages x tune_t_fsflushr) should be
greater than or equal to autoup to cause memory to be checked
if dopageflush is non-zero.
- When to Change
-
There are several
potential situations for changing autoup and or tune_t_fsflushr:
-
Systems with large amounts of memory—In this case, increasing autoup reduces the amount of memory scanned in each invocation
of fsflush.
-
Systems with minimal memory demand—Increasing both autoup
and tune_t_fsflushr reduces the number of scans made. autoup should be increased also to maintain the current ratio of autoup / tune_t_fsflushr.
-
Systems with large numbers of transient files (for example,
mail servers or software build machines)—If large numbers of files are
created and then deleted, fsflush might unnecessarily write
data pages for those files to disk.
- Commitment Level
-
Unstable
dopageflush
- Description
-
Controls whether memory
is examined for modified pages during fsflush invocations.
In each invocation of fsflush, the number of memory pages
in the system is determined (it might have changed because of a dynamic reconfiguration
operation). Each invocation scans (total number of pages x tune_t_fsflushr) / autoup pages.
- Data Type
-
Signed integer
- Default
-
1 (enabled)
- Range
-
0 (disabled) or 1 (enabled)
- Units
-
Toggle (on/off)
- Dynamic?
-
Yes
- Validation
-
None
- When to Change
-
If the system page
scanner rarely runs, indicated by a value of 0 in the sr
column of vmstat output.
- Commitment Level
-
Unstable
doiflush
- Description
-
Controls whether file
system metadata syncs will be executed during fsflush invocations.
Syncs are done every Nth invocation of fsflush where N= (autoup / tune_t_fsflushr). Because this is an integer division, if tune_t_fsflushr is greater than autoup, a sync will be done
on every invocation of fsflush because the code checks
to see if its iteration counter is greater than or equal to N. Note that N is computed once on
invocation of fsflush. Later changes to tune_t_fsflushr or autoup will have no effect on the frequency
of sync operations.
- Data Type
-
Signed integer
- Default
-
1 (enabled)
- Range
-
0 (disabled) or 1 (enabled)
- Units
-
Toggle (on/off)
- Dynamic?
-
Yes
- Validation
-
None
- When to Change
-
When files are frequently
modified over a period of time and the load caused by the flushing perturbs
system behavior. Files whose existence, and therefore consistency of state
does not matter if the system reboots, are better kept in a TMPFS file system
(for example, /tmp). Inode traffic can be reduced on
systems running the Solaris 7 and 8 releases by using the mount -noatime option. This option eliminates inode updates when the file
is accessed.
A system engaged in realtime processing might want to disable this option
and use explicit application file syncing to achieve consistency.
- Commitment Level
-
Unstable
Process Sizing Tunables
Several variables are used to control the number of processes that are
available on the system and the number of processes that an individual user
can create. The foundation variable is maxusers, which
drives the values assigned to max_nprocs and maxuprc.
maxusers
- Description
-
Originally, maxusers defined the number of logged in users the system could
support. Various tables were sized based on this setting when a kernel was
generated. Now, the Solaris release does much of its sizing based on the amount
of memory on the system, so much of the past use of maxusers
has changed. There are still a number of subsystems that are derived from maxusers:
-
The maximum number of processes on the system
-
The number of quota structures held in the system
-
The size of the directory name lookup cache (DNLC)
- Data Type
-
Signed integer
- Default
-
Lesser of the amount of
memory in Mbytes and 2048
- Range
-
1 to 2048, based on physical
memory if not set in the /etc/system file.
1 to 4096, if set in the /etc/system file.
- Units
-
Users
- Dynamic?
-
No. After computation of
dependent variables is done, maxusers is never referenced
again.
- Validation
-
None
- When to Change
-
When the default
number of user processes derived by the system is too low. This situation
is seen by the following message that displays on the system console:
When the default number of processes is too high:
-
Database servers that have a lot of memory and relatively
few running processes, can save system memory by reducing the default value
of maxusers.
-
File servers that have a lot of memory and few running processes
can reduce this value, but should explicitly set the size of the DNLC. (See ncsize.)
-
Compute servers that have a lot of memory and few running
processes can reduce this value.
- Commitment Level
-
Unstable
- Change History
-
See maxusers (Solaris 7 Release)
for more information.
- Changes From Previous Release
-
See maxusers for more information.
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 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
-
See max_nprocs (Pre-Solaris 8 Releases)
for more information.
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. (See fastscan
and slowscan for more information.) 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 also attempts to constrain itself to use not more than 4%
of one CPU for pageout operations. The algorithm is to look through some amount
of memory between slowscan and fastscan,
and stop 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.
 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
enable priority_paging or adjust cachefree.
These are no longer needed, although still present in the kernel. Manipulating
them will almost certainly result in performance degradation when the page
scanner runs.
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.
lotsfree
- Description
-
Initial trigger for
system paging to begin. When this threshold is crossed, the page scanner wakes
up to begin looking for memory pages to reclaim.
- Data Type
-
Unsigned long
- Default
-
The greater of 1/64th of
physical memory or 512 Kbytes
- Range
-
The minimum value is 512 Kbytes
or 1/64th of physical memory, whichever is greater, expressed as pages using
the page size returned by getpagesize(3C).
The maximum is the number of physical memory pages. The maximum value
should be no more than 30% of physical memory. The system does no enforcement
of this range other than that described in the Validation section.
- Units
-
Pages
- Dynamic?
-
Yes, but dynamic changes
are lost if a memory based DR operation occurs.
- Validation
-
If lotsfree is greater than the amount of physical memory, the value is reset
to the default.
- Implicit
-
The relationship of cachefree is greater than or equal to lotsfree,
which is greater than desfree, which is greater than minfree, must be maintained at all times.
- When to Change
-
When demand for pages
is subject to sudden sharp spikes, the memory algorithm might not be able
to keep up with demand. One way to work around this problem is to start reclaiming
memory at an earlier time. This solution gives the paging system some additional
margin.
A rule of thumb is to set this parameter to 2 times what the system
needs to allocate in a few seconds. This parameter is workload dependent:
a DBMS server can probably work fine with the default settings, but a system
doing heavy file system I/O might need to adjust this parameter.
For systems with relatively static workloads and large amounts of memory,
adjust this value downwards. The minimum acceptable value is 512 Kbytes expressed
as pages using the page size returned by getpagesize(3C).
- Commitment Level
-
Unstable
desfree
- Description
-
Amount of memory desired
to be free at all times on the system.
- Data Type
-
Unsigned integer
- Default
-
lotsfree
/ 2
- Range
-
The minimum value is 256 Kbytes
or 1/128th of physical memory, whichever is greater, expressed as pages using
the page size returned by getpagesize(3C).
The maximum is the number of physical memory pages. The maximum value
should be no more than 15% of physical memory. The system does no enforcement
of this range other than that described in the Validation section.
- Units
-
Pages
- Dynamic?
-
Yes, unless dynamic reconfiguration
operations that add or delete memory occur. At that point, the value is reset
to whatever was provided in the /etc/system file or was
calculated from the new physical memory value.
- Validation
-
If desfree
is greater than lotsfree, desfree is
set to lotsfree / 2. No message is displayed.
- Implicit
-
The relationship of cachefree is greater than or equal to lotsfree,
which is greater than desfree, which is greater than minfree, should be maintained at all times.
- Side Effects
-
Several side effects
can arise from increasing the value of this variable. When the new value nears
or exceeds the amount of available memory on the system:
-
Asynchronous I/O requests are not processed unless available
memory exceeds desfree. Increasing the value of desfree can result in rejection of requests that otherwise would
succeed.
-
NFS Version 3 asynchronous writes are executed as synchronous
writes.
-
The swapper is awakened earlier, and the behavior of the swapper
is biased towards more aggressive actions.
-
The system might not prefault as many executable pages into
the system. This side effect results in applications potentially running slower
than they otherwise would.
- When to Change
-
For systems with
relatively static workloads and large amounts of memory, adjust this value
downwards. The minimum acceptable value is 256 Kbytes expressed as pages using
the page size returned by getpagesize(3C).
- Commitment Level
-
Unstable
minfree
- Description
-
Minimum acceptable memory
level. When memory drops below this number, the system biases allocations
toward those necessary to successfully complete pageout operations or to swap
processes completely out of memory, and either denies or blocks other allocation
requests.
- Data Type
-
Unsigned integer
- Default
-
desfree
/ 2
- Range
-
The minimum value is 128 kbytes
or 1/256th of physical memory, whichever is greater, expressed as pages using
the page size returned by getpagesize(3C).
The maximum is the number of physical memory pages. The maximum value
should be no more than 7.5% of physical memory. The system does no enforcement
of this range other than that described in the Validation section.
- Units
-
Pages
- Dynamic?
-
Yes, unless dynamic reconfiguration
operations that add or delete memory occur. At that point, the value is reset
to whatever was provided in the /etc/system file or was
calculated from the new physical memory value.
- Validation
-
If minfree
is greater than desfree, minfree is
set to desfree / 2. No message is displayed.
- Implicit
-
The relationship of cachefree is greater than or equal to lotsfree,
which is greater than desfree, which is greater than minfree should be maintained at all times.
- When to Change
-
The default value
is generally adequate. For systems with relatively static workloads and large
amounts of memory, adjust this value downwards. The minimum acceptable value
is 128 Kbytes expressed as pages using the page size returned by getpagesize(3C).
- Commitment Level
-
Unstable
throttlefree
- Description
-
Memory level at which
blocking memory allocation requests are put to sleep, even if the memory is
sufficient to satisfy the request.
- Data Type
-
Unsigned integer
- Default
-
minfree
- Range
-
The minimum value is 128 Kbytes
or 1/256th of physical memory, whichever is greater, expressed as pages using
the page size returned by getpagesize(3C).
The maximum is the number of physical memory pages. The maximum value
should be no more than 4% of physical memory. The system does no enforcement
of this range other than that described in the Validation section.
- Units
-
Pages
- Dynamic?
-
Yes, unless dynamic reconfiguration
operations that add or delete memory occur. At that point, the value is reset
to whatever was provided in the /etc/system file or was
calculated from the new physical memory value.
- Validation
-
If throttlefree is greater than desfree, throttlefree is set to minfree. No message is displayed.
- Implicit
-
The relationship of cachefree is greater than or equal to lotsfree,
which is greater than desfree, which is greater than minfree, should be maintained at all times.
- When to Change
-
The default value
is generally adequate. For systems with relatively static workloads and large
amounts of memory, adjust this value downwards. The minimum acceptable value
is 128 Kbytes expressed as pages using the page size returned by getpagesize(3C).
- Commitment Level
-
Unstable
pageout_reserve
- Description
-
Number of pages reserved
for the exclusive use of the pageout or scheduler threads. When available
memory is less than this value, non-blocking allocations are denied for any
processes other than pageout or the scheduler. Pageout needs to have a small
pool of memory for its use so it can allocate the data structures necessary
to do the I/O for writing a page to its backing store. This variable was introduced
in the Solaris 2.6 release to ensure that the system would be able to perform
a pageout operation in the face of the most severe memory shortage.
- Data Type
-
Unsigned integer
- Default
-
throttlefree
/ 2
- Range
-
The minimum value is 64 Kbytes
or 1/512th of physical memory, whichever is greater, expressed as pages using
the page size returned by getpagesize(3C).
The maximum is the number of physical memory pages. The maximum value
should be no more than 2% of physical memory. The system does no enforcement
of this range other than that described in the Validation section.
- Units
-
Pages
- Dynamic?
-
Yes, unless dynamic reconfiguration
operations that add or delete memory occur. At that point, the value is reset
to whatever was provided in the /etc/system
file or was calculated from the new physical memory value.
- Validation
-
If pageout_reserve is greater than throttlefree / 2, pageout_reserve is set to throttlefree / 2. No
message is displayed.
- Implicit
-
The relationship of cachefree is greater than or equal to lotsfree,
which is greater than desfree, which is greater than minfree, which is greater than or equal to throttlefree, should be maintained at all times.
- When to Change
-
The default value
is generally adequate. For systems with relatively static workloads and large
amounts of memory, adjust this value downwards. The minimum acceptable value
is 64 Kbytes expressed as pages using the page size returned by getpagesize(3C).
- Commitment Level
-
Unstable
cachefree
- Description
-
The Solaris 8 release
changes the way file system pages are cached. These changes subsume the priority
paging capability.
Note –
Remove both cachefree and priority_paging settings in the /etc/system
file.
The caching changes remove most of the pressure on the virtual memory
system resulting from file system activity. Several statistics exhibit new
behavior:
-
Page reclaims are higher because pages are now explicitly
added to the free list after I/O completes.
-
Free memory is now higher because the free memory count now
includes a large component of the file cache.
-
Scan rates are drastically reduced.
- Commitment Level
-
Obsolete
- Change History
-
See cachefree (Solaris 2.6 and Solaris 7 Releases)
for more information.
priority_paging
- Description
-
This variable sets cachefree to 2 times lotsfree.
The Solaris 8 release changes the way file system pages are cached.
These changes subsume the priority paging capability.
Note –
Remove both cachefree and priority_paging settings in the /etc/system
file.
- Commitment Level
-
Obsolete
- Change History
-
See priority_paging (Solaris 2.6 and 7 Releases)
for more information.
pages_pp_maximum
- Description
-
Defines the number of
pages that the system requires be unlocked. If a request to lock pages would
force available memory below this value, that request is refused.
- Data Type
-
Unsigned long
- Default
-
Maximum of the triplet (200, tune_t_minarmem + 100, [10% of memory available at boot time])
- Range
-
Default value to no more than
20% of physical memory. The systems does no enforcement of this range other
than that described in the Validation section.
- Units
-
Pages
- Dynamic?
-
Yes, unless dynamic reconfiguration
operations that add or delete memory occur. At that point, the value is reset
to whatever was provided in the /etc/system file or was
calculated.
- Validation
-
Maximum of the quadruplet
(200, tune_t_minarmem + 100, [10% of memory available],
and the value from /etc/system). No message is displayed
if the value from /etc/system
is increased. Done only at boot time.
- When to Change
-
When memory locking
requests or attaching to a shared memory segment with the SHARE_MMU flag fails, yet the amount of memory available seems to be sufficient.
Keeping 10% of memory free on a 32–Gbyte system might be excessive.
Excessively large values can cause memory locking requests to fail unnecessarily.
- Commitment Level
-
Unstable
tune_t_minarmem
- Description
-
The minimum available
resident (not swappable) memory to maintain in order to avoid deadlock. Used
to reserve a portion of memory for use by the core of the operating system.
Pages restricted in this way are not seen when the OS determines the maximum
amount of memory available.
- Data Type
-
Signed integer
- Default
-
25
- Range
-
1 to physical memory
- Units
-
Pages
- Dynamic?
-
No
- Validation
-
None. Large values result
in wasted physical memory.
- When to Change
-
The default value
is generally adequate. Consider increasing it if the system locks up and debugging
information indicates the problem was because no memory was available.
- Commitment Level
-
Unstable
fastscan
- Description
-
Maximum number of pages
per second that the system looks at when memory pressure is highest.
- Data Type
-
Signed integer
- Default
-
The lesser of 64 Mbytes
and 1/2 of physical memory.
- Range
-
1 to one-half of physical
memory
- Units
-
Pages
- Dynamic?
-
Yes, unless dynamic reconfiguration
operations that add or delete memory occur. At that point, the value is reset
to whatever was provided by /etc/system
or was calculated from the new physical memory value.
- Validation
-
Maximum value is the
lesser of 64 Mbytes and 1/2 of physical memory.
- When to Change
-
When more aggressive
scanning of memory is desired during periods of memory shortfall, especially
if the system is subject to periods of intense memory demand or when performing
heavy file I/O.
- Commitment Level
-
Unstable
slowscan
- Description
-
Minimum number of pages
per second that the system looks at when attempting to reclaim memory.
- Data Type
-
Signed integer
- Default
-
The smaller of 1/20th of
physical memory in pages and 100.
- Range
-
1 to fastscan
/ 2
- Units
-
Pages
- Dynamic?
-
Yes, unless dynamic reconfiguration
operations that add or delete memory occur. At that point, the value is reset
to whatever was provided in the /etc/system file or was
calculated from the new physical memory value.
- Validation
-
If slowscan is larger than fastscan / 2, slowscan is reset to fastscan / 2. No message is displayed.
- When to Change
-
When more aggressive
scanning of memory is desired during periods of memory shortfall especially
if the system is subject to periods of intense memory demand.
- Commitment Level
-
Unstable
min_percent_cpu
- Description
-
Minimum percentage of
CPU that pageout can consume. This variable is used as
the starting point for determining the maximum amount of time that can be
consumed by the page scanner.
- Data Type
-
Signed integer
- Default
-
4
- Range
-
1 to 80
- Units
-
Percentage
- Dynamic?
-
Yes
- Validation
-
None
- When to Change
-
Increasing this value
on systems with multiple CPUs and lots of memory, which are subject to intense
periods of memory demand, enables the pager to spend more time attempting
to find memory.
- Commitment Level
-
Unstable
handspreadpages
- Description
-
The Solaris environment
uses a two-handed clock algorithm to look for pages that are candidates for
reclaiming when memory is low. The first hand of the clock walks through memory
marking pages as unused. The second hand walks through memory some distance
after the first hand, checking to see if the page is still marked as unused.
If so, the page is subject to reclaim. The distance between the front hand
and the back hand is handspreadpages.
- Data Type
-
Unsigned long
- Default
-
fastscan
- Range
-
1 to maximum number of physical
memory pages on the system
- Units
-
Pages
- Dynamic?
-
Yes. This parameter requires
that the kernel variable reset_hands also be set to a non-zero
value. Once the new value of handspreadpages has been recognized, reset_hands is set to zero.
- Validation
-
Set to lesser of the
amount of physical memory and the handspreadpages value
- When to Change
-
When you want the
amount of time that pages are potentially resident before reclaim is increased.
Increasing this value increases the separation between the hands, and therefore,
the amount of time before a page can be reclaimed.
- Commitment Level
-
Unstable
pages_before_pager
- Description
-
Part of a system threshold
that immediately frees pages after an I/O completes instead of storing the
pages for possible reuse. The threshold is lotsfree + pages_before_pager. The NFS environment also uses this threshold to curtail its asynchronous
activities as memory pressure mounts.
- Data Type
-
Signed integer
- Default
-
200
- Range
-
1 to amount of physical memory
- Units
-
Pages
- Dynamic?
-
No
- Validation
-
None
- When to Change
-
When the majority
of I/O is done for pages that are truly read or written once and never referenced
again. Setting this variable to a larger amount of memory keeps adding pages
to the free list.
When the system is subject to bursts of severe memory pressure. A larger
value here helps to keep a bigger cushion against the pressure.
- Commitment Level
-
Unstable
maxpgio
- Description
-
Maximum number of page
I/O requests that can be queued by the paging system. This number is divided
by 4 to get the actual maximum used by the paging system. It is used to throttle
the number of requests as well as to control process swapping.
- Data Type
-
Signed integer
- Default
-
40
- Range
-
1 to 1024
- Units
-
I/0s
- Dynamic?
-
No
- Validation
-
None
- Implicit
-
The maximum number of I/O
requests from the pager is limited by the size of a list of request buffers,
which is currently sized at 256.
- When to Change
-
When the system is
subject to bursts of severe memory pressure. A larger value here helps to
recover faster from the pressure if more than one swap device is configured
or the swap device is a striped device.
- Commitment Level
-
Unstable
Swapping-Related Variables
Swapping in the Solaris environment is accomplished by the swapfs pseudo
file system. The combination of space on swap devices and physical memory
is treated as the pool of space available to support the system for maintaining
backing store for anonymous memory. The system attempts to allocate space
from disk devices first, and then uses physical memory as backing store. When
swapfs is forced to use system memory for backing store, limits are enforced
to ensure that the system does not deadlock because of excessive consumption
by swapfs.
swapfs_reserve
- Description
-
Amount of system memory
that is reserved for use by system (UID = 0) processes.
- Data Type
-
Unsigned long
- Default
-
The smaller of 4 Mbytes
and 1/16th of physical memory
- Range
-
The minimum value is 4 Mbytes
or 1/16th of physical memory, whichever is smaller, expressed as pages using
the page size returned by getpagesize(3C).
The maximum is the number of physical memory pages. The maximum value
should be no more than 10% of physical memory. The system does no enforcement
of this range other than that described in the Validation section.
- Units
-
Pages
- Dynamic?
-
No
- Validation
-
None
- When to Change
-
Generally not necessary.
Only change on recommendation of a software provider, or when system processes
are terminating because of an inability to obtain swap space. A much better
solution is to add physical memory or additional swap devices to the system.
- Commitment Level
-
Unstable
swapfs_minfree
- Description
-
Amount of physical memory
that is desired be kept free for the rest of the system. Attempts to reserve
memory for use as swap space by any process that causes the system's perception
of available memory to fall below this value are rejected. Pages reserved
in this manner can only be used for locked-down allocations by the kernel
or by user-level processes.
- Data Type
-
Unsigned long
- Default
-
The larger of 2 Mbytes and
1/8th of physical memory
- Range
-
1 to amount of physical memory
- Units
-
Pages
- Dynamic?
-
No
- Validation
-
None
- When to Change
-
When processes are
failing because of an inability to obtain swap space, yet the system has memory
available.
- Commitment Level
-
Unstable
General Kernel Variables
noexec_user_stack
- Description
-
Enables the stack to
be marked as non-executable. This helps in making buffer-overflow attacks
more difficult.
A Solaris system running a 64-bit kernel makes the stacks of all 64-bit
applications non-executable by default. Setting this variable is necessary
to make 32-bit applications non-executable on systems running 64-bit or 32-bit
kernels.
Note –
This variable exists on all systems running the Solaris 2.6, 7,
or 8 releases, but it is only effective on sun4u, sun4m, and sun4d architectures.
- Data Type
-
Signed integer
- Default
-
0 (disabled)
- Range
-
0 (disabled), 1 (enabled)
- Units
-
Toggle (on/off)
- Dynamic?
-
Yes. Does not affect currently
running processes—only those created after the value is set.
- Validation
-
None
- When to Change
-
Should be enabled
at all times unless applications are deliberately placing executable code
on the stack without using mprotect(2) to make the stack executable.
- Commitment Level
-
Unstable
- Change History
-
See noexec_user_stack (Solaris 2.6 and 7 Releases)
for more information.
Kernel Memory Allocator
The Solaris kernel memory allocator distributes chunks of memory for
use by entities inside the kernel. The allocator creates a number of caches
of varying size for use by its clients. Clients can also request the allocator
to create a cache for use by that client (for example, to allocate structures
of a particular size). Statistics about each of the caches that the allocator
manages can be seen with the kstat -c kmem_cache command.
Specialized caches can be viewed with the crash(1M) command, using the kmastat operator.
Occasionally, systems might panic because of memory corruption. The
kernel memory allocator supports a debugging interface that performs various
integrity checks on the buffers as well as collecting information on the allocators.
The integrity checks provide the opportunity to detect errors closer to where
they actually occurred, and the collected information provides additional
data for support people when they try to ascertain the reason for the panic.
Use of the flags incurs additional overhead and memory usage during
system operations. The flags should only be used when a memory corruption
problem is suspected.
kmem_flags
- Description
-
The Solaris kernel memory
allocator has various debugging and test options that were extensively used
during the internal development cycle of the Solaris environment. Prior to
the Solaris 2.5 release, these options were not usable in released Solaris
versions. Starting with the Solaris 2.5 release, a subset of these options
are available and they are controlled by the kmem_flags
variable, which was set by booting kadb, and then setting
the variable before starting the kernel. Because of issues with the timing
of the instantiation of the kernel memory allocator and the parsing of /etc/system, it was not possible to set these flags in the /etc/system file until the Solaris 8 release.
Five supported flag settings are described here.
Table 2–1 kmem_flags Settings
|
Flag
|
Setting
|
Description
|
|
AUDIT
|
0x1
|
The allocator maintains a log that
contains recent history of its activity. The number of items logged depends
on whether CONTENTS is also set. The log is a fixed size
and when space is exhausted, earlier records are reclaimed.
|
|
TEST
|
0x2
|
The allocator writes a pattern into
freed memory and checks that the pattern is unchanged when the buffer is next
allocated. If some portion of the buffer is changed, this indicates that the
memory was probably used by an entity that had previously allocated and freed
the buffer. If an overwrite is seen, the system panics.
|
|
REDZONE
|
0x4
|
The allocator provides extra memory
at the end of the requested buffer and inserts a special pattern into that
memory. When the buffer is freed, the pattern is checked to see if data was
written past the end of the buffer. If an overwrite is seen, the kernel panics.
|
|
CONTENTS
|
0x8
|
The allocator logs up to 256 bytes
of buffer contents when the buffer is freed. Requires that AUDIT also be set.
The numeric value of these flags can be
logically added (OR'ed) together and set by the /etc/system
file in the Solaris 8 release, or for previous releases, by booting kadb and setting the flags before starting the kernel.
|
|
LITE
|
0x100
|
Does minimal sanity checking when
a buffer is allocated and freed. When enabled, the allocator checks that the
redzone has not been written into, that a freed buffer is not being freed
again, and that the buffer being freed is the size that was allocated. This
flag is available as of the Solaris 7 3/99
release. Do not combine this flag with any other flags.
|
- Data Type
-
Signed integer
- Default
-
0 (disabled)
- Range
-
0 (disabled) or 1 - 15 or
256 (0x100)
- Dynamic?
-
Yes. Changes made during
runtime only affect new kernel memory caches. After system initialization,
the creation of new caches is rare.
- Validation
-
None
- When to Change
-
When memory corruption
is suspected.
- Commitment Level
-
Unstable
General Driver
moddebug
- Description
-
Variable that you can
set to values that cause messages about various steps in the module loading
process to be displayed.
- Data Type
-
Signed integer
- Default
-
0 (messages off)
- Range
-
The most useful values are:
-
0x80000000 - Prints [un] loading... message.
For every module loaded, messages such as the following would appear on the
console and in the /var/adm/messages file:
Nov 5 16:12:28 sys genunix: [ID 943528 kern.notice]
load 'sched/ TS_DPTBL' id 9 loaded @ 0x10126438/
0x10438dd8 size 132/2064
Nov 5 16:12:28 sys genunix: [ID 131579 kern.notice]
installing TS_DPTBL, module id 9.
|
-
0x40000000 - Prints detailed error messages. For every module
loaded, messages such as the following would appear on the console and in
the /var/adm/messages file:
Nov 5 16:16:50 sys krtld: [ID 284770 kern.notice]
kobj_open: can't open /platform/SUNW,Ultra-1/kernel/
sched/TS_DPTBL
Nov 5 16:16:50 sys krtld: [ID 284770 kern.notice]
kobj_open: can't open /platform/sun4u/kernel/
sched/TS_DPTBL
Nov 5 16:16:50 sys krtld: [ID 797908 kern.notice]
kobj_open: '/kernel/sch...
Nov 5 16:16:50 sys krtld: [ID 605504 kern.notice]
descr = 0x2a
Nov 5 16:16:50 sys krtld: [ID 642728 kern.notice]
kobj_read_file: size=34,
Nov 5 16:16:50 sys krtld: [ID 217760 kern.notice]
offset=0
Nov 5 16:16:50 sys krtld: [ID 136382 kern.notice]
kobj_read: req 8192 bytes,
Nov 5 16:16:50 sys krtld: [ID 295989 kern.notice]
got 4224
Nov 5 16:16:50 sys krtld: [ID 426732 kern.notice]
read 1080 bytes
Nov 5 16:16:50 sys krtld: [ID 720464 kern.notice]
copying 34 bytes
Nov 5 16:16:50 sys krtld: [ID 234587 kern.notice]
count = 34 [33 lines elided]
Nov 5 16:16:50 sys genunix: [ID 943528 kern.notice]
load 'sched/TS_DPTBL' id 9 loaded @ 0x10126438/
0x10438dd8 size 132/2064
Nov 5 16:16:50 sys genunix: [ID 131579 kern.notice]
installing TS_DPTBL, module id 9.
Nov 5 16:16:50 sys genunix: [ID 324367 kern.notice]
init 'sched/TS_DPTBL' id 9 loaded @ 0x10126438/
0x10438dd8 size 132/2064
|
-
0x20000000 - Prints even more detailed messages. This doesn't
print any additional information beyond what the detailed error message flag does during system boot, but it does print additional information
about releasing the module when the module is unloaded.
These values can be added together to set the final value.
- Dynamic?
-
Yes
- Validation
-
None
- When to Change
-
When a module is
either not loading as expected or the system seems to hang while loading modules.
Note that when print detailed messages is set, system boot
is slowed down considerably by the number of messages written to the console.
- Commitment Level
-
Unstable
General I/O
maxphys
- Description
-
Maximum size of physical
I/O requests. If a driver sees a request larger than this size, the driver
breaks the request into maxphys size chunks. File systems
can and do impose their own limit.
- Data Type
-
Signed integer
- Default
-
126,976 (sun4m), 131,072
(sun4u), 57,344 (Intel). The sd driver uses the value
of 1,048,576 if the drive supports wide transfers. The ssd
driver uses 1,048,576 by default.
- Range
-
Machine-specific page size
to MAXINT
- Units
-
Bytes
- Dynamic?
-
Yes, but many file systems
load this value into a per-mount point data structure when the file system
is mounted. A number of drivers load the value at the time a device is attached
into a driver-specific data structure.
- Validation
-
None
- When to Change
-
When doing I/O to
and from raw devices in large chunks. Note that a DBMS doing OLTP operations
issues large numbers of small I/Os. Changing maxphys does
not result in any performance improvement in that case.
When doing I/O to and from a UFS file system where large amounts of
data (greater than 64 Kbytes) are being read or written at any one time. Note
that the file system should be optimized to increase contiguity (for example,
increase the size of the cylinder groups and decrease the number of inodes
per cylinder group). UFS imposes an internal limit of 1 Mbyte on the maximum
I/O size it transfers.
- Commitment Level
-
Unstable
rlim_fd_max
- Description
-
"Hard" limit on file
descriptors that a single process might have open. To override this limit
requires superuser privilege.
- Data Type
-
Signed integer
- Default
-
1024
- Range
-
1 to MAXINT
- Units
-
File descriptors
- Dynamic?
-
No
- Validation
-
None
- When to Change
-
When the maximum
number of open files for a process is not enough. Note that other limitations
in system facilities can mean that a larger number of file descriptors is
not as useful as it might be:
-
A 32-bit program using standard I/O is limited to 256 file
descriptors. A 64-bit program using standard I/O can use up to 2 billion descriptors.
-
select(3C)
is by default limited to 1024 descriptors per fd_set. Starting
with the Solaris 7 release, 32-bit application code can be recompiled with
a larger fd_set size (less than or equal to 65,536). A
64-bit application sees an fd_set size of 65,536, which
cannot be changed.
An alternative to changing this on a system wide basis is to use the plimit(1) command.
If a parent process has its limits changed by plimit, all
children inherit the increased limit. This is useful for daemons such as inetd.
- Commitment Level
-
Unstable
rlim_fd_cur
- Description
-
"Soft" limit on file
descriptors that a single process can have open. A process might adjust its
file descriptor limit to any value up to the "hard" limit defined by rlim_fd_max by using the setrlimit() call or
issuing the limit command in whatever shell it is running.
You do not require superuser privilege to adjust the limit to any value less
than or equal to the hard limit.
- Data Type
-
Signed integer
- Default
-
256
- Range
-
1 to MAXINT
- Units
-
File descriptors
- Dynamic?
-
No
- Validation
-
Compared to rlim_fd_max and if rlim_fd_cur is greater than rlim_fd_max, rlim_fd_cur is reset to rlim_fd_max.
- When to Change
-
When the default
number of open files for a process is not enough. Increasing this value means
only that it is possibly not necessary for a program to use setrlimit(2) to increase
the maximum number of file descriptors available to it.
- Commitment Level
-
Unstable
- Change History
-
See rlim_fd_cur (Solaris 7 Release and Earlier)
for more information.
General File System
ncsize
- Description
-
Number of entries in
the directory name look-up cache (DNLC). This parameter is used by UFS and
NFS to cache elements of path names that have been resolved.
Starting with the Solaris 8 6/00 release, the DNLC also caches negative
lookup information, which means it caches a name not found in the cache.
- Data Type
-
Signed integer
- Default
-
4 x (v.v_proc
+ maxusers) + 320
- Range
-
0 to MAXINT
- Units
-
DNLC entries
- Dynamic?
-
No
- Validation
-
None. Larger values cause
the time it takes to unmount a file system to increase as the cache must be
flushed of entries for that file system during the unmount process.
- When to Change
-
Prior to the Solaris
8 6/00 release, it is difficult to determine whether the cache is too small.
It is possible to infer this by noting the number of enters returned by kstat -n ncstats. If the number seems high given the system workload
and file access pattern, this may be due to the size of the DNLC.
Starting with the Solaris 8 6/00 release, kstat -n dnlcstats, is available for you to determine when entries have been removed
from the DNLC because it was too small. The sum of the pick_heuristic and the pick_last represents otherwise valid
entries which were reclaimed because the cache was too small.
Note that excessive values of ncsize have an immediate
impact on the system since the system allocates a set of data structures for
the DNLC based on the value of ncsize. A system running
a 32-bit kernel allocates 36 byte structures for ncsize,
while a system running a 64-bit kernel allocates 64 byte structures for ncsize. The value also has a further affect on UFS and NFS unless ufs_inode and nfs:nfs_rnode are explicitly set.
- Commitment Level
-
Unstable
rstchown
- Description
-
Indicates whether the
POSIX semantics for the chown(2) system call are in effect. POSIX semantics
are:
-
A process cannot change the owner of a file unless it is running
with UID 0.
-
A process cannot change the group ownership of a file to a
group in which it is not currently a member unless it is running as UID 0.
- Data Type
-
Signed integer
- Default
-
1, indicating that POSIX
semantics are used
- Range
-
0 = POSIX semantics not in
force, 1 = POSIX semantics used
- Units
-
Toggle (on/off)
- Dynamic?
-
Yes
- Validation
-
None
- When to Change
-
When POSIX semantics
are not desired. Note that turning off POSIX semantics opens the potential
for various security holes. It also opens the possibility of a user changing
ownership of a file to another user and being unable to retrieve the file
back without intervention from the user or the system administrator.
- Commitment Level
-
Obsolete
segkpsize
- Description
-
Specify the amount of
kernel pageable memory available. This memory is used primarily for kernel
thread stacks. Increasing this number allows either larger stacks for the
same number of threads or more threads. This parameter can only be set on
systems running 64–bit kernels. Systems running 64-bit kernels use a
default stack size of 24 Kbytes.
- Data Type
-
Unsigned long
- Default
-
64–bit kernels, 2
Gbytes
32–bit kernels, 512 Mbytes
- Range
-
64–bit kernels, 512
Mbytes - 24 Gbytes
32-bit kernels, 512 Mbytes
- Units
-
Mbytes
- Dynamic?
-
No
- Validation
-
Value is compared to
minimum and maximum sizes (512 Mbytes and 24 Gbytes for 64-bit systems) and
if smaller than the minimum or larger than the maximum, it is reset to 2 Gbytes
and a message to that effect is displayed.
The actual size used in creation of the cache is the lesser of the value
specified in segkpsize after the constraints checking and
50% of physical memory.
- When to Change
-
This is one of the
steps necessary to support large numbers of processes on a system. The default
size of 2 Gbytes, assuming at least 1 Gbyte of physical memory is present,
allows creation of 24–Kbyte stacks for more than 87,000 kernel threads.
The size of a stack in a 64-bit kernel is the same whether the process is
a 32-bit process or a 64-bit process. If more than this number is needed, segkpsize can be increased assuming sufficient physical memory exists.
- Commitment Level
-
Unstable
- Change History
-
See segkpsize (Solaris 7 and Earlier Releases)
for more information.
dnlc_dir_enable
- Description
-
Enables large directory
caching.
- Data Type
-
Unsigned integer
- Default
-
1 (enabled)
- Range
-
0 (disabled), 1 (enabled)
- Dynamic?
-
Yes, but do not change
this tunable dynamically. It is possible to enable it if originally disabled,
or to disable it if originally enabled. However, enabling, disabling, and
then enabling this parameter might lead to stale directory caches.
- Validation
-
No
- When to Change
-
Directory caching
has no known problems, but if problems occur, then set dnlc_dir_enable to 0 to disable caching.
- Commitment Level
-
Unstable
dnlc_dir_min_size
- Description
-
Minimum number of entries
before caching for one directory.
- Data Type
-
Unsigned integer
- Default
-
40
- Range
-
0 to MAXUINT (no maximum)
- Units
-
- Dynamic?
-
Yes, it can be changed
at any time.
- Validation
-
No
- When to Change
-
If performance problems
occur with caching small directories, then increase dnlc_dir_min_size. Note that individual file systems might have their own range limits
for caching directories. For instance, UFS limits directories to a minimum
of ufs_min_dir_cache bytes (approximately 1024 entries),
assuming 16 bytes per entry.
- Commitment Level
-
Unstable
dnlc_dir_max_size
- Description
-
Maximum number of entries
cached for one directory.
- Data Type
-
Unsigned integer
- Default
-
MAXUINT (no maximum)
- Range
-
0 to MAXUINT
- Dynamic?
-
Yes, it can be changed
at any time.
- Validation
-
No
- When to Change
-
If performance problems
occur with large directories, then decrease dnlc_dir_max_size.
- Commitment Level
-
Unstable
UFS
bufhwm
- Description
-
Maximum amount of memory
for caching I/O buffers. The buffers are used for writing file system metadata
(superblocks, inodes, indirect blocks, and directories). Buffers are allocated
as needed until the amount to be allocated would exceed bufhwm.
At this point, enough buffers are reclaimed to satisfy the request.
For historical reasons, this parameter does not require the ufs: prefix.
- Data Type
-
Signed integer
- Default
-
2% of physical memory
- Range
-
80 Kbytes to 20% of physical
memory
- Units
-
Kbytes
- Dynamic?
-
No. Value is used to compute
hash bucket sizes and is then stored into a data structure that adjusts the
value in the field as buffers are allocated and deallocated. Attempting to
adjust this value without following the locking protocol on a running system
can lead to incorrect operation.
- Validation
-
If bufhwm
is less than 80 Kbytes or greater than the lesser of 20% of physical memory
or twice the current amount of kernel heap, it is reset to the lesser of 20%
of physical memory or twice the current amount of kernel heap. The following
message appears on the system console and in the /var/adm/messages file.
binit: bufhwm out of range (value attempted). Using N.
Value attempted refers to the value entered in /etc/system or by using kadb -d. N is the value computed by the system
based on available system memory.
- When to Change
-
Since buffers are
only allocated as they are needed, the overhead from the default setting is
the allocation of a number of control structures to handle the maximum possible
number of buffers. These structures consume 52 bytes per potential buffer
on a 32–bit kernel and 104 bytes per potential buffer on a 64–bit
kernel. On a 512 Mbyte 64–bit kernel this consumes 104*10144 bytes,
or 1 Mbyte. The header allocations assumes buffers are 1 Kbyte in size, although
in most cases, the buffer size is larger.
The amount of memory, which has not been allocated in the buffer pool,
can be found by looking at the bfreelist structure in the
kernel with a kernel debugger. The field of interest in the structure is bufsize, which is the possible remaining memory in bytes. Looking
at it with the buf macro by using mdb:
# mdb -k
Loading modules: [ unix krtld genunix ip nfs ipc ]
> bfreelist$<buf
bfreelist:
[ elided ]
bfreelist + 0x78: bufsize [ elided ]
75734016
|
bufhwm on this system, with 6 Gbytes of memory, is
122277. It is not directly possible to determine the number of header structures
used since the actual buffer size requested is usually larger than 1 Kbyte.
However, some space might be profitably reclaimed from control structure allocation
for this system.
The same structure on the 512 Mbyte system shows that only 4 Kbytes
of 10144 Kbytes has not been allocated. When the biostats kstat
is examined with kstat -n biostats, it is seen that the
system had a reasonable ratio of buffer_cache_hits to buffer_cache_lookups as well. This indicates that the default setting
is reasonable for that system.
- Commitment Level
-
Unstable
ndquot
- Description
-
Number of quota structures
for the UFS file system that should be allocated. Relevant only if quotas
are enabled on one or more UFS file systems. Because of historical reasons,
the ufs: prefix is not needed.
- Data Type
-
Signed integer
- Default
-
((maxusers
x 40) / 4) + max_nprocs
- Range
-
0 to MAXINT
- Units
-
Quota structures
- Dynamic?
-
No
- Validation
-
None. Excessively large
values hang the system.
- When to Change
-
When the default
number of quota structures is not enough. This situation is indicated by the
following message displayed on the console or written in the message log.
- Commitment Level
-
Unstable
ufs_ninode
- Description
-
Number of inodes to
be held in memory. Inodes are cached globally (for UFS), not on a per-file
system basis.
A key variable in this situation is ufs_ninode. This
parameter is used to compute two key limits that affect the handling of inode
caching. A high watermark of ufs_ninode / 2 and a low water
mark of ufs_ninode / 4 are computed.
When the system is done with an inode, one of two things can happen:
-
The file referred to by the inode is no longer on the system
so the inode is deleted. After it is deleted, the space goes back into the
inode cache for use by another inode (which is read from disk or created for
a new file).
-
The file still exists but is no longer referenced by a running
process. The inode is then placed on the idle queue. Any referenced pages
are still in memory.
When inodes are idled, the kernel defers the idling process to a later
time. If a file system is a logging file system the kernel also defers deletion
of inodes. Two kernel threads do this. Each thread is responsible for one
of the queues.
When the deferred processing is done, the system drops the inode onto
either a delete or idle queue, each of which has a thread that can run to
process it. When the inode is placed on the queue, the queue occupancy is
checked against the low watermark. If it is in excess of the low watermark,
the thread associated with the queue is awakened. After it is awakened, the
thread runs through the queue and forces any pages associated with the inode
out to disk and frees the inode. The thread stops when it has removed 50%
of the inodes on the queue at the time it was awakened.
A second mechanism is in place if the idle thread is unable to keep
up with the load. When the system needs to find a vnode, it goes through the ufs_vget routine. The first thing vget does is check the length of the idle queue. If the length is
above the high watermark, then it pops two inodes off the idle queue and "idles"
them (flushes pages and frees inodes). It does this before
it gets an inode for its own use.
The system does attempt to optimize by placing inodes with no in-core
pages at the head of the idle list and inodes with pages at the end of the
idle list, but it does no other ordering of the list. Inodes are always removed
from the front of the idle queue.
The only time that inodes are removed from the queues as a whole is
when a sync, unmount, or remount occur.
For historical reasons, this parameter does not require the ufs: prefix.
- Data Type
-
Signed integer
- Default
-
ncsize
- Range
-
0 to MAXINT
- Units
-
Inodes
- Dynamic?
-
Yes
- Validation
-
If ufs_ninode is less than or equal to zero, the value is set to ncsize.
- When to Change
-
When the default
number of inodes is not enough. If the maxsize reached
field as reported by kstat -n inode_cache is larger than
the maxsize field in the kstat, the value of ufs_ninode may be too small. Excessive inode idling (described previously)
can also be a problem.
This situation can be identified by using kstat -n inode_cache to look at the inode_cache kstat. Thread idles are inodes idled by the background threads while vget idles are idles by the requesting process before using an inode.
- Commitment Level
-
Unstable
ufs:ufs_WRITES
- Description
-
If ufs_WRITES is non-zero, the number of bytes outstanding for writes on a file
is checked. See ufs_HW subsequently to determine whether
the write should be issued or should be deferred until only ufs_LW bytes are outstanding. The total number of bytes outstanding is
tracked on a per-file basis so that if the limit is passed for one file, it
won't affect writes to other files.
- Data Type
-
Signed integer
- Default
-
1 (enabled)
- Range
-
0 (disabled), 1 (enabled)
- Units
-
Toggle (on/off)
- Dynamic?
-
Yes
- Validation
-
None
- When to Change
-
When you want UFS
write throttling turned off entirely. If sufficient I/O capacity does not
exist, disabling this parameter can result in long service queues for disks.
- Commitment Level
-
Unstable
ufs:ufs_LW and ufs:ufs_HW
- Description
-
ufs_HW
is the number of bytes outstanding on a single file barrier value. If the
number of bytes outstanding is greater than this value and ufs_WRITES is set, then the write is deferred. The write is deferred by putting
the thread issuing the write to sleep on a condition variable.
ufs_LW is the barrier for the number of bytes outstanding
on a single file below which the condition variable on which other sleeping
processes are toggled. When a write completes and the number of bytes is less
than ufs_LW, then the condition variable is toggled, which
causes all threads waiting on the variable to awaken and try to issue their
writes.
- Data Type
-
Signed integer
- Default
-
256 x 1024 for ufs_LW and 384 x 1024 for ufs_HW
- Range
-
0 to MAXINT
- Units
-
Bytes
- Dynamic?
-
Yes
- Validation
-
None
- Implicit
-
ufs_LW
and ufs_HW have meaning only if ufs_WRITES
is not equal to zero. ufs_HW and ufs_LW
should be changed together to avoid needless churning when processes awake
and find that they either cannot issue a write (when ufs_LW
and ufs_HW are too close) or when they might have waited
longer than necessary (when ufs_LW and ufs_HW are too far apart).
- When to Change
-
Consider changing
these values when file systems consist of striped volumes. The aggregate bandwidth
available can easily exceed the current value of ufs_HW.
Unfortunately, this is not a per-file system setting.
When ufs_throttles is a non-trivial number. ufs_throttles can currently be accessed only with a kernel debugger.
- Commitment Level
-
Unstable
TMPFS
tmpfs:tmpfs_maxkmem
- Description
-
Maximum amount of kernel
memory that TMPFS can use for its data structures (tmpnodes and directory
entries).
- Data Type
-
Unsigned long
- Default
-
One page or 4% of physical
memory, whichever is greater.
- Range
-
Number of bytes in one page
(8192 for UltraSPARCTM systems, 4096 for all others)
to 25% of the available kernel memory at the time TMPFS was first used.
- Units
-
Bytes
- Dynamic?
-
Yes
- Validation
-
None
- When to Change
-
Increase if the following
message is displayed on the console or written in the messages file.
tmp_memalloc: tmpfs over memory limit
|
The current amount of memory used by TMPFS for its data structures is
held in the tmp_kmemspace field, which can be examined
with a kernel debugger.
- Commitment Level
-
Unstable
- Changes From Previous Release
-
tmpfs:tmpfs_maxkmem
tmpfs:tmpfs_minfree
- Description
-
Minimum amount of swap
space that TMPFS leaves for the rest of the system.
- Data Type
-
Signed long
- Default
-
256
- Range
-
0 to maximum swap space size
- Units
-
Pages
- Dynamic?
-
Yes
- Validation
-
None
- When to Change
-
To maintain a reasonable
amount of swap space on systems with large amounts of TMPFS usage, you can
increase this number. The limit has been reached when the console or system
messages file displays the following message.
fs-name: File system full, swap
space limit exceeded
- Commitment Level
-
Unstable
- Changes From Previous Release
-
See tmpfs:tmpfs_minfree for more information.
Pseudo Terminals
Pseudo terminals, ptys, are used for two purposes
in Solaris:
-
Supporting remote logins by using the telnet, rlogin, or rsh commands
-
Providing the interface through which the X Window system
creates command interpreter windows
The default number of pseudo-terminals is sufficient for a desktop workstation
so tuning focuses on the number of ptys available for remote
logins.
Previous versions of Solaris required that steps be taken to explicitly
configure the system for the desired number of ptys. Starting
with the Solaris 8 release, a new mechanism removes the necessity for tuning
in most cases. The default number of ptys is now based
on the amount of memory on the system and should be changed only to increase
the number or to decrease the default value.
Three related variables are used in the configuration process:
-
pt_cnt - Default maximum number of ptys
-
pt_pctofmem - Percentage of kernel memory
that can be dedicated to pty support structures
-
pt_max_pty - Hard maximum for number of ptys
pt_cnt has a default value of zero, which tells the
system to limit logins based on the amount of memory specified in pct_pctofmem, unless pt_max_pty is set. If pt_cnt is non-zero, ptys are allocated until
this limit. When that threshold is crossed, the system looks at pt_max_pty. If that has a non-zero value, it is compared to pt_cnt and the pty allocation is allowed if pt_cnt is less than pt_max_pty. If pt_max_pty is zero, pt_cnt is compared to the
number of ptys supported based on pt_pctofmem. If pt_cnt is less than this value, the pty allocation is allowed. Note that the limit based on pt_pctofmem only comes into play if both pt_cnt
and ptms_ptymax have their default values of zero.
To put a hard limit on ptys that is different than
the maximum derived from pt_pctofmem, set pt_cnt and ptms_ptymax in /etc/system
to the number of ptys desired. The setting of ptms_pctofmem is not relevant in this case.
To dedicate a different percentage of system memory to pty support and let the operating system manage the explicit limits,
do the following:
-
Do not set pt_cnt or ptms_ptymax in /etc/system.
-
Set pt_pctofmem in /etc/system to the desired percentage. For example, set pt_pctofmem=10 for a 10% setting.
Note that the memory is not actually allocated until it is used in support
of a pty. Once memory is allocated, it remains allocated.
pt_cnt
- Description
-
The number of /dev/pts entries available is dynamic up to a limit determined
by the amount of physical memory available on the system. pt_cnt is one of three variables that determines the minimum number of
logins that the system can accommodate. The default maximum number of /dev/pts devices the system can support is determined at boot time
by computing the number of pty structures that can fit
in a percentage of system memory (see pt_pctofmem next).
If pt_cnt is zero, the system allocates up to that maximum.
If pt_cnt is non-zero, the system allocates to the greater
of pt_cnt and the default maximum.
- Data Type
-
Unsigned integer
- Default
-
0
- Range
-
0 to maxpid
- Units
-
logins/windows
- Dynamic?
-
No
- Validation
-
None
- When to Change
-
When you want to
explicitly control the number of users that can remotely log in to the system.
- Commitment Level
-
Unstable
- Change History
-
See pt_cnt (Solaris 7 and Earlier Releases)
for more information.
pt_pctofmem
- Description
-
Maximum percentage of
physical memory that can be consumed by data structures to support /dev/pts entries. A system running a 64-bit
kernel consumes 176 bytes per /dev/pts entry. A system
running a 32-bit kernel consumes 112 bytes per /dev/pts
entry.
- Data Type
-
Unsigned integer
- Default
-
5
- Range
-
0 to 100
- Units
-
Percentage
- Dynamic?
-
No
- Validation
-
None
- When to Change
-
When you want to
either restrict or increase the number of users that can log in to the system.
A value of zero means that no remote users can log in to the system.
- Commitment Level
-
Unstable
pt_max_pty
- Description
-
Maximum number of ptys the system offers.
- Data Type
-
Unsigned integer
- Default
-
0 (Uses system defined maximum)
- Range
-
0 to MAXUINT
- Units
-
logins/windows
- Dynamic?
-
Yes
- Validation
-
None
- Implicit
-
Should be greater than
or equal to pt_cnt.Value is not checked until the number
of ptys allocated exceeds the value of pt_cnt.
- When to Change
-
When you want to
place an absolute ceiling on the number of logins supported even if the system
could handle more based on its current configuration values.
- Commitment Level
-
Unstable
Streams
nstrpush
- Description
-
Number of modules that
can be inserted into (pushed onto) into a stream.
- Data Type
-
Signed integer
- Default
-
9
- Range
-
9 to 16
- Units
-
Modules
- Dynamic?
-
Yes
- Validation
-
None
- When to Change
-
At the direction
of your software vendor. No messages are displayed when a STREAM exceeds its
permitted push count. A value of EINVAL is returned to
the program that attempted the push.
- Commitment Level
-
Unstable
strmsgsz
- Description
-
Maximum number of bytes
that a single system call can pass to a STREAM to be placed in the data part
of a message. Any write(2) exceeding this size is broken into multiple messages.
- Data Type
-
Signed integer
- Default
-
65,536
- Range
-
0 to 262,144
- Units
-
Bytes
- Dynamic?
-
Yes
- Validation
-
None
- When to Change
-
When putmsg(2) calls return ERANGE.
- Commitment Level
-
Unstable
strctlsz
- Description
-
Maximum number of bytes
that a single system call can pass to a STREAM to be placed in the control
part of a message.
- Data Type
-
Signed integer
- Default
-
1024
- Range
-
0 to MAXINT
- Units
-
Bytes
- Dynamic?
-
Yes
- Validation
-
None
- When to Change
-
At the direction
of your software vendor. putmsg(2) calls return ERANGE
if they attempt to exceed this limit.
- Commitment Level
-
Unstable
System V Message Queues
System V message queues provide a message-passing interface that enables
exchange of messages by queues created in the kernel. Interfaces are provided
in the Solaris environment to enqueue and dequeue messages. Messages can have
a type associated with them. Enqueueing places messages at the end of a queue.
Dequeuing removes the first message of a specific type from the queue or the
first message if no type is specified.
The module is dynamically loaded on first reference. Parameters provided
to the subsystem are validated at that time. Entries in the /etc/system file must contain the msgsys: prefix.
This facility is different from the POSIX 1003.1b message queue facility.
The Solaris 8 release modified the use of some of the parameters for
this facility. The msgsys:msginfo_msgssz, msgsys:msginfo_msgmap, and msgsys:msginfo_msgseg parameters are now
obsolete. The variables have been left in place to avoid error messages.
Any values applied are ignored.
The maximum number of messages the facility can handle at any one point
in time is now entirely defined by msgsys:msginfo_msgtql.
An array of message headers sized to the value specified in this variable
is allocated and initialized as a free list. When an attempt is made to send
a message, the free list is examined and if a header is available, a buffer
is allocated from kernel memory to handle the message data. The data is copied
into the buffer and the message is placed in the destination queue. When the
message is read, the buffer is freed and the header placed on the free list.
Previous Solaris versions would limit the number of messages either
by setting msgsys:msginfo_msgtql or by limiting the number
of memory segments and the size of the segments that were allocated to a message
buffer pool. When the module is first loaded, it allocates a number of data
structures needed to manage messages. The total space allocated for these
structures must not exceed 25% of available kernel memory, or the attempt
to load fails and the following message is displayed.
msgsys: can't load module, too much memory requested
|
Unlike previous Solaris versions, a message buffer pool is not allocated
as part of set up and is no longer considered in the 25% of memory check.
msgsys:msginfo_msgmax
- Description
-
Maximum size of System
V message.
- Data Type
-
Unsigned long
- Default
-
2048
- Range
-
0 to amount of physical memory
- Units
-
Bytes
- Dynamic?
-
No. Loaded into msgmax field of msginfo structure.
- Validation
-
None
- When to Change
-
When msgsnd(2) calls return with error of EINVAL or at the recommendation of a software vendor.
- Commitment Level
-
Unstable
msgsys:msginfo_msgmnb
- Description
-
Maximum number of bytes
that can be on any one message queue.
- Data Type
-
Unsigned long
- Default
-
4096
- Range
-
0 to amount of physical memory
- Units
-
Bytes
- Dynamic?
-
No. Loaded into msgmnb field of msginfo structure.
- Validation
-
None
- When to Change
-
When msgsnd() calls block or return with an error of EAGAIN,
or at the recommendation of a software vendor.
- Commitment Level
-
Unstable
msgsys:msginfo_msgmni
- Description
-
Maximum number of message
queues that can be created.
- Data Type
-
Signed integer
- Default
-
50
- Range
-
0 to MAXINT
- Dynamic?
-
No. Loaded into msgmni field of msginfo structure.
- Validation
-
None
- When to Change
-
When msgget(2) calls return with an error
of ENOSPC or at the recommendation of a software vendor.
- Commitment Level
-
Unstable
msgsys:msginfo_msgtql
- Description
-
Maximum number of messages
that can be created. If a msgsnd call attempts to exceed
this limit, the request is deferred until a message header is available. Or,
if the request has set the IPC_NOWAIT flag, the request
fails with the error EGAIN.
- Data Type
-
Signed integer
- Default
-
40
- Range
-
0 to MAXINT
- Dynamic?
-
No. Loaded into msgtql field of msginfo structure.
- Validation
-
None
- When to Change
-
When msgsnd() calls block or return with error of EGAIN, or
at the recommendation of a software vendor.
- Commitment Level
-
Unstable
System V Semaphores
System V semaphores provide counting semaphores in the Solaris environment.
In addition to the standard set and release operations for semaphores, System
V semaphores can have values that are incremented and decremented as needed
(for example, to represent the number of resources available). The ability
is offered to do operations on a group of semaphores simultaneously as well
as to have the system undo the last operation by a process if it dies.
Semaphores are created in sets.
The module is dynamically loaded on first reference. Parameters provided
to the subsystem are validated at that time and all data structures (including
the semaphores) are created. Values for parameters are, accordingly, not changeable
at runtime because increases in values would lead to data corruption. Entries
in the /etc/system
file must contain the semsys: prefix.
This facility is different from the POSIX 1003.1b semaphore facility.
semsys:seminfo_semmni
- Description
-
Maximum number of semaphore
identifiers.
- Data Type
-
Signed integer
- Default
-
10
- Range
-
1 to 65,535
- Dynamic?
-
No
- Validation
-
Compared to SEMA_INDEX_MAX (currently 65,535) and reset to that value if larger.
A warning message is written to the console and or system messages file.
- When to Change
-
When the default
number of sets is not enough. Generally changed at the recommendation of software
vendors. No error messages are displayed when an attempt is made to create
more sets than are currently configured. The application sees a return code
of ENOSPC from a semget(2) call.
- Commitment Level
-
Unstable
semsys:seminfo_semmns
- Description
-
Maximum number of System
V semaphores on the system.
- Data Type
-
Signed integer
- Default
-
60
- Range
-
1 to MAXINT
- Dynamic?
-
No
- Validation
-
The amount of space that
could possibly be consumed by the semaphores and their supporting data structures
is compared to 25% of the kernel memory available at the time the module is
first loaded. If the memory threshold is exceeded, the module refuses to load
and the semaphore facility is not available.
- When to Change
-
When the default
number of semaphores is not enough. Generally changed at the recommendation
of software vendors. No error messages are displayed when an attempt is made
to create more semaphores than are currently configured. The application sees
a return code of ENOSPC from a semget(2) call.
- Commitment Level
-
Unstable
semsys:seminfo_semvmx
- Description
-
Maximum value a semaphore
can be set to.
- Data Type
-
Unsigned short
- Default
-
32,767
- Range
-
1 to 65,535
- Dynamic?
-
No
- Validation
-
None
- When to Change
-
When the default
value is not enough. Generally changed at the recommendation of software vendors.
No error messages are displayed when the maximum value is exceeded. The application
sees a return code of ERANGE from a semop(2) call.
- Commitment Level
-
Unstable
semsys:seminfo_semmsl
- Description
-
Maximum number of System
V semaphores per semaphore identifier.
- Data Type
-
Signed integer
- Default
-
25
- Range
-
1 to MAXINT
- Dynamic?
-
No
- Validation
-
The amount of space that
could possibly be consumed by the semaphores and their supporting data structures
is compared to 25% of the kernel memory available at the time the module is
first loaded. If the memory threshold is exceeded, the module refuses to load
and the semaphore facility is not available.
- When to Change
-
When the default
value is not enough. Generally changed at the recommendation of software vendors.
No error messages are displayed when an attempt is made to create more semaphores
in a set than are currently configured. The application sees a return code
of EINVAL from a semget(2) call.
- Commitment Level
-
Unstable
semsys:seminfo_semopm
- Description
-
Maximum number of System
V semaphore operations per semop(2) call. This parameter refers to the number
of sembufs in the sops array that is
provided to the semop() system call.
- Data Type
-
Signed integer
- Default
-
10
- Range
-
1 to MAXINT
- Dynamic?
-
No
- Validation
-
The amount of space that
could possibly be consumed by the semaphores and their supporting data structures
is compared to 25% of the kernel memory available at the time the module is
first loaded. If the memory threshold is exceeded, the module refuses to load
and the semaphore facility is not available.
- When to Change
-
When the default
value is not enough. Generally changed at the recommendation of software vendors.
No error messages are displayed when an attempt is made to perform more semaphore
operations in a single semop call than are currently allowed.
The application sees a return code of E2BIG from a semop() call.
- Commitment Level
-
Unstable
semsys:seminfo_semmnu
- Description
-
Total number of undo
structures supported by the System V semaphore system.
- Data Type
-
Signed integer
- Default
-
30
- Range
-
1 to MAXINT
- Dynamic?
-
No
- Validation
-
The amount of space that
could possibly be consumed by the semaphores and their supporting data structures
is compared to 25% of the kernel memory available at the time the module is
first loaded. If the memory threshold is exceeded, the module refuses to load
and the semaphore facility is not available.
- When to Change
-
When the default
value is not enough. Generally changed at the recommendation of software vendors.
No error message is displayed when an attempt is made to perform more undo
operations than are currently configured. The application sees a return
value of ENOSPC from a semop(2) call when the system runs out of undo
structures.
- Commitment Level
-
Unstable
- Changes From Previous Release
-
See semsys:seminfo_semmnu for more information.
semsys:seminfo_semume
- Description
-
Maximum number of System
V semaphore undo structures that can be used by any one process.
- Data Type
-
Signed integer
- Default
-
10
- Range
-
1 to MAXINT
- Dynamic?
-
No
- Validation
-
The amount of space that
could possibly be consumed by the semaphores and their supporting data structures
is compared to 25% of the kernel memory available at the time the module is
first loaded. If the memory threshold is exceeded, the module refuses to load
and the semaphore facility is not available.
- When to Change
-
When the default
value is not enough. Generally changed at the recommendation of software vendors.
No error messages are displayed when an attempt is made to perform more undo
operations than are currently configured. The application sees a return code
of EINVAL from a semop(2) call.
- Commitment Level
-
Unstable
semsys:seminfo_semaem
- Description
-
Maximum value that a
semaphore's value in an undo structure can be set to.
- Data Type
-
Unsigned short
- Default
-
16,384
- Range
-
1 to 65,535
- Dynamic?
-
No
- Validation
-
None
- When to Change
-
When the default
value is not enough. Generally changed at the recommendation of software vendors.
No error messages are displayed when an attempt is made to perform more undo
operations than are currently configured. The application sees a return code
of EINVAL from a semop(2) call.
- Commitment Level
-
Unstable
System V Shared Memory
System V shared memory allows the creation of a segment by a process.
Cooperating processes can attach to the memory segment (subject to access
permissions on the segment) and gain access to the data contained in the segment.
This capability is implemented as a loadable module. Entries in the /etc/system file must contain the shmsys: prefix.
Starting with the Solaris 7 release, the keyserv daemon
uses System V shared memory.
A special kind of shared memory known as intimate shared memory (ISM)
is used by DBMS vendors to maximize performance. When a shared memory segment
is made into an ISM segment, the memory for the segment is locked. This enables
a faster I/O path to be followed and improves memory usage because a number
of kernel resources describing the segment are now shared between all processes
attaching to the segment in ISM mode.
The module is dynamically loaded on first reference. Parameters provided
to the subsystem are validated at that time.
This facility is different from the POSIX 1003.1b shared memory facility.
shmsys:shminfo_shmmax
- Description
-
Maximum size of system
V shared memory segment that can be created. This parameter is an upper limit
that is checked before the system sees if it actually has the physical resources
to create the requested memory segment.
- Data Type
-
Unsigned long
- Default
-
1,048,576
- Range
-
0 - MAXINT on 32-bit systems,
MAXINT64 on 64-bit systems
- Units
-
Bytes
- Dynamic?
-
No. Loaded into shmmax field of shminfo structure.
- Validation
-
None
- When to Change
-
When the default
value is too low. Generally changed at the recommendation of software vendors,
but unless the size of a shared memory segment needs to be constrained, setting
this parameter to the maximum possible value has no side effects.
- Commitment Level
-
Unstable
shmsys:shminfo_shmmin
- Description
-
Minimum size of system
V shared memory segment that can be created.
- Data Type
-
Unsigned long
- Default
-
1
- Range
-
0 to amount of physical memory
- Units
-
Bytes
- When to Change
-
Not recommended.
System programs such as powerd might fail if this value
is too large. Programs attempting to create a section smaller than the value
of shminfo_shmmin will see an EINVAL
error when attempting to create the segment and generally, will exit.
- Commitment Level
-
Unstable
- Changes From Previous Release
-
See shmsys:shminfo_shmmin for more information.
shmsys:shminfo_shmmni
- Description
-
System wide limit on
number of shared memory segments that can be created.
- Data Type
-
Signed integer
- Default
-
100
- Range
-
0 to MAXINT
- Dynamic?
-
No. Loaded into shmmni field of shminfo structure.
- Validation
-
The amount of space consumed
by the maximum possible number of data structures to support System V shared
memory is checked against 25% of the currently available kernel memory at
the time the module is loaded. If the memory consumed is too large, the attempt
to load the module fails.
- When to Change
-
When the system limits
are too low. Generally changed on the recommendation of software vendors.
- Commitment Level
-
Unstable
shmsys:shminfo_shmseg
- Description
-
Limit on the number
of shared memory segments that any one process can attach.
- Data Type
-
Signed short
- Default
-
6
- Range
-
0 to 32,767
- Dynamic?
-
No. Loaded into shmseg field of shminfo structure.
- Validation
-
The amount of space consumed
by the maximum possible number of data structures to support system V shared
memory is checked against 25% of the currently available kernel memory at
the time the module is loaded. If the memory consumed is too large, the attempt
to load the module fails.
- When to Change
-
When the system limits
are too low. Generally changed on the recommendation of software vendors.
- Commitment Level
-
Unstable
- Changes From Previous Release
-
shmsys:shminfo_shmseg
segspt_minfree
- Description
-
Pages of system memory
that cannot be allocated for ISM shared memory.
- Data Type
-
Unsigned long
- Default
-
5% of available system memory
when first ISM segment is created.
- Range
-
0 to 50% of physical memory.
- Units
-
Pages
- Dynamic?
-
Yes
- Validation
-
None. Values that are
too small can cause the system to hang or performance to severely degrade
when memory is consumed with ISM segments.
- When to Change
-
On database servers
with large amounts of physical memory using ISM, this parameter can be tuned
downward. If ISM segments are not used, this parameter has no effect. A maximum
value of 128 Mbytes (0x4000) is almost certainly sufficient on large memory
machines.
- Commitment Level
-
Unstable
- Changes From Previous Release
-
segspt_minfree
Scheduling
rechoose_interval
- Description
-
Number of clock ticks
before a process is deemed to have lost all affinity for the last CPU it ran
on. After this interval expires, any CPU is considered a candidate for scheduling
a thread. This parameter is relevant only for threads in the timesharing class.
Real-time threads are scheduled on the first available CPU.
- Data Type
-
Signed integer
- Default
-
3
- Range
-
0 to MAXINT
- Dynamic?
-
Yes
- Validation
-
None
- When to Change
-
When caches are large,
or the system is running a critical process, or a set of processes that seem
to suffer from excessive cache misses not caused by data access patterns.
Consider using the processor set (psrset(1M)) capabilities available as of the Solaris
2.6 release or processor binding (pbind(1M)) before
changing this parameter.
- Commitment Level
-
Unstable
Timers
hires_tick
- Description
-
Variable that when set
causes the Solaris environment to use a system clock rate of 1000 instead
of the default value of 100.
- Data Type
-
Signed integer
- Default
-
0
- Range
-
0 (disabled) or 1 (enabled)
- Dynamic?
-
No. Causes new system timing
variable to be set at boot time. Not referenced after boot.
- Validation
-
None
- When to Change
-
When you want timeouts
with a resolution of less than 10 milliseconds and greater than or equal to
1 millisecond.
- Commitment Level
-
Unstable
timer_max
- Description
-
Number of POSIX timers
available.
- Data Type
-
Signed integer
- Default
-
32
- Range
-
0 to MAXINT
- Dynamic?
-
No. Increasing value can
cause a system crash.
- Validation
-
None
- When to Change
-
When default number
of timers offered by system is inadequate. Applications see an EGAIN error when executing timer_create system calls.
- Commitment Level
-
Unstable
Sun4u Specific
consistent_coloring
- Description
-
Starting with the Solaris
2.6 release, the ability to use different page placement policies on the UltraSPARC
(sun4u) platform was introduced. A page placement policy attempts to allocate
physical page addresses to maximize the use of the L2 cache. Whatever algorithm
is chosen as the default algorithm, that algorithm can potentially provide
less optimal results than another algorithm for a particular application set.
This variable changes the placement algorithm selected for all processes on
the system.
Based on the size of the L2 cache, memory is divided into bins. The
page placement code allocates a page from a bin when a page fault first occurs
on an unmapped page. The page chosen depends on which of the three possible
algorithms are used:
-
Page coloring - Various bits of the virtual address are used
to determine the bin from which the page is selected. This is the default
algorithm in the Solaris 8 release. consistent_coloring
is set to zero to use this algorithm. No per-process history exists for this
algorithm.
-
Virtual addr=physical address - Consecutive pages in the program
selects pages from consecutive bins. consistent_coloring
is set to 1 to use this algorithm. No per-process history exists for this
algorithm.
-
Bin-hopping - Consecutive pages in the program generally allocate
pages from every other bin, but the algorithm occasionally skips more bins. consistent_coloring is set to 2 to use this algorithm. Each process
starts at a randomly selected bin and a per-process memory of the last bin
allocated is kept.
- Dynamic?
-
Yes
- Validation
-
None. Values larger than
2 cause a number of WARNING: AS_2_BIN: bad consistent coloring value messages to appear on the console and the system hangs immediately
thereafter. A power-cycle is required to recover.
- When to Change
-
When the primary
workload of the system is a set of long-running high-performance computing
(HPC) application(s). Changing this value might provide better performance.
File servers, database servers, and systems with a number of active processes
(for example, compile or time-sharing servers) will not benefit from changes.
- Commitment Level
-
Unstable
|