Sent this too fast... Must have hit the a wrong key... Not enough coffee yet
I have 4 rather large tsm servers, db over 30 gb. 2 are AIX, 2 are sun. The performance on the 2 aix boxes is similar. One server is very old, installed in 97, db is 60 db, and goes through 12 million objects, deleting between 300,000 and 1 million objects. 3000 objects/sec examined, but between 70 and 100 deleted. Expiration lasts between 60 and 90 minutes. The other aix server is brand new. Db is 40 gb, moslty du to 2 imap servers whose backups are kept 180 days (OUCH!!). Expiration goes through 150,000 objects, deleting 100,000. 200 objects examined/sec, 150 deleted. The old server is a f80, the new one a p615, soon to be a p630. As for the SUN servers, performance is nowhere near as good. I can't get more than 40 objects/second, examined or deleted. I moved the database on raw volumes, didn't help much. I can't seem to get these servers to perform well. The 2 instances are on a 480 with 2 cpu's. Disks are the same as the AIX servers (HDS 9960). Is anyone getting good expiration performance on SUN servers. If so, how are you setup? Guillaume Gilbert Backup Administrator CGI - ITM (514) 415-3000 x5091 [EMAIL PROTECTED] > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] > On Behalf Of Loon, E.J. van - SPLXM > Sent: Friday, March 26, 2004 8:23 AM > To: [EMAIL PROTECTED] > Subject: Re: Expiration after TSM upgrade from 5.1.6.4 to 5.2.2.1 > > > Hi Luke! > Just because I'm currently trying to boost expiration > processing: I see your > database is rather large, how long did it take you to expire > those 23194393 > objects? > I really tried almost everything, from moving to 15k speed > disks, multiple > database volumes, moving to RAW's, the best I have seen in my > environment is > 60 objects per second. > I posted a question some time ago (2002) where I requested for other > people's performances, Tom Kauffman was the winner at that time with a > dazzling 3112 objects per second! > Kindest regards, > Eric van Loon > KLM Royal Dutch Airlines > > > -----Original Message----- > From: Luke Dahl [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 25, 2004 21:39 > To: [EMAIL PROTECTED] > Subject: Re: Expiration after TSM upgrade from 5.1.6.4 to 5.2.2.1 > > > Hi Mark, > Output from q db f=d: > Available Space (MB): 118,780 > Assigned Capacity (MB): 70,000 > Maximum Extension (MB): 48,780 > Maximum Reduction (MB): 15,924 > Page Size (bytes): 4,096 > Total Usable Pages: 17,920,000 > Used Pages: 11,215,255 > Pct Util: 62.6 > Max. Pct Util: 77.3 > Physical Volumes: 1 > Buffer Pool Pages: 32,768 > Total Buffer Requests: 2,151,221,843 > Cache Hit Pct.: 99.04 > Cache Wait Pct.: 0.00 > Backup in Progress?: No > Type of Backup In Progress: > Incrementals Since Last Full: 0 > Changed Since Last Backup (MB): 2,785.80 > Percentage Changed: 6.36 > Last Complete Backup Date/Time: 03/24/04 17:33:13 > > This is the standard amount of expiration we see: > 03/14/04 17:27:07 ANR0812I Inventory file expiration process 1692 > completed: > examined 23194393 objects, deleting > 1690917 backup > objec > cts, 0 archive objects, 0 DB backup > volumes, and 0 > recov > very plan files. 0 errors were encountered. > > This is currently running: > Process Process Description Status > s Number > -------- -------------------- > ------------------------------------------------- > 26 Expiration Examined 22853888 objects, > deleting 20518954 > bac > ckup objects, 0 archive > objects, 0 DB backup > vo > olumes, 0 recovery plan files; 1 errors > encount > tered. > > I don't think the policies were correctly expiring data prior to the > upgrade. We've had numerous nodes that seemed to be storing > much more than > their policy dictated. We tried to force expiration on the > files and it > didn't seem to make much of a difference. Unfortunately > we've been tweaking > policies and trying to force a lot of data to drop off prior > to the upgrade > so I can't point to any particular reason why expiration is > now expiring so > much data. You can see the db size has dropped as well due to the > expiration - and we performed an unload/reload less than a > month ago prior > to the upgrade. Being the db volume is one volume it could be disk > contention, but it's a raw volume fiber attached (Sun T-3's). > > Luke > > "Stapleton, Mark" wrote: > > > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] > On Behalf Of > > Luke Dahl > > > We upgraded our TSM Server (Solaris 9) from 5.1.6.4 to > 5.2.2.1 last > > >week. Prior to the upgrade our expiration usually lasted about 24 > > hours > > >(53Gb database). It would generally post results like > this: examined > > >16446439 objects, deleting 59582 backup objects > > >Our 3494 library showed est. capacity of 60Tb and > approximately 88 pct. > > >util. > > > > What is your db's cache hit ratio? 24 hours for a 53GB database is > > manifestly too long. It should get through expiration in > 2-3 hours. Give > > us the output from Q DB F=D. > > > > >Any idea why expiration wasn't running properly prior to > the upgrade? > > >Data integrity looks good but we've just cleared out loads > of space. I > > >don't recall a known bug in expiration processing in > 5.1.6.4 but may > > >have missed something. Thanks for your thoughts and input. > > > > How, exactly, did you "clear out loads of space"? > > > > -- > > Mark Stapleton > > > ********************************************************************** > For information, services and offers, please visit our web > site: http://www.klm.com. This e-mail and any attachment may > contain confidential and privileged material intended for the > addressee only. If you are not the addressee, you are > notified that no part of the e-mail or any attachment may be > disclosed, copied or distributed, and that any other action > related to this e-mail or attachment is strictly prohibited, > and may be unlawful. If you have received this e-mail by > error, please notify the sender immediately by return e-mail, > and delete this message. Koninklijke Luchtvaart Maatschappij > NV (KLM), its subsidiaries and/or its employees shall not be > liable for the incorrect or incomplete transmission of this > e-mail or any attachments, nor responsible for any delay in receipt. > ********************************************************************** >
