Our TSM setup is not nearly as large as most of yours, but for what it's worth, here are our values for the past month:
FULL_DBBACKUP 2004-08-14 6537600 FULL_DBBACKUP 2004-08-15 6051600 FULL_DBBACKUP 2004-08-16 6303600 FULL_DBBACKUP 2004-08-17 5511600 FULL_DBBACKUP 2004-08-17 12970800 FULL_DBBACKUP 2004-08-18 6739200 FULL_DBBACKUP 2004-08-19 7081200 FULL_DBBACKUP 2004-08-20 7657200 FULL_DBBACKUP 2004-08-21 7927200 FULL_DBBACKUP 2004-08-22 7945200 FULL_DBBACKUP 2004-08-23 5875200 FULL_DBBACKUP 2004-08-24 6343200 FULL_DBBACKUP 2004-08-25 7992000 FULL_DBBACKUP 2004-08-26 5904000 FULL_DBBACKUP 2004-08-27 8514000 FULL_DBBACKUP 2004-08-28 7419600 FULL_DBBACKUP 2004-08-29 5922000 FULL_DBBACKUP 2004-08-30 6379200 FULL_DBBACKUP 2004-08-31 7578000 FULL_DBBACKUP 2004-09-01 8089200 FULL_DBBACKUP 2004-09-02 7473600 FULL_DBBACKUP 2004-09-03 5533200 FULL_DBBACKUP 2004-09-04 5644800 FULL_DBBACKUP 2004-09-05 8298000 FULL_DBBACKUP 2004-09-06 6627600 FULL_DBBACKUP 2004-09-07 6937200 FULL_DBBACKUP 2004-09-08 6778800 FULL_DBBACKUP 2004-09-09 8236800 FULL_DBBACKUP 2004-09-10 8859600 FULL_DBBACKUP 2004-09-11 8974800 FULL_DBBACKUP 2004-09-12 5958000 FULL_DBBACKUP 2004-09-13 8762400 EXPIRATION 2004-08-14 9637200 EXPIRATION 2004-08-15 20984400 EXPIRATION 2004-08-16 8056800 EXPIRATION 2004-08-17 19476000 EXPIRATION 2004-08-18 7131600 EXPIRATION 2004-08-19 18943200 EXPIRATION 2004-08-20 14011200 EXPIRATION 2004-08-21 13417200 EXPIRATION 2004-08-22 10011600 EXPIRATION 2004-08-23 20188800 EXPIRATION 2004-08-24 19026000 EXPIRATION 2004-08-25 17978400 EXPIRATION 2004-08-26 13017600 EXPIRATION 2004-08-27 12211200 EXPIRATION 2004-08-28 8910000 EXPIRATION 2004-08-29 15472800 EXPIRATION 2004-08-30 19191600 EXPIRATION 2004-08-31 17380800 EXPIRATION 2004-09-01 11451600 EXPIRATION 2004-09-02 11592000 EXPIRATION 2004-09-03 11980800 EXPIRATION 2004-09-04 12006000 EXPIRATION 2004-09-05 12412800 EXPIRATION 2004-09-06 13010400 EXPIRATION 2004-09-07 18284400 EXPIRATION 2004-09-08 14076000 EXPIRATION 2004-09-09 12236400 EXPIRATION 2004-09-10 12283200 EXPIRATION 2004-09-11 10602000 EXPIRATION 2004-09-12 12808800 RedHat Enterprise Linux 3.2.3-34 SMP TSM 5.2.2.4 IBM x335 Dual 2GHz Intel Xeon 2.5GB RAM DB Size 3G (65% util - 99.7% Hit ratio) on mirrored 36G 15k disk volume L3583-36 w/2 LTO-1 drives (dedicated FC HBA through SAN) I think cache hit ratio would have a pretty strong correlation to expiration performance... (having a database that's relatively tiny doesn't hurt either ;-) Ken Mueller Magna Carta Companies -----Original Message----- From: Christo Heuer [mailto:[EMAIL PROTECTED] Sent: Monday, September 13, 2004 3:13 AM To: [EMAIL PROTECTED] Subject: Re: Expiration performance Hi Ben, I agree with you on these points - ran Dave's script on our main TSM server - and the Database backup performance is exceptionally good - the slowest I'm seeing is 31000000: FULL_DBBACKUP 2004-09-03 62625600 FULL_DBBACKUP 2004-09-04 56156400 FULL_DBBACKUP 2004-09-05 59911200 FULL_DBBACKUP 2004-09-06 51152400 FULL_DBBACKUP 2004-09-07 57801600 FULL_DBBACKUP 2004-09-08 60886800 FULL_DBBACKUP 2004-09-09 52707600 FULL_DBBACKUP 2004-09-10 59018400 FULL_DBBACKUP 2004-09-11 57938400 FULL_DBBACKUP 2004-09-12 58968000 The average seems to be in the region of 50000000 +, so from that point of view it seems excellent - but the expiration sucks according to the script. ACTIVITY Date Objects Examined Up/Hr ------------------ ---------- --------------------------------- EXPIRATION 2004-08-14 856800 EXPIRATION 2004-08-14 867600 EXPIRATION 2004-08-15 864000 EXPIRATION 2004-08-17 770400 EXPIRATION 2004-08-18 669600 EXPIRATION 2004-08-19 846000 EXPIRATION 2004-08-20 734400 So, yes, it seems that Ymmv, but is there anyone out there getting good performance from expiration? If there are people out there, don't you want to share your environment with us - might be able to collectively cast some light on the lower expiration figures. For the record, my environment is as follows: AIX 5.2 TSM 5.2.2.5 DB size 105Gig - 93% utilized - 13 Lun's (One over the recommendation). Disk subsys - FastT900 File system - RLV Tape technology: 3584 with Lto-2 drives. P650 (4 Processors and 4Gig Ram) Regards ChristoH =================================================================== 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 ______________________________________________________ Important Notice: Important restrictions, qualifications and disclaimers ("the Disclaimer") apply to this email. To read this click on the following address: http://www.absa.co.za/ABSA/EMail_Disclaimer The Disclaimer forms part of the content of this email in terms of section 11 of the Electronic Communications and Transactions Act, 25 of 2002. If you are unable to access the Disclaimer, send a blank e-mail to [EMAIL PROTECTED] and we will send you a copy of the Disclaimer.
