Events Calendar

«
<
September 2010
>
»
M T W T F S S
30 31 1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 1 2 3

Select Language

Tuning IBM TSM for migration performance PDF Print E-mail
Written by Tomas Dalebjörk   
Sunday, 09 March 2008 16:03

Tuning IBM TSM for migration performance

 

This guide line will tell you how to configure TSM on AIX to improve migration performance when migrating data from disk to tape.

  1. Choosing disk vendor
  2. Disk vendor settings
  3. Host Based Adapter settings
  4. Disk settings
  5. Volume manager settings
  6. File system settings
  7. Operating system settings
  8. File settings
  9. TSM settings

1. Choosing disk vendor

Please consider that different vendors works differently on large I/O and caching.
For example:
  • EMC has a common cache for all I/O on a LUN
  • HDS has one cache for each HBA cards accessing a LUN
There is pros and cons of both types of I/O.
If you have round robin access to a LUN, the read ahead mechanism will be fooled when I/O is not coming from the same HBA card on HDS, but will be allright on EMC.
On the otherhand, if you have a global file system sharing the same resources, EMC will be fooled when next I/O is not as it thought it might be, but HDS knows that this ordered I/O is from another HBA.
  • Caching size (EMC has a fixed size 4kb x 3)
  • HDS has dynamic size
If a larger block is sent (or read) from EMC, it would not fit into the cache, and will go all the way to the disk.
In HDS it will, cause it is a dynamic shared cache among all I/O on the system.

2. Disk vendor settings

  • If you are going to stripe disks from the operating system, avoid stripe data from the same RAID group.
  • avoid mixing storage pool data and database data from the same RAID group

3. Host Based Adapter settings

  • change round robin on HDS to external round robin settings (improves performance with 25%), /usr/DynamicLinkManager/bin/dlnkmgr set -sys exrr

4. Disk settings

The default settings on block size is good enough, increasing the size would not help unless you have SANergy installed on the system. Changing queue depth would not help either on FILE sequential pool, unless you have installed TSM 5.5 or higher, and changed the TSM options (more on this later)

  • change reserve_policy to no_reserve (improves performance with 10%), chdev -l hdiskX -a reserve_policy=no_reserve
  • change queue_depth, chdev -l hdiskX -a queue_depth=8 -P
  • change max_transfer, chdev -l hdiskX -a max_transfer=0x100000 -P

5. Volume Manager settings

5.1 Volume Manager settings for database

  • Create one scalable volume group containing database disks only, mkvg tsm01vg01 hdiskX hdiskY ...
  • Create logical volumes for databases (4GB each) use max spread, mkly -e x -y tsm01D01 tsmv01vg01 hdiskX hdiskY
  • Create one logical volume for transaction log, mklv -y tsm01L01 tsm01vg01 hdiskZ

5.2 Volume Manager settings for random disk pool

Only create random disk pool for TOC (Table of contents), such as file and directory informations, NDMP, etc.

  • Create scalable one volume group containing random disk pool data only mkvg tsm01vg02 hdiskX hdiskY ...
  • Create logical volumes for the storage pool (4GB each) use max spread, mkly -e x -y tsm01A01 tsm01vg02 hdiskX hdiskY

5.3 Volume Manager settings for sequential access (FILE) pool

To improve performance it is advisable to use device type FILE for primary storage pools in TSM. This will improve the performance with more than 300%. Reason for the improvements is that both the operating system and the disk vendor will do more read ahead in the background.

  • Create one volume group containing the sequential disk pool, mkvg tsm01vg03 hdiskX hdiskY ...
  • Create one logical volume with type jfs2, mkly -y tsm01A02 tsm01vg03 hdiskX hdiskY

6. File system settings

Studies has shown that the journal log can in some cases degrade performance, so it is advisable to create separate journal logs for the file systems.

  • Create file system with online log (with striping if possible), mkfs -V jfs2 -l /tsm01/stg/primary -o log=INLINE -o logsize=256 -t jfs -x online /dev/tsm01A02

7. Operating system settings

To avoid the operating system to occupy all the memory for file system cache, it is recommended to decrease the default settings.

  • decrease the max memory for file system cache, vmo -p -o maxperm%=20
  • decrease the max memory for file system cache, vmo -p -o maxclient%=20
  • decrease the min memory for file system cache, vmo -p -o minperm%=5

8. File settings

Avoid fragmentations as far as it is possible. Create the files for the sequential access storage pool manually, do not let TSM create the files when needed if your platform is AIX.

Formula for size of file:

<file system size> / ( <resource utilization> x <clients> ) = <average size>

  • Create the files for the sequential access pool (primary), dsmfmt -g -data /tsm01/stg/primary/v001.dsm <average size>
  • Check that the files are not fragmented, fileplace -pv /tsm01/stg/primary/v001.dsm

9. TSM settings

Use device type FILE for primary pool, use DISK for TOC (Table of Content) data pool. The block size will be 256k for each I/O instead of default 4k.

9.1 TSM settings for the primary pool

  • tsm> def devclass file devt=file
  • tsm> def stg primary file
  • tsm> def v primary /tsm01/stg/primary/v001.dsm

9.2 TSM settings for the TOC pool

  • tsm> def devclass toc devt=disk
  • tsm> def stg toc toc
  • tsm> def v toc /dev/rtsm01A01

10. Mount options

Avoid to update unnecceary informations, such as ATIME, DIRTIME.

10.1 Mount options

  • mount -o noatime /dev/tsm01A02 /tsm01/stg/primary

 
Last Updated on Sunday, 16 May 2010 08:58
 
Repostor : Your recovery expert