Yes, I've notice that reclamation is much slower on
a co-located tape pool that on a non co-located tape pool.

Doug Thorneycroft
Systems Analyst
Computer Technology Section
County Sanitation Districts of Los Angeles County
(562) 699-7411 Ext. 1058
FAX (562) 699-6756
dthorneycroft AT lacsd DOT org



-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Matthew Glanville
Sent: Friday, June 03, 2005 12:30 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Testing TSM 5.3, writes to pools that are collocated extremly
slow


I'm running TSM on Solaris 9, version 5.3.1.2 and have experienced an
extreme slowdown in performance when writing data to any collocate
sequential storage pool. FILE or tape.

Server setings:
movebatchsize=1000, txngroupmax=2048, movesizethresh=2048

This happens both with client backups, pool migrations and move data's
within the same pool.
However, if a very large file is being written, it streams well for the
duration of that large file.
The slowdown has something to do with a pause between each batch of small
files.

Here's some stat's around this.

random disk pool -> Collocate=filespace pool performance
3:20pm  up 9 day(s),  1:43,  3 users,  load average: 1.47, 1.32, 0.99
   r/s    w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b device
    6.2    0.0 1587.2    0.0  0.0  0.6    0.0   97.9   0   6 sd144

I just updated tape pool collocate=no and waited a minute and we have fast
write speed again.
3:23pm  up 9 day(s),  1:46,  3 users,  load average: 0.65, 1.03, 1.24
  r/s    w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b device
 171.8    0.0 41541.9    0.0  0.0  0.7    0.0    4.0   0  67 sd144

Notice the higher cpu load as well.
no other processes were running in TSM or on host during this.

Has anyone else seen this?  Is it a 5.3 issue or maybe 5.3.1.2?

I placed a call in, seems they are swamped today with other calls at IBM
Tivoli HQ.

Thanks
  Matt G.