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
