Tuning the Solaris Kernel
The following table describes the different ways tunable parameters can be applied.
/etc/system File
The /etc/system file provides a static mechanism for adjusting the values of kernel
parameters. Values specified in this file are read at boot time and are
applied. Any changes that are made to the file are not applied to
the operating system until the system is rebooted.
Prior to the Solaris 8 release, /etc/system entries that set the values of
parameters were applied in two phases:
The first phase obtains various bootstrap parameters (for example, maxusers) to initialize key system parameters.
The second phase calculates the base configuration by using the bootstrap parameters, and all values specified in the /etc/system file are applied. In the case of the bootstrap parameters, reapplied values replace the values that are calculated or reset in the initialization phase.
The second phase sometimes caused confusion to users and administrators by setting parameters
to values that seem to be impermissible or by assigning values to parameters
(for example, max_nprocs) that have a value overridden during the initial configuration.
Starting in the Solaris 8 release, one pass is made to set
all the values before the configuration parameters are calculated.
Example—Setting a Parameter in /etc/system
The following /etc/system entry sets the number of read-ahead blocks that are read
for file systems mounted using NFS version 2 software.
set nfs:nfs_nra=4
Recovering From an Incorrect Value
Make a copy of the /etc/system file before modifying it so that you
can easily recover from incorrect value. For example:
# cp /etc/system /etc/system.good
If a value specified in the /etc/system file causes the system to become
unbootable, you can recover with the following command:
ok boot -a
This command causes the system to ask for the name of various
files used in the boot process. Press the Return key to accept the
default values until the name of the /etc/system file is requested. When the Name of system file [/etc/system]:
prompt is displayed, type the name of the good /etc/system file or
/dev/null:
Name of system file [/etc/system]: /etc/system.good
If /dev/null is specified, this path causes the system to attempt to read
from /dev/null for its configuration information. Because this file is empty, the system
uses the default values. After the system is booted, the /etc/system file
can be corrected.
For more information on system recovery, see System Administration Guide: Basic Administration.
kmdb Command
kmdb is a interactive kernel debugger with the same general syntax as mdb.
An advantage of interactive kernel debugger is that you can set breakpoints. When
a breakpoint is reached, you can examine data or step through the execution
of kernel code.
kmdb can be loaded and unloaded on demand. You do not have to
reboot the system to perform interactive kernel debugging, as was the case with
kadb.
For more information, see kmdb(1).
mdb Command
Starting with the Solaris 8 release is the modular debugger, mdb, is unique
among Solaris debuggers because it is easily extensible. A programming API is available
that allows compilation of modules to perform desired tasks within the context of
the debugger.
mdb also includes a number of desirable usability features, including command-line editing, command
history, built-in output pager, syntax checking, and command pipelining. mdb is the recommended post-mortem
debugger for the kernel.
For more information, see mdb(1).
Example—Using mdb to Change a Value
To change the value of the integer parameter maxusers from 495 to 512,
do the following:
# mdb -kw
Loading modules: [ unix krtld genunix ip logindmux ptm nfs ipc lofs ]
> maxusers/D
maxusers:
maxusers: 495
> maxusers/W 200
maxusers: 0x1ef = 0x200
> $q
Replace maxusers with the actual address of the item to be changed, as
well as the value the parameter is to be set to.
For more information on using the modular debugger, see the Solaris Modular Debugger Guide.
When using either kmdb or mdb debugger, the module name prefix is not
required. After a module is loaded, its symbols form a common name space
with the core kernel symbols and any other previously loaded module symbols.
For example, ufs:ufs_WRITES would be accessed as ufs_WRITES in each debugger (assuming
the UFS module is loaded). The ufs: prefix is required when set in
the /etc/system file.
