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:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Sung Y Lee
Sent: Friday, September 10, 2004 10:27 AM
To: ADSM-L AT VM.MARIST DOT EDU
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
<JCrnjanski@INFIN
ITYNETWORK.COM> To
Sent by: "ADSM: ADSM-L AT VM.MARIST DOT EDU
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:throuda AT HTD DOT CZ]
Sent: Friday, September 10, 2004 5:10 AM
To: ADSM-L AT VM.MARIST DOT EDU
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
throuda AT htd DOT cz
|