I just went thru the process of changing the interval for expire processing.
Initially, we ran it daily, then every other day... now we're running it
weekly. I can't find any of the stats I was keeping right now but I do
remember that the elapsed time for expire processing doesn't go up
exponentially. For instance, in Andy's case, where expire processing runs
2-3 hours a day, if he were to change to running it weekly, this doesn't
mean it'll now run 14-21 hours (2-3 x 7) . It would take longer, however
(8-12 hours would be my guess).
I guess this ends up being a trade off between the additional CPU overhead
of running it daily versus a slight increase in the size of the ADSM
database. Another factor in our decision to try to run it weekly was that
expire processing interferes with client level restores, especially when
you're trying to do a restore for a client at the same time expire
processing is running against that client.
Tim Pittson
pittson1 AT bwmail1.hcc DOT com
----------
From: owner-adsm-l
To: Multiple recipients of list ADSM-L
Subject: Re: Expire processing requirements
Date: Tuesday, December 05, 1995 6:44PM
Mark Stevens answered:
> On Dec 5, 4:35pm Andy Raibeck said:
> >Tim Pittson says:
> >
> >> A couple of options to improve expire processing
> >>
> >> 1) Allow multiple expire processes to run at the same time (same as
> >> migration)
> >>
> >> 2) Allow expire processing to be restartable from the node it left off
at.
> >> For instance, we try to run expire processing only once a week. Since
we
> >> usually shutdown ADSM to back it up daily, it doesn't finish within 24
hour
s
> >>
> >> so we end up having to run it again the next day. Would be nice if we
coul
d
> >>
> >> take some sort of checkpoint before shutting down, then have ADSM
restart
> >> expire processing from the node it left off at.
> >>
> >> 3) Provide the ability to control and schedule expire processing by
either
> >> policy domain or nodename.
> >
> >I agree with #1.
> >
> >#2 isn't a bad requirement, but why not run expiration processing daily?
> >It'll cut down on the duration of each execution.
>
> Some people can't run daily because expiration processing takes more
> than 24 hours, though this could be alleviated with #1.
>
> >Not sure why I'd want #3. Why would I want to expire some clients' data,
but
> >not others? I don't see this as a client-level function so much as an
overall
> >ADSM housekeeping function.
>
> #3 is probably to address tuning (expiration runs too long) issues.
> Tim? If you could run expiration processes more quickly or more of
> them, then #3 may not be needed. With #3 you could manually balance the
> load of expiration processes, but I don't think that's something I
> would want to do.
Anyone have experience with playing with duration between expiration runs?
I usually run it daily, and it runs for around 2 - 3 hours. I seem to
remember one time when it didn't run for several days. Then when it *did*
run, it took a heck of a lot longer than 2 - 3 hours. Am I imagining things?
This is why I suggested that maybe running it daily would reduce the time it
takes per run. I'd appreciate hearing from anyone else who might clarify
this.
I suspect that the reason a lot of the long-running functions (expiration,
audit license, startup of the schedule manager, etc.) is because of the time
it takes to access the database. It'd be nice if IBM would do something to
tune that puppy up - if anything can be done. I'm not a database expert, so
I'm not sure if this is a price you pay for any kind of relational database.
Andy Raibeck
Connecticut Mutual
203-987-3521
|
