Skip Navigation Links | |
Exit Print View | |
Oracle Solaris Tunable Parameters Reference Manual Oracle Solaris 11 Express 11/10 |
1. Overview of Oracle Solaris System Tuning
2. Oracle Solaris Kernel Tunable Parameters
Where to Find Tunable Parameter Information
General Kernel and Memory Parameters
fsflush and Related Parameters
General File System Parameters
sun4u or sun4v Specific Parameters
4. Internet Protocol Suite Tunable Parameters
5. Network Cache and Accelerator Tunable Parameters
A. Tunable Parameters Change History
The Solaris kernel memory allocator distributes chunks of memory for use by clients inside the kernel. The allocator creates a number of caches of varying size for use by its clients. Clients can also request the allocator to create a cache for use by that client (for example, to allocate structures of a particular size). Statistics about each cache that the allocator manages can be seen by using the kstat -c kmem_cache command.
Occasionally, systems might panic because of memory corruption. The kernel memory allocator supports a debugging interface (a set of flags), that performs various integrity checks on the buffers. The kernel memory allocator also collects information on the allocators. The integrity checks provide the opportunity to detect errors closer to where they actually occurred. The collected information provides additional data for support people when they try to ascertain the reason for the panic.
Use of the flags incurs additional overhead and memory usage during system operations. The flags should only be used when a memory corruption problem is suspected.
The Solaris kernel memory allocator has various debugging and test options that were extensively used during the internal development cycle of the Solaris OS. Starting in the Solaris 2.5 release, a subset of these options became available. They are controlled by the kmem_flags variable, which was set with a kernel debugger, and then rebooting the system. Because of issues with the timing of the instantiation of the kernel memory allocator and the parsing of the /etc/system file, it was not possible to set these flags in the /etc/system file until the Solaris 8 release.
Five supported flag settings are described here.
|
Signed integer
0 (disabled)
0 (disabled) or 1 - 15 or 256 (0x100)
Yes. Changes made during runtime only affect new kernel memory caches. After system initialization, the creation of new caches is rare.
None
When memory corruption is suspected
Unstable
If the kmem_stackinfo variable is enabled in the /etc/system file at kernel thread creation time, the kernel thread stack is filled with a specific pattern instead of filled with zeros. During kernel thread execution, this kernel thread stack pattern is progressively overwritten. A simple count from the stack top until the pattern is not found gives a high watermark value, which is the maximum kernel stack space used by a kernel thread. This mechanism allows the following features:
Compute the percentage of kernel thread stack really used (a high watermark) for current kernel threads in the system
When a kernel thread ends, the system logs the last kernel threads that have used the most of their kernel thread stacks before dying to a small circular memory buffer
Unsigned integer
0 (disabled)
0 (disabled) or 1 (enabled)
Yes
None
When you want to monitor kernel thread stack usage. Keep in mind that when kmem_stackinfo is enabled, the performance of creating and deleting kthreads is decreased. For more information, see the Chapter 5, Built-In Commands, in Oracle Solaris Modular Debugger Guide.
This parameter must be set in the global zone.
Unstable