| | 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 EAGAIN 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
|
Solaris Volume Manager Parameters
md_mirror:md_resync_bufsz
| Description | Sets the size of the
buffer used for resynchronizing RAID 1 volumes (mirrors), as the number of
512-byte blocks in the buffer. Setting larger values can increase resynchronization
speed.
| | Data Type | Integer
| | Default | The default value is 128,
which is acceptable for small systems. Larger systems could use higher values
to increase mirror resynchronization speed.
| | Range | 128 to 2048
| | Units | Blocks (512 bytes)
| | Dynamic? | No
| | Validation | None
| | When to Change | If you use Solaris
Volume Manager RAID 1 volumes (mirrors) and you want to increase the speed
of mirror resynchronizations. Assuming that you have adequate memory for overall
system performance, you can increase this value without causing other performance
problems.
If you need to increase the speed of mirror resynchronizations, increase
the value of this parameter incrementally (using 128-block increments) until
performance is satisfactory. On fairly large or relatively new systems, a
value of 2048 seems to be optimal. High values on older systems might hang
the system.
| | Commitment Level | Unstable
|
| |
