We have full XIV and use 10 TB of it for TSM storage pools.  The rest of the 
XIV is allocated to an SVC for general host use and is fairly busy.  The 
default max block size of the hdisk and fibre card is sufficient as is the 
default queue depth of the fibre cards.  The default queue depth of the hdisk 
is 1 which is limiting.  I have mine set to 40.  This can only be done is you 
are at a recent enough AIX level and XIV drivers.
 

 

Orville Lantto

 

 

-----Original Message-----
From: Remco Post <r.post AT PLCS DOT NL>
To: ADSM-L AT VM.MARIST DOT EDU
Sent: Fri, Oct 1, 2010 9:01 am
Subject: Re: [ADSM-L] [adsm] TSM and XIV


On Thu, Sep 30, 2010 at 10:58 PM, Orville Lantto <olantto AT email DOT com> 
wrote:

> Could be that you are hitting the SATA IOPS limit.  Cache does not help
> much for long streaming IOs like TSM storage pools.  Since SATA has only the
> capacity for about 60 IOPS per drive, and the XIV has 180 drives.  This is
> only a maximum 10800 IOPS,  At 4 KB block size this is 42 MB/sec, in the
> neighborhood of what you are seeing.  If you can get your block size up, the
> XIV will do much better.  I have tuned my system for TSM's 256 kB block size
> and I have seen very satisfactory speeds in my disk pools.  Just today I was
> watching and the XIV storage pools were going at about 180 MB/sec, about 680
> IOPS, and  with 5 ms latency.  This on a near full XIV with only 10%
> dedicated to TSM.
>
>
>
>
>

We're doing only about 300 IOPS... the transfer block size is 1 MB. And
cache does help... all storage boxes have prefetching and for processes like
migration, these prefetching algorithms should be able to do a good job.

Also, with two migration processes, we get just twice the performance of one
process.

What is your configuration? JFS2? Raw volumes? How many drawers in the XIV?
What type of tape drive? And is the 180 MB/s just for one TSM server or for
all of them? How many processes were running at that time?

--
Met vriendelijke groeten,

Remco Post, PLCS