As with most complex systems, parameters for overall control of the system can have a dramatic effect on performance. In the past much of a UNIX System Administrator’s time would be spent “tuning” the kernel parameters of a system to achieve greater performance, tighten security, or control a system more closely such as by limiting logins or processes per user. These days, the modern Solaris operating environment is reasonably well tuned out of the box and much of the kernel “tweaking” is generally not needed. That being said, some system parameters still need to be set for specific tasks and for changing the Solaris environment from that of generalized computing to one specialized for the customer’s environment.
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.
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.
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 -
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 |
---|---|
| The search path for modules |
| The root file system type (ufs) |
| The root device—often customized when root is mirrored |
| Modules that should not be loaded—sometimes used as a workaround to skip a faulty module |
| Modules that must be loaded at boot |
| 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)
.
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.
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
.
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.
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
In Solaris 10, we enhanced the System V IPC implementation to do away with as much administrative hand-holding (removing unnecessary tunables) and, by the use of task-based resource controls, to limit users’ access to the System V IPC facilities (replacing the remaining tunables). At the same time, we raised the default values for those limits that remained to more reasonable values. For information on the System V Tunables, see the discussion on Section 4.2.1 in Solaris™ Internals.
[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.
3.133.158.36