| Variable-Name | Variable-Name is the exact name that would be typed in the /etc/system file, or found in the /etc/default/facility file. Most names are of the form variable where the variable name does not contain a colon (:). These names refer to variables in the core portion of the kernel. If the name does contain a colon, the characters to the left of the colon reference the name of a loadable module. The name of the variable within the module consists of the characters to the right of the colon. For example:
| |
| Description | This section briefly describes what the variable does or controls. | |
| Data Type | Signed or unsigned short or long integer with the following distinctions:
| |
| Default | What the system uses as the default value. | |
| Units | (Optional) Description of unit type. | |
| Range | Possible range allowed by system validation or the bounds of the data type.
| |
| Dynamic? | Yes, if it can be changed on a running system with the mdb or kadb debuggers. No, if it is a boot time initialization only. | |
| Validation | Identifies checks the system applies to the value of the variable either as entered from the /etc/system file or the default value, as well as when the validation is applied. | |
| Implicit | (Optional) Unstated constraints that might exist on the variable, especially in relation to other variables. | |
| When to Change | Why someone might want to change this value including error messages or return codes. | |
| Commitment Level | Identifies the stability of the interface. Many of the parameters in this manual are still evolving and are classified as unstable. For more information, see attributes(5). | |
| Change History | (Optional) Contains a link to Change History appendix, if applicable. |
Tuning the Solaris Kernel
The table below describes the different ways tuning parameters can be applied.
Apply Tuning Parameters in These Ways | For More Information |
|---|---|
Modifying the /etc/system file | |
Using the kernel debugger (kadb) | |
Using the modular debugger (mdb) | |
Using the ndd command to set TCP/IP parameters | |
Modifying the /etc/default files |
/etc/system File
The /etc/system file provides a static mechanism for adjusting the values of kernel variables. Values specified in this file are read at boot time and are applied. Any changes 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 system variables were applied in two phases:
The first phase obtains various bootstrap variables (for example, maxusers) to initialize key system parameters.
The second phase calculates the base configuration by using the bootstrap variables, and all values entered in the /etc/system file are applied. In the case of the bootstrap variables, reapplied values replace the values calculated or reset in the initialization phase.
The second phase sometimes caused confusion to users and administrators by setting variables to values that seem to be impermissible or assigning values to variables (for example, max_nprocs) that have a value overridden during the initial configuration.
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 /etc/system before modifying it so you can easily recover from incorrect value:
# cp /etc/system /etc/system.good |
If a value entered in /etc/system 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 carriage return 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, enter the name of the good /etc/system file or /dev/null:
Name of system file [/etc/system]: /etc/system.good |
If /dev/null is entered, this path causes the system to attempt to read from /dev/null for its configuration information and because it 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.
kadb
kadb is a bootable kernel debugger with the same general syntax as adb. For the exceptions, see kadb(1M). One advantage of kadb is that the user can set breakpoints and when the breakpoint is reached, examine data or step through the execution of kernel code.
If the system is booted with the kadb -d command, values for variables in the core kernel can be set, but values for loadable modules would have to be set when the module was actually loaded.
For a brief tutorial on using the kadb command, see "Debugging" in Writing Device Drivers.
mdb
Starting with the Solaris 8 release is the modular debugger, mdb(1), which is unique among available 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. This is the recommended post-mortem debugger for the kernel.
Example--Using mdb to Change a Value
To change the value of the integer variable maxusers from 5 to 6, 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 variable is to be set to.
For more information on using the modular debugger, see the Solaris Modular Debugger Guide.
When using kadb or mdb, the module name prefix is not required because 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 of the debuggers (assuming the UFS module is loaded), but would require the ufs: prefix when set in the /etc/system file. Including the module name prefix kadb results in an undefined symbol message.