|
|
Adjusting these parameters can have a significant impact on system performance, both positive and negative. Think carefully about the way your computer is used, analyze its current performance, and consider other performance factors (such as filesystem organization, sticky bits, $PATH efficiency, and filesystem block sizes) before tuning the kernel.
Kernel parameters affect the settings of various system tables. The default parameter values are acceptable for most configurations and applications. If your application has special performance needs, you might have to experiment with different combinations of parameter values to find an optimal set. For changes to the kernel parameters to be effective, the system kernel must be rebuilt and the system rebooted.
The ADT_BSIZE parameter controls the size, in bytes, of an audit buffer. If you have auditing turned on, a large audit buffer can improve system performance by allowing you to store more data in main memory and reduce the number of disk writes. However, an overly large audit buffer can use space required for other data structures and reduce performance.
The MAXCLSYSPRI parameter specifies the maximum global priority used by the SYS scheduling class for scheduling kernel processes. Changing this parameter changes the range of priorities used to schedule kernel processes and can have a significant effect on the performance of the system. In general, there is no need to change this parameter unless you add new scheduling classes or reconfigure the priorities of other currently configured classes.
SEGKMEM_BYTES, SEGKMEM_PERCENT, SEGKVN_BYTES, and SEGKVN_PERCENT, along with DRV_SEGKMEM_BYTES, UVIRT_EXTENSION and the size of general purpose memory, control the size of the kpgseg (segkvn) kernel virtual segment. (kpgseg and segkvn are both valid names for the same virtual segment.) This segment is used by the kernel memory allocator for all of its memory, by the hardware address translation layer (HAT) for its L1 page tables, and by various drivers for both temporary and permanent mappings. It is also used by the kernel to map ublocks and loadable modules. If kpgseg (segkvn) is too small, performance might decrease because of an increased cost for allocating kernel virtual space. Also, performance might decrease on a multiprocessing system due to an increased requirement for TLB (Translation Lookaside Buffer) shootdown. In some cases driver modules might not load. Moreover, in extreme cases, the system or some LWPs could hang because of a wait for kernel virtual space that is not available. Under any of these circumstances, you may want to increase kpgseg (segkvn) virtual space. Conversely, if kpgseg (segkvn) is underutilized, you might want to decrease its size to save some of the physical memory needed to support kernel virtual.
The SEGMAP_BYTES and SEGMAP_PERCENT determine the amount of virtual address space available for kernel mapping of user read and write requests. If segkmap is too small for the load, local file or remote NFS performance can suffer. Conversely, if segkmap is underutilized, and more kernel virtual space is required in another kernel virtual segment, then it might be advisable to decrease the size of segkmap.
On a machine running a database application where raw partitions are being used instead of files, the space for SEGMAP can be reduced to leave room for the application. One sign that this would be useful is excessive paging.
The parameters SEGMAP_AGE_TIME and SEGMAP_AGINGS control the rate at which segkmap unloads the translations for mappings that it is caching (and thereby freeing the pages). The effect of slowing down segkmap aging is to increase aspects of filesystem performance (as mentioned in ``Adjusting filesystem parameters'' ), but at the expense of decreased available memory for other uses (for example, for process pages).
As physical memory size increases beyond 1GB the default tuning can no longer be met due to the constraints on 1GB of kernel virtual. Therefore, you might need to monitor the balance between segments (that is, monitor the workload). Also, be aware of UVIRT_EXTENSION because it interacts strongly.