|
|
The virtual disk driver has a number of tunable kernel parameters which affect the behavior of arrays. These parameters are listed in ``Virtual disks''.
The vdisk driver collects a number of statistics to help you tune the values of these parameters. Use the -Tp options to dkconfig(ADM) to view these statistics.
In this example, dkconfig is used to examine these statistics for the virtual disk array /dev/dsk/vdisk3:
Global Virtual Disk Buffer Pool
Maximum number of buffer headers 306
Number of free buffer headers 216
Global Virtual Disk Job Pool
Maximum number of jobs 200
Number of free jobs 177
Limits for each redundant virtual disk
Maximum number of jobs 100
Maximum number of piece pool entries 100
Maximum number of async writes 20
Total number of hash table entries 256
/dev/dsk/vdisk3:
Number of free jobs 57
Number of free piece pool entries 57
Number of async writes 5
Number of async sleeps 1
Number of hash table tests 2005571
Number of hash table sleeps 124824
The statistics show:
The vdisk driver maintains its own pool of buffer headers independently of the buffer cache. When it requires a buffer header and one is not available in the buffer pool, the kernel dynamically allocates another 16KB of memory for buffer headers. It does not deallocate this memory since the buffer headers can be reused. Each buffer header requires 214 bytes of memory. In the example above, the vdisk driver is using 64KB of memory for buffer headers.
There are no kernel parameters that control the size of the buffer pool.
In practice, its size depends on the number of virtual disks and
VDUNITJOBS (the maximum number of job structures that
can be allocated to each virtual disk).
When the vdisk driver is initialized, it allocates memory to
the job structures in the job pool that is shared by
all the system's virtual disks.
The maximum number of available job structures is controlled by the
VDJOBS kernel parameter. If the system runs out of
free job structures,
the vdisk driver will report ``vdisk - job pool is empty''
on the console.
A process requiring a job structure will sleep until one becomes
available.
The vdisk driver restricts the number of job structures
that a virtual disk can use. This is to ensure that the virtual disks
have an equal share of the job pool.
If no more jobs are available, the driver
reports ``vdisk - job queue is full''. A process requiring a job
will sleep until one becomes available.
The maximum number of job structures per virtual disk is controlled by the kernel parameter VDUNITJOBS. The output from dkconfig -Tp shows the current number of free job structures for each virtual disk. If this value is near 0, increase the value of VDUNITJOBS.
When a virtual disk is configured, the vdisk driver allocates memory to be used for the virtual disk's piece pool. A piece pool entry contains a piece structure for each virtual disk. Since a piece pool entry may be needed for each for each job structure, the kernel parameter VDUNITJOBS also defines the number of entries in each virtual disk's piece pool. If a virtual disk's piece pool becomes exhausted, the driver reports ``vdisk - piece pool is empty''. A process requiring an entry from the piece pool will then sleep until one becomes available.
The output from dkconfig -Tp shows the current number of free piece pool entries for each disk piece. If this number is consistently near 0, increase the value of VDUNITJOBS.
The vdisk driver maintains a count of the outstanding asynchronous writes for each virtual disk. If this count exceeds the value of the kernel parameter VDASYNCMAX, processes attempting to write to the virtual disk will sleep until the count has been reduced. For each virtual disk, the output from dkconfig -Tp shows the current number of outstanding asynchronous writes and the number of times that processes had to sleep waiting for the count to be reduced. If sufficient memory is available, increase the value of VDASYNCMAX to prevent processes having to sleep.
If enough system buffers are available, increasing
the value of VDASYNCMAX to 32 can increase
write performance on RAID 1 configurations.
A hash table is used to prevent more than one process accessing a given virtual disk stripe at a time. However, since each hash entry protects more than one stripe, processes may contend for a hash table entry even when they want to access different stripes and there is no danger of data corruption.
If a process tests a hash table entry and finds that another process may already be accessing a stripe, it sleeps until the entry is available. The output from dkconfig -Tp shows the number of sleeps and tests for each disk piece. If the number of sleeps is relatively high and your system is not short of memory, increase the value of the VDHASHMAX kernel parameter to reduce contention for hash table entries. If there is no appreciable decrease in the ratio of sleeps to tests, it is likely that the applications using the virtual disks are contending for the same stripes.
The size of each hash table entry is 24 bytes so that the default hash table size of 1024 entries requires 24KB of memory.