Previous  |  Next  >  
Product: File System Guides   
Manual: File System 4.1 Administrator's Guide   

Kernel Tunables

This section describes the kernel tunable parameters in VxFS.

Internal Inode Table Size

VxFS caches inodes in an inode table. There is a dynamic tunable in VxFS called vx_ninode that determines the number of entries in the inode table.

You can dynamically change the value of vx_ninode by using the sam or kctune commands (see the sam(1M) and kctune(1M) manual pages). This value is used to determine the number of entries in the VxFS inode table. By default, vx_ninode initializes at zero; the file system then computes a value based on the system memory size.

A VxFS file system can also obtain the value of vx_ninode from the system configuration file used for making the HP-UX kernel (/stand/system for example). To change the computed value of vx_ninode, you can add an entry to the system configuration file. For example:


 tunable vx_ninode 1000000

This sets the inode table size to 1,000,000 inodes after making a new HP-UX kernel using mk_kernel.

Increasing the value of vx_ninode increases the inode table size immediately, allowing a higher number of inodes to be cached. Decreasing the value of vx_ninode decreases the inode table size to the specified value. After the tunable is decreased, VxFS attempts to free excess cached objects so that the resulting number of inodes in the table is less than or equal to the specified value of vx_ninode. If this attempt fails, the value of the vx_ninode tunable is not changed. In such a case, the kctune command can be specified with the -h option so that the new value of vx_ninode takes effect after a system reboot.

Be careful when changing the value of vx_ninode, as the value can affect file system performance. Typically, the default value determined by VxFS based on the amount of system memory ensures good system performance across a wide range of applications. However, if it is determined that the default value is not suitable, vx_ninode can be set to an appropriate value based on the expected file system usage. The vxfsstat command can be used to monitor inode cache usage and statistics to determine the optimum value of vx_ninode for the system.

Changing the value of a tunable does not resize the internal hash tables and structures of the caches. These sizes are determined at system boot up based on either the system memory size, which is the default, or the value of the tunable if explicitly set, whichever is larger. Thus, dynamically increasing the tunable to a value that is more than two times either the default value or the user-defined value, if larger, may cause performance degradation unless the system is rebooted.

Examples of Changing the vx_inode Tunable Value

The following are examples of changing the vx_ninode tunable value.

Example 1 - Reporting the Current Value of vx_ninode


 # kctune vx_ninode

This command displays the current value of vx_ninode.

Example 2 - Setting vx_ninode


 # kctune -s vx_ninode=10000

This command sets vx_ninode to 10000, the specified value.

Example 3 - Restoring vx_ninode to Its Default Value


 # kctune -s vx_ninode=

This command restores vx_ninode to its default value by clearing the user-specified value. The default value is the value determined by VxFS to be optimal based on the amount of system memory, which is used if vx_ninode is not explicitly set.

Example 4 - Delaying a Change to vx_ninode Until After a Reboot


 # kctune -h -s vx_ninode=10000

If the -h option is specified, the specified value for vx_ninode will not take effect until after a system reboot.

VxFS Buffer Cache High Water Mark

VxFS maintains its own buffer cache in the kernel for frequently accessed file system metadata. This cache is different from the HP-UX kernel buffer cache that caches file data. The vx_bc_bufhwm dynamic, global, tunable parameter lets you change the VxFS buffer cache high water mark, that is, the maximum amount of memory that can be used to cache VxFS metadata.

The initial value of vx_bc_bufhwm is zero. When the operating system reboots, VxFS sets the value of vx_bc_bufhwm based on the amount of system memory. You can explicitly reset the value of vx_bc_bufhwm by changing the value of vxfs_bc_bufhwm using the sam or kctune commands (see the sam(1M) and kctune(1M) manual pages). You can also set the value by adding an entry to the system configuration file. For example, the following entry:


 vxfs_bc_bufhwm vx_bc_bufhwm                  300000

sets the high water mark to 300 megabytes. The change takes effect after you rebuild the HP-UX kernel using the mk_kernel command. You specify the vx_bc_bufhwm tunable in units of kilobytes. The minimum value is 6144.

Increasing the value of vx_bc_bufhwm increases the VxFS buffer cache immediately, allowing a greater amount of memory to be used to cache VxFS metadata. Decreasing the value of vx_bc_bufhwm decreases the VxFS buffer cache to the specified value. This frees memory such that the amount of memory used for buffer cache is lower than the specified value of vx_bc_bufhwm.

Typically, the default value computed by VxFS based on the amount of system memory ensures good system performance across a wide range of applications. For application loads that cause frequent file system metadata changes on the system (for example, a high rate of file creation or deletion, or accessing large directories), changing the value of vx_bc_bufhwm may improve performance.

You can use the vxfsstat command to monitor buffer cache statistics and inode cache usage (see the vxfsstat(1M) manual page).

Number of Links to a File

In VxFS, the number of possible links to a file is determined by the vx_maxlink global tunable. The default value of vx_maxlink is 32767, the maximum value is 65535. This is a static tunable.

You can set the value of vx_maxlink using the sam or kctune commands (see the sam(1M) and kctune(1M) manual pages), or by adding an entry to the system configuration file as shown in the following example:


 vxfs_maxlink vx_maxlink 40000

This sets the value of vx_maxlink to 40,000 links.

VxFS Inode Free Time Lag

In VxFS, an inode is put on a freelist if it is not being used. The memory space for this unused inode can be freed if it stays on the freelist for a specified amount of time. The vx_ifree_timelag tunable specifies the minimum amount of time an unused inode spends on a freelist before its memory space is freed.

The vx_ifree_timelag tunable is dynamic. Any changes to vx_ifree_timelag take effect immediately.

The default value of vx_ifree_timelag is 0. By setting vx_ifree_timelag to 0, the inode free time lag is autotuned to 1800 seconds. Specifying negative one (-1) stops the freeing of inode space; no further inode allocations are freed until the value is changed back to a value other than negative one.

You can change the value of vx_ifree_timelag using the sam or kctune commands (see the sam(1M) and kctune(1M) manual pages), or by adding an entry to the system configuration file. The following example changes the value of vx_ifree_timelag to 2400 seconds:


 # kctune -s vxfs_ifree_timelag=2400
Note   Note    The default value vx_ifree_timelag typically provides optimal VxFS performance. Be careful when adjusting the tunable because incorrect tuning can adversely affect system performance.

VxVM Maximum I/O Size

When using VxFS with the VERITAS Volume Manager (VxVM), VxVM by default breaks up I/O requests larger than 256K. When using striping, to optimize performance, the file system issues I/O requests that are up to a full stripe in size. If the stripe size is larger than 256K, those requests are broken up.

See the VERITAS Volume Manager Administrator's Guide for more information on avoiding I/O breakup by setting the maximum I/O tunable parameter.

 ^ Return to Top Previous  |  Next  >  
Product: File System Guides  
Manual: File System 4.1 Administrator's Guide  
VERITAS Software Corporation
www.veritas.com