IBM Tivoli Storage Manager, Version 7.1

Configuring Oracle Solaris systems for disk performance

For best performance for disks that are used for Tivoli® Storage Manager, configure the system according to a few guidelines.

Procedure

Use the latest Solaris version and release, and apply the latest kernel patch. By using the latest release, you can take advantage of the latest improvements to functions such as ZFS.
Tune the record size. The record size property specifies a suggested block size for files in the file system. This property is designed only for use with database workloads that access files in fixed-size records. Specifying a record size value greater than or equal to the record size of the database can result in significant performance gains. Changing the record size of the file system affects only files that are created after the change. Specify a number that is a power of 2, in the range of 512 bytes - 128 KB.
1. For the file system where the Tivoli Storage Manager database is stored, set the record size equal to the database page size, which is 8 - 32 KB.
  When the database page size is less than the page size of the operating system, set the record size as the page size of the operating system. Page size is 8 KB on SPARC systems and 4 KB on x64 systems.
2. For the recovery logs for the Tivoli Storage Manager server, use a distinct file system or preferably a distinct pool with the default record size of 128 KB.
Keep sufficient free space in the zpool. For the Tivoli Storage Manager database, set a quota on the zpool to ensure that 20% of the zpool space is always available. Performance can be affected when more than 80% of the zpool capacity is in use.
Use a separate, dedicated zpool for recovery log files. When you use a dedicated LUN on dedicated disks for log files, ZFS can handle the latency-sensitive log activity in priority. Dedicated LUNs help the system handle the database workload with a high transaction rate.
Set a maximum limit for the Adjustable Replacement Cache (ARC) size, which is used by ZFS to cache the data from all pools. The cache dynamically shrinks or grows based on memory usage on the system. If the server requires a large amount of memory, set a limit on the maximum size for the ARC. With the limit on the ARC size, ZFS is less likely to shrink its cache in periods of peak memory demand.
To estimate the maximum size for the ZFS ARC, complete the following calculation:
1. Add the memory usage requirements for applications that use a large amount of memory on the system.
2. From the size of the physical memory of the system, subtract the memory usage that you obtained in step 1.
3. Multiply the result of step 2 by 80%. Use this number as the value for the zfs_arc_max parameter.
For example, to limit the ARC size to 30 GB, set the zfs:zfs_arc_max parameter in the /etc/system file:
```
set zfs:zfs_arc_max = 32212254720
```
You can use the kstat command to verify the size of the ZFS cache.
For the file system where the Tivoli Storage Manager database is stored, set primarycache=metadata. The primarycache parameter controls what is cached in the ARC, and the value metadata means that the ARC is used for metadata only.
Adjust the ZFS I/O queue size. You control the I/O queue depth for a ZFS LUN with the zfs_vdev_max_pending parameter.
When there are many LUNs in a ZFS pool, and each LUN contains many physical disks, the ZFS I/O queue can limit the read operations. The ZFS I/O queue size is set to 35 by default, which means that there are 35 concurrent I/O streams per LUN. A high number of LUNs in a zpool can cause contention on the storage channel and lead to longer response times. To relieve the contention and reduce the time, you can adjust the ZFS I/O queue size dynamically.
In the following example, the queue size is reduced to 10:
```
echo zfs_vdev_max_pending/W0t10 | mdb -kw
```
You can check the average queue depth by using the iostat command and observing the number of entries in the actv and wait queues.

Feedback