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 [EMAIL PROTECTED] -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of Matthew Glanville Sent: Friday, June 03, 2005 12:30 PM To: [email protected] 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.
