ctl_cyrusdb looping

[Jim Howell]

At 11:36 AM 6/17/2003 -0400, Rob Siemborski wrote:
>On Tue, 17 Jun 2003, Jim Howell wrote:
>
> > > > The first time through I let it run for 15 minutes, the "done" 
> message came
> > > > in 81 seconds.  Should I of let it keep going?  What can I do to 
> prevent
> > > > this from happening again?  Thanks.
> > >
> > >Most likely it was processing your duplicate delivery database, which can
> > >be quite large and take some time to process (you can generally tell what
> > >is going on by truss/strace on the process).
> >
> > We don't use the duplicate delivery feature.  Duplicate suppression is set
> > to no in the imapd.conf
>
>The duplicate delivery database is still maintained (its also used for
>things like sieve vacation).
>
>But its totally safe to delete in this circumstance.

Hi,
         Ok, the next time we restart (which will be Sunday).  I'll be sure 
we delete the deliver.db file.  Thanks for the hint.  We only just upgraded 
to 2.1.11 in the last few months and we are still discovering the little 
things.. :)  One thing I don't think I made clear, after the message 
stating the mailboxes.db had been recovered I let it run for a few minutes 
before killing the "ctl_cyrusdb -r".  Also before killing it I observed the 
looping via truss.  I'm going to do some code reading tomorrow to verify my 
thoughts..


> > >Options you have are to just delete it or to wait.  Killing the process in
> > >the middle of recovery is probably not ideal.
> > >
> > >If you're using Berkeley DB for your duplicate delivery database, you many
> > >want to look at increasing your checkpoint frequency.  This could help
> > >reduce the amount of log that needs to be played back during recovery.
> >
> > We use skiplist for the Mailboxes DB although we compiled in the duplicate
> > delivery function with db3, but like I said we don't use it.

Well I didn't realize some of the impliecations..  I do now.. :)  Thanks 
for the help I'll let you know how I make out.
Jim


>Except that you do use the database ;)
>
>One thing that might be slowing down your rebuild is if you never expire
>the entries either (via ctl_deliver).
>
>-Rob
>
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
>Research Systems Programmer * /usr/contributed Gatekeeper