Section A.1. Tunable Parameters in Solaris

A.1. Tunable Parameters in Solaris

Historically, Solaris parameters have typically been found in various locations. These include the /etc/system file, running commands like ndd(1) and the /etc/default directory. In more recent Solaris versions, additional features such as resource management and container technology has allowed for a more flexible system of task-based controls and even distributed level of tunables using directory services, not specific to a single system.

The following subsections present an overview of the key locations.

A.1.1. /etc/default Directory

This directory contains configuration files for many Solaris services. With each major release of Solaris, more configuration files have been migrated to this consistent location. Following is a list of these files on Solaris 10.

# ls /etc/default autofs         inetinit       lu             passwd         tar cron           init           metassist.xml  power          telnetd devfsadm       ipsec          mpathd         rpc.nisd       utmpd dhcpagent      kbd            nfs            su             webconsole fs             keyserv        nfslogd        sys-suspend    yppasswdd ftp            login          nss            syslogd 

It is useful to become familiar with which configuration files exist in this directory. They are usually well commented and easy to edit, and some have man pages.

A.1.2. prctl Command

The new framework enables us to dynamically configure tunable parameters by using the resource control framework. Ideally, we want these to be statically defined for our applications. We can also put these definitions within a network database (LDAP) to remove any per-machine settings.

The following example shows how to observe the System V Shared memory max parameter for a given login instance by using the prctl command.

sol10$ id -p uid=0(root) gid=0(root) projid=3(default) sol10# prctl -n project.max-shm-memory -i project 3 project: 3: default NAME    PRIVILEGE       VALUE    FLAG   ACTION                        RECIPIENT project.max-shm-memory         privileged       246MB      -   deny                                  -         system          16.0EB    max   deny                                  - 

The shared memory maximum for this login has defaulted to 246 Mbytes. The following example shows how we can dynamically raise the shared memory limit.

sol10# prctl -n project.max-shm-memory -r -v 500mb -i project 3 sol10# prctl -n project.max-shm-memory -i project 3 project: 3: default NAME    PRIVILEGE       VALUE    FLAG   ACTION                        RECIPIENT project.max-shm-memory         privileged       500MB      -   deny                                  -         system          16.0EB    max   deny                                  - 

To make this permanent, we would create a project entry for the user or project in question.

sol10# projadd -c "My database" -U oracle user.oracle sol10# projmod -sK "project.max-shm-memory=(privileged,64G,deny)" user.oracle sol10# su - oracle oracle$ prctl -n project.max-shm-memory -i project user.oracle project: 101: user.oracle NAME    PRIVILEGE       VALUE    FLAG   ACTION                        RECIPIENT project.max-shm-memory         privileged      64.0GB      -   deny                                  -         system          16.0EB    max   deny                                  - 

A.1.3. /etc/system File

The system configuration file customizes various parameters in the kernel. This file is read-only at boot time, so changes require a reboot to take effect. The following are example configuration lines.

set autoup=600 set nfs:nfs4_nra=16 

This first line sets the parameter autoup to be 600. autoup is a fsflush parameter that defines the age in seconds at which dirty pages are written to disk. The second line sets the nfs4_nra variable from the nfs module to be 16, which is the NFSv4 read-ahead block parameter.

A common reason that /etc/system was modified was to tune kernel parameters such as the maximum shared memory, the number of semaphores, and the number of pts devices. In recent versions of Solaris, some of these commonly tuned parameters have been made dynamic or dynamically changeable, as described in Section A.1.2. You must still edit /etc/system for less commonly used parameters.

Table A.1 lists the various commands that can be placed in /etc/system. These are also listed in the default comments (which start with either "*" or "#").

Table A.1. /etc/system Commands

Command	Description
moddir	The search path for modules
rootfs	The root file system type (ufs)
rootdev	The root deviceoften customized when root is mirrored
exclude	Modules that should not be loadedsometimes used as a workaround to skip a faulty module
forceload	Modules that must be loaded at boot
set	Parameter to set

When changing settings in /etc/system, be sure to carefully study the Tunable Parameters Reference Manual for that release of Solaris. The manual, which is available on docs.sun.com, lists crucial details for each parameter, such as description, data type, default, range, units, dynamic or static behavior, validity checks that are performed, suggestions for when to change, and commitment level.

Another reference for /etc/system is system(4).

A.1.4. driver.conf File

Individual configuration files for drivers (kernel modules) may reside in /kernel/drv, /usr/kernel/drv and under /platform. These files allow drivers to be customized in advanced ways.

However, editing /etc/system is often sufficient since the set command can modify driver parameters, as was shown with nfs:nfs4_nra; the set command also places driver settings in one file for easy maintenance. Editing driver.conf files instead is usually only done under the direction of a Sun engineer.

A.1.5. ndd Command

The ndd^[1] command gets and sets TCP/IP driver parameters and makes temporary live changes. Permanent changes to driver parameters usually need to be listed in /etc/system.

^[1] There is a popular belief that ndd stands for Network Device Driver, which sounds vaguely meaningful. We're not sure what it stands for, nor does the source code say; however, the data types used suggest ndd may mean Name Dispatch Debugger. An Internet search returns zero hits on this.

The following example demonstrates the use of ndd to list the parameters from the arp driver, to list the value of arp_cleanup_interval, and finally to set the value to 60, 000 and check that this worked.

# ndd /dev/arp \? ?                             (read only) arp_cache_report              (read only) arp_debug                     (read and write) arp_cleanup_interval          (read and write) arp_publish_interval          (read and write) arp_publish_count             (read and write) # ndd /dev/arp arp_cleanup_interval 300000 # ndd -set /dev/arp arp_cleanup_interval 60000 # ndd -get /dev/arp arp_cleanup_interval 60000 

The arp_cleanup_interval is the timeout milliseconds for the arp cache.

A.1.6. routeadm(1)

Solaris 10 provides a new command, routeadm, that sets ip_forwarding for network interfaces in a permanent (that is, survives reboots) way. The following command enables ip_forwarding for all network interface and configures routed to broadcast RIP and answer RDISC, both now and after reboots:,

# routeadm -e ipv4-routing -e ipv4-forwarding -u