I might as well chime in with my results -- ANR0984I Process 1120 for EXPIRE INVENTORY started in the BACKGROUND at 12:01:26 ANR0812I Inventory file expiration process 1120 completed: examined 2984588 objects, deleting 32611 backup objects, 2726 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. ANR0987I Process 1120 for EXPIRE INVENTORY running in the BACKGROUND processed 35337 items with a completion state of SUCCESS at 12:17:25.
Or 3,112 objects per second. Environment -- 4-way 660-6M1, fiber-channel access to two ESS raid arrays with the database software mirrored by TSM between them (yes, I'm paranoid). Using SDD to load-balance I/O over 3 fibers to six logical drives (three from each array). TSM 4.2.1.13, AIX 4.3.3 ML 10. Tom Kauffman NIBCO, Inc > -----Original Message----- > From: Loon, E.J. van - SPLXM [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, September 11, 2002 6:03 AM > To: [EMAIL PROTECTED] > Subject: Re: Expiration processing: There are many fixes in this area > > > Hi Paul and Miles! > Thanks for replying! I was impressed by your figures Miles! > 1260 objects per > second, wow! I don't know much about UNIX hardware so I don't > know what a > 6h1 is, but it must be a lot faster that a H70. > I will plan a upgrade to 4.2.2.12 next week, let's see if that helps. > For now, I will wait with 5.1, from experience I'm always a > bit afraid for > TSM maintenance level 1 software. I will upgrade to 5.1 as > soon as 5.1.2.0 > becomes available though. > Kindest regards, > Eric van Loon > KLM Royal Dutch Airlines > > > -----Original Message----- > From: Seay, Paul [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, September 11, 2002 04:12 > To: [EMAIL PROTECTED] > Subject: Re: Expiration processing: There are many fixes in this area > > > During backups and a maxed out system I fired up an > expiration to see what > my worse rate is. It was an average of 187 objects a second. > Cache hit > rate was only 95.7 during this time. So, yes, you have a > problem, and I > think I know what it is. Until you get to 4.2.2.7, and > really higher or > 5.1.1.4 if V5 there are some nasty expiration locking > problems. You may > want to consider getting on 4.2.2.12 or 5.1.1.4 depending on > your situation. > > Paul D. Seay, Jr. > Technical Specialist > Naptheon Inc. > 757-688-8180 > > > -----Original Message----- > From: Loon, E.J. van - SPLXM [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, September 10, 2002 4:49 AM > To: [EMAIL PROTECTED] > Subject: Expiration processing > > > Hi *SM-ers! > Last week I read about Rodney Clark doing a 400 objects a > second expiration. > I checked my expiration process: it's inspecting about 20 > objects a second. > Ok, maybe he has got faster hardware, but 20 times faster? I have TSM > 4.2.2.0 running on a H70 with the database on raw logical > volumes (36 Gb. > 10K rpm SSA disks, TSM mirroring). My database cache hit is > 98.53%. I was > hoping that some people out there (with somewhat similar > setup) could share > their expiration performance with me. Does anybody have some > tips? Where > should I start troubleshooting? Thank you very much in > advance for your > reply! Kindest regards, Eric van Loon KLM Royal Dutch Airlines > > > ********************************************************************** > 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. > ********************************************************************** >
