As an operating system, Oracle Solaris adjusts easily to system load and thus requires minimal tuning. However, in certain cases, tuning might be necessary. This book provides details about the officially supported tuning options available for Oracle Solaris.
The Oracle Solaris kernel consists of a core portion, which is always loaded, and a number of loadable modules that are loaded as these modules are being referenced. Many kernel parameters listed in this guide are core parameters. However, a few parameters belong to loadable modules.
The tunable parameters described in this book can change from one Oracle Solaris release to the next. Publication of these tunable parameters does not preclude changes to the tunable parameters and their descriptions without notice.
The following table describes the different ways tunable parameters can be applied.
|
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 then applied. No changes specified in the file take effect unless the system is rebooted.
However, to tune parameters, do NOT edit the /etc/system file. Instead, use files in the /etc/system.d directory. This method enables you to tune system parameters without directly manipulating the /etc/system file. The method consists of the following steps:
Create an empty file in the /etc/system.d directory.
Provide the file with a company specific name and indications of its contents.
In the file itself, add the customized setting for the tunable you are configuring.
As a first step, add only those tunables that are required by in-house or third-party applications. After baseline testing has been established, evaluate system performance to determine if additional tunable settings are required.
Files in the /etc/system.d directory are read at boot time and their contents are added to the /etc/system file. At the end of the boot process, the new configurations are applied to the system.
One pass is made to set all the values before the configuration parameters are calculated.
Example 1 Setting a ZFS Parameter for a Specific SystemThe following entry sets the ZFS ARC maximum (zfs_arc_max) to 30 GB.
set zfs:zfs_arc_max = 0x780000000
Suppose that the name of your company is Widget, Inc. You would store this entry in the /etc/system.d/widget:zfs file. To apply the new zfs_arc_max setting, reboot the machine.
You can recover from an incorrect value by using one of the following approaches:
Resetting the Parameter in the /etc/system.d/file
Remove the defective parameter setting from your configuration file in the /etc/system.d directory. At boot time, the /etc/system file is updated with the previous configurations which are then reapplied to the system.
Using a Cloned Boot Environment
Before you introduce system parameter changes, clone the boot environment first.
# beadm create BE-clonename
Then, if your current BE becomes unusable after applying changes to /etc/system, reboot the system. From the x86 GRUB menu or SPARC boot menu, select the BE clone. After booting completes, you can optionally activate the BE clone to become the default BE to be used in subsequent system boots.
Using File Copies
Make a copy of the /etc/system file before updating it with new parameters from configuration files in the /etc/system.d directory so that you can easily recover from incorrect value. For example:
# cp /etc/system /etc/system.good
If a value specified in the configuration file in /etc/system.d 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 appears, 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 Troubleshooting System Administration Issues in Oracle Solaris 11.3.
The kmdb utility is an interactive kernel debugger with the same general syntax as the modular debugger (mdb). With this debugger, 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 the kadb utility.
For more information, see the kmdb(1) man page.
The modular debugger, mdb, is the recommended post-mortem debugger for the kernel. This debugger also includes a number of desirable usability features such as command-line editing, command history, built-in output pager, syntax checking, and command pipelining. A programming API is available that enables a compilation of modules to perform desired tasks within the context of the debugger.
For more information, see the Oracle Solaris Modular Debugger Guide and the mdb(1) man page.
Example 2 Using mdb to Display InformationDisplay a high-level view of a system's memory usage. For example:
# mdb -k Loading modules: [ unix genunix specfs dtrace mac cpu.generic cpu_ms.AuthenticAMD.15 uppc pcplusmp scsi_vhci zfs mpt sd ip hook neti arp usba sockfs kssl qlc fctl stmf stmf_sbd md lofs random idm fcp crypto cpc smbsrv nfs fcip sppp ufs logindmux ptm nsmb scu mpt_sas pmcs emlxs ] > ::memstat Page Summary Pages MB %Tot ------------ ---------------- ---------------- ---- Kernel 160876 628 16% ZFS File Data 303401 1185 30% Anon 25335 98 2% Exec and libs 1459 5 0% Page cache 5083 19 1% Free (cachelist) 6616 25 1% Free (freelist) 510870 1995 50% Total 1013640 3959 Physical 1013639 3959 > $q
When using either the 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.
This section describes the format for tuning Oracle Solaris parameters.
The exact name of the tunable.
Some parameters use the naming convention module:parameter to indicate that the parameter belongs to a loadable module. For example, tmpfs:tmpfs_maxkmem means that tmpfs_maxkmem is a parameter of the tmpfs module.
Briefly describes what the parameter does or controls.
Indicates the signed or unsigned short integer or long integer. A long integer is twice the width in bits as an integer. For example, an unsigned integer = 32 bits, an unsigned long integer = 64 bits.
(Optional) Describes the unit type.
Indicates the value that the system uses by default.
Specifies the possible range allowed by system validation or the bounds of the data type.
MAXINT – A shorthand description for the maximum value of a signed integer (2,147,483,647)
MAXUINT – A shorthand description for the maximum value of an unsigned integer (4,294,967,295)
Indicates whether the parameter can by configured on a running system with the mdb or kmdb debugger (Yes), or only during boot time initialization (No).
Checks that the system applies to the value of the variable either as specified in the /etc/system file or the default value, as well as when the validation is applied.
(Optional) Provides unstated constraints that might exist on the parameter, especially in relation to other parameters.
Explains why someone might want to change this value. Includes error messages or return codes.
Identifies whether the parameter can be set in a exclusive-IP zone or must be set in the global zone. None of the parameters can be set in shared-IP zones.
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 the attributes(5) man page.