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
guillaume.gilbert AT cgi DOT com
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]
> On Behalf Of Loon, E.J. van - SPLXM
> Sent: Friday, March 26, 2004 8:23 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> 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:ldahl AT JPL.NASA DOT GOV]
> Sent: Thursday, March 25, 2004 21:39
> To: ADSM-L AT VM.MARIST DOT EDU
> 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:ADSM-L AT VM.MARIST DOT EDU]
> 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.
> **********************************************************************
>
|
