Go to main content

Oracle® Solaris 11.4 Tunable Parameters Reference Manual

Exit Print View

Updated: August 2021

Tuning an Oracle Solaris System

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 manual are core parameters. However, a few parameters belong to loadable modules.

Note - Tuning system parameters is the least effective method to use to improve performance. Rather, improving and tuning the application, as well as adding more physical memory and balancing disk I/O patterns, are better options.

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.

Apply Tunable Parameters in These Ways
For More Information
Set the parameter in a configuration file in the /etc/system.d directory.
Use the kernel debugger (kmdb).
Use the modular debugger (mdb).
Use the ipadm command to set TCP/IP parameters.
Modify the /etc/default files.

/etc/system.d/ Directory Files

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:

  1. Create an empty file in the /etc/system.d directory.

  2. Provide the file with a company specific name and indications of its contents.

  3. 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 System

The 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 about system recovery, see Troubleshooting System Administration Issues in Oracle Solaris 11.4.

kmdb Utility

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.

Caution  - Because the kmdb utility stops the kernel that is currently running, only use it if you are an expert user such as a kernel developer. Do not use the kmdb utility on production systems.

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.

mdb Command

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 Information

Display a high-level view of a system's memory usage.

Note that the following command uses the –-kernel option in place of the obsolescent –k option:

# mdb --kernel --unsafe-io-access
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.

Tuning Format of Tunable Parameters Descriptions

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.

Data Type

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.

When to Change

Explains why someone might want to change this value. Includes error messages or return codes.

Zone Configuration

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.

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 the attributes(7) man page.