Appendix B Revision History for this Manual

This section describes the revision history for this manual.

Current Version—Solaris 9 Release

The current version of this manual applies to the Solaris 9 release.

New Parameters

This parameter is new in the Solaris 8 1/01 release.

logevent_max_q_sz

For information, see logevent_max_q_sz.

Unsupported or Obsolete Parameters

priority_paging and cachefree are Not Supported

The priority_paging and cachefree tunable parameters are not supported in the Solaris 9 release. They have been replaced with an enhanced file system caching architecture that implements paging policies similar to priority paging, but are always enabled. Attempts to set these parameters in the /etc/system file result in boot-time warnings such as:

sorry, variable 'priority_paging' is not defined in the 'kernel'
sorry, variable 'cachefree' is not defined in the 'kernel'     

The SUNWcsr packages that contain the /etc/system file have been modified so that the inclusion of the priority_paging or cachefree tunable parameters are prohibited. If you upgrade to the Solaris 9 release or pkgadd the SUNWcsr packages and your /etc/system file includes the priority_paging or cachefree parameters, the following occurs:

1. This message is displayed if the priority_paging or cachefree parameters are set in the /etc/system file:

   ---

   Note –

   /etc/system has been modified since it contains references to priority paging tunables. Please review the changed file.

   ---

2. Comments are inserted in the /etc/system file before any line that sets priority_paging or cachefree. For example, if priority_paging is set to 1, this line is replaced with the following lines:

* NOTE: As of Solaris 9, priority paging is unnecessary and has been removed. 
* Since references to priority paging-related tunables will now result in 
* boot-time warnings, the assignment below has been commented out. For more 
* details, see the Solaris 9 Release Notes, or the "Solaris Tunable Parameters
* Reference Manual".

Obsolete Parameters

The following parameters are now obsolete.

• rlim_fd_max

• shmsys:shminfo_shmmin

• shmsys:shminfo_shmseg

Changed Parameters

These parameters changed or were corrected.

maxusers

The following section changed.

Range

1 to 2048

to:

Range

1 to 2048, based on physical memory without any setting in the /etc/system file.

1 to 4096, if set in the /etc/system file.

pages_pp_maximum

The following sections changed.

Default

Maximum of the triplet (200, tune_t_minarmem + 100, [10% of memory available at boot time])

to:

Default

The greater of (tune_t_minarmem + 100 and [4% of memory available at boot time + 4 Mbytes])

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.

to:

Range

Minimum value enforced by the system is tune_t_minarmem + 100. The system does not enforce a maximum value.

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.

to:

Validation

If the value specified in the /etc/system file or the calculated default is less than tune_t_minarmem + 100, the value is reset to tune_t_minarmem + 100.

No message is displayed if the value from the /etc/system file is increased. Done only at boot time, and during dynamic reconfiguration operations that involve adding or deleting memory.

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.

to:

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.

Excessively large values can cause memory locking requests to fail unnecessarily.

rlim_fd_max

The following section changed for releases prior to the Solaris 9 release.

Default

1024

to:

Default

65,536

segspt_minfree

The following section changed.

Range

0 to 32,767

to:

Range

0 to 50% of physical memory.

shmsys:shminfo_shmseg

The following section changed.

Description

Limit on the number of shared memory segments that any one process can create.

to:

Description

Limit on the number of shared memory segments that any one process can attach.

shmsys:shminfo_shmmax

The following sections changed.

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.

to:

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.

Attempts to create a shared memory section whose size is zero or whose size is larger than the specified value will fail with an EINVAL error.

Default

1,048,576

to:

Default

8,388,608

tmpfs:tmpfs_maxkmem

The following section changed.

Default

to:

Default

One page or 4% of physical memory, whichever is greater.

tmpfs:tmpfs_minfree

This parameter was corrected. The following section changed:

Units

Bytes

to:

Units

Pages

tcp_rexmit_interval_max

The following section changed.

Range

1 millisecond to 20 seconds

to:

Range

1 millisecond to 2 hours

tcp_slow_start_initial

This parameter was corrected.

For information, see tcp_slow_start_initial.

tcp_conn_req_max_q0

The following section changed:

When to Change

For applications, such as web servers that might receive excessive connection requests, you can increase the default value to match the incoming rate.

The following explains the relationship between tcp_conn_req_max_q0 and the maximum number of pending connections for each socket.

When a connection request is received, TCP first checks if the number (N) of pending TCP connections (three-way handshake is done) waiting to be accepted exceeds the maximum for the listener. If the connections are excessive, the request is denied. If the number of connections is allowable, then TCP checks if the number of incomplete pending TCP connections exceeds the sum of N and tcp_conn_req_max_q0. If it does not, the request is accepted. Otherwise, the oldest incomplete pending TCP request is dropped.

to:

When to Change

For applications, such as web servers that might receive excessive connection requests, you can increase the default value to match the incoming rate.

The following explains the relationship between tcp_conn_req_max_q0 and the maximum number of pending connections for each socket.

When a connection request is received, TCP first checks if the number of pending TCP connections (three-way handshake is done) waiting to be accepted exceeds the maximum (N) for the listener. If the connections are excessive, the request is denied. If the number of connections is allowable, then TCP checks if the number of incomplete pending TCP connections exceeds the sum of N and tcp_conn_req_max_q0. If it does not, the request is accepted. Otherwise, the oldest incomplete pending TCP request is dropped.

Removal of sun4d Support

The sun4d platform is not supported in the Solaris 9 release. The following parameters were modified to reflect the removal of sun4d support:

• max_nprocs

• maxphys

• noexec_user_stack

Changes to Existing Parameters From the Previous Release (Solaris 8)

shmsys:shminfo_shmmin

The following section changed:

When to Change

No known reason.

To:

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.

semsys:seminfo_semmnu

This parameter was added because it was left out inadvertently.