Hi,
i will share our values for expiration and dbbackup performance.
The comparison with Chistos values look like :-(
AIX 5.1
TSM-Server 5.1.9.3 (P630 , 4 GB Ram, 4 CPU)
TSM-DB 41 GB 67% Utilization on EMC-DMX 801
IBM 3584 with 10 LTO2
tsm: SWX00306>run db_backup_perf
ACTIVITY Date Pages backed Up/Hr
------------------ ---------- ---------------------------------
FULL_DBBACKUP 2004-09-06 4896000
FULL_DBBACKUP 2004-09-06 5965200
FULL_DBBACKUP 2004-09-07 6667200
FULL_DBBACKUP 2004-09-07 6490800
FULL_DBBACKUP 2004-09-08 6004800
FULL_DBBACKUP 2004-09-08 6609600
FULL_DBBACKUP 2004-09-09 5886000
FULL_DBBACKUP 2004-09-09 7081200
FULL_DBBACKUP 2004-09-09 5644800
FULL_DBBACKUP 2004-09-09 5569200
FULL_DBBACKUP 2004-09-10 7462800
FULL_DBBACKUP 2004-09-10 4885200
FULL_DBBACKUP 2004-09-11 6534000
FULL_DBBACKUP 2004-09-11 8168400
FULL_DBBACKUP 2004-09-11 7196400
FULL_DBBACKUP 2004-09-11 5486400
FULL_DBBACKUP 2004-09-12 7153200
FULL_DBBACKUP 2004-09-12 5378400
FULL_DBBACKUP 2004-09-12 3402000
FULL_DBBACKUP 2004-09-13 7628400
ANR1462I RUN: Command script DB_BACKUP_PERF completed successfully.
tsm: SWX00306>run expiration_perf
ACTIVITY Date Objects Examined Up/Hr
------------------ ---------- ---------------------------------
EXPIRATION 2004-09-06 277200
EXPIRATION 2004-09-07 349200
EXPIRATION 2004-09-08 97200
EXPIRATION 2004-09-09 334800
EXPIRATION 2004-09-10 356400
EXPIRATION 2004-09-11 338400
EXPIRATION 2004-09-12 244800
ANR1462I RUN: Command script EXPIRATION_PERF completed successfully.
Regards
Michael Garnebode
Diplom-Informatiker
Systemberater
Schmitz RZ Consult
Gesellschaft für DV-Beratung und Projektmanagement mbH
Im Blumersfeld 22
50259 Pulheim
Tel.: +49 (0) 2238/922266
Fax: +49 (0) 2238/922267
EMail: garnebode AT schmitz-rz-consult DOT de
-----Ursprüngliche Nachricht-----
Von: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] Im Auftrag
von Christo Heuer
Gesendet: Montag, 13. September 2004 09:13
An: ADSM-L AT VM.MARIST DOT EDU
Betreff: 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 disclaimer AT absa.co DOT za and we
will send you a copy of the Disclaimer.
|