Yes, interesting stats. On all my TSM servers, they get above 5M pages for the
DB backup, but none of them are above 3.8M objects on the expire inventory. Some in
the 2M, others only in the .5 M range.
These random thoughts pointed at the group, not necessarily Joe.
Since my db backups (sequential reads) go well, but the expire inventory
(random reads and writes) are slow, might that point to DB fragmentation? Improper
tuning of TSM buffers? Overcommittal of the fast-write disk cache? Bad karma?
One would think that the more files deleted during the expire inventory, the
longer it will take for the expire inventory to progress? No? I can run 2 expire
inventories in a row and the second one goes much much quicker because there are very
few changes to the DB to be made. It seems like the performance on the "number of
objects examined" is really one of those "your mileage may vary" kind of stats.
Perhaps I'm not getting the performance I should out of the expiration...
Ben
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Sung Y Lee
Sent: Friday, September 10, 2004 10:27 AM
To: [EMAIL PROTECTED]
Subject: Re: Expiration performance
Pretty nice scripts.
It was noted that output should be > 5 mil for 1st script and >3.8 mil
for 2nd script.
Should this be a concern if 1st script shows up > 5 mil, but the 2nd script is < 3.8
mil for the TSM server? Could this be used as bench mark to say, the faster and better
CPU and/or TSM server is needed? I know this question is very general since there are
many many factors to be consider.... I guess can or should one include this in the
sizing of the current environment?
Thanks,
Sung Y. Lee
Joe Crnjanski
<[EMAIL PROTECTED]
ITYNETWORK.COM> To
Sent by: "ADSM: [EMAIL PROTECTED]
Dist Stor cc
Manager"
<[EMAIL PROTECTED] Subject
.EDU> Re: Expiration performance
09/10/2004 12:06
PM
Please respond to
"ADSM: Dist Stor
Manager"
I have scripts to test performance. I don't remember how did I get them (maybe from
this group)
Database backup performance (result from the script should be >5,000,000)
select activity, cast ((end_time) as date) as "Date", (examined/cast
((end_time-start_time) seconds as decimal (18,13)) *3600) "Pages backed Up/Hr" from
summary where activity='FULL_DBBACKUP' and days (end_time) -days (start_time)=0
Expiration performance (result from the script should be >3,800,000)
select activity, cast ((end_time) as date) as "Date", (examined/cast
((end_time-start_time) seconds as decimal (18,13)) *3600) "Objects Examined Up/Hr"
from summary where activity='EXPIRATION' and days (end_time) -days (start_time)=0
Joe Crnjanski
Infinity Network Solutions Inc.
Phone: 416-235-0931 x26
Fax: 416-235-0265
Web: www.infinitynetwork.com
-----Original Message-----
From: Tomáš Hrouda [mailto:[EMAIL PROTECTED]
Sent: Friday, September 10, 2004 5:10 AM
To: [EMAIL PROTECTED]
Subject: Expiration performance
Hi all,
I have a question for people that are administering simillar TSM system like me. TSM
server on Sunfire 6800, 4x UltraSparcIII 1.2GHz, Solaris 5.9, Veritas VM 3.5 MP3.
Database and diskpools at HP512 disk array with 2x 2Gbit FC HBA connect. About 500 TSM
nodes including fileservers, Oracle DB, MS Exchange, MS SQL. About 800-1000GB daily
data througput. TSM DB has 54GB allocated space and about 80% utilization.
Now what is going about: there is about 4 milions examined and about 1 milion deleted
objects (average values) during expiration process, which takes about 3-4 hours every
day. This means about 15000obj/min effective speed, but I know, this value is greatly
dependent on deleted object and less on examined object. Here is last 20 days in table:
DATUM MINT EXAMINED DELETED OBJ_MIN
---------- ------ --------- --------- --------
2004-08-22 263 3398758 615560 12874.0
2004-08-23 228 3351541 612942 14635.5
2004-08-24 206 2484002 650679 12000.0
2004-08-24 28 338548 153478 11674.0
2004-08-24 41 763327 658053 18174.4
2004-08-25 239 2906026 718224 12108.4
2004-08-26 242 3054086 752255 12568.2
2004-08-27 250 3168014 846850 12621.5
2004-08-28 242 2989464 634817 12302.3
2004-08-29 263 3050878 721088 11556.3
2004-08-30 229 2887915 564426 12556.1
2004-08-31 269 3688850 850329 13662.4
2004-09-02 17 148694 124645 8260.7
2004-09-03 209 2140264 1305591 10191.7
2004-09-04 382 5130891 1520585 13396.5
2004-09-05 302 4220154 566306 13927.9
2004-09-06 253 4245286 593276 16713.7
2004-09-07 236 4193877 628473 17695.6
2004-09-08 83 824472 290712 9815.1
2004-09-09 137 2099219 410653 15211.7
2004-09-09 244 3891087 1064453 15881.9
We are monitoring whole system day by day (CPU, disk groups I/O, memory, network
...blablabla) and there is seen from these data, that CPU is largely loaded during
backups (70-90%), but not during expiration (5-10%). Database disks have average
activity about 0,5MByte/s read and 0,5Mbyte write during both backups and expiration,
and about 12Mbyte/s read during TSM database backup. But there is about 25% processing
time waiting for I/O during both backups and expiration. There is SELFTUNEBUFPOOLSIZE
activated, bufferpool is 131072 KB and last 2 months no increase was registered.
I have some other experiences on smaller TSM systems with different configurations, on
different hardware and platforms, but all these systems are much more loaded during
expiraton process than during backups. I want to ask, if somebody has system with
similar sizing in production and if these values (I mean low load affect of expiration
process) seems OK, or what si your expiriences with expirations. Am I supposed to find
some bottlenecks in filesystem/OS/TSM settings? Or is this fenomen caused by size of
TSM environment and is it normal?
Thanks for any suggestions
Tomas Hrouda
Storage Specialist
HTD s.r.o. Praha
CZECH REPUBLIC
[EMAIL PROTECTED]
