ctl_cyrusdb looping
Igor Brezac
igor at ypass.net
Tue Jun 17 11:58:35 EDT 2003
On Tue, 17 Jun 2003, Jure Pecar wrote:
> On Tue, 17 Jun 2003 10:54:06 -0400 (EDT)
> Rob Siemborski <rjs3 at andrew.cmu.edu> wrote:
>
>
> > 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).
> >
> > 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.
> >
> > -Rob
>
> I'm seeing the same on my 2.2.0a here ... deliverdb is now at 826mb, i
> have checkpoint event set with period=10 and i find one or two ctl_deliver
> processes running, eating all the cputime available. strace shows it's
> chewing the db files as it should ... Maybe i should experiment with -E 2
> or even 1 ...
Are you using db 4.1.25? If so, apply master/service(-thread).c patches.
It will speedup checkpointing as well as duplicated|tls db pruning.
> What are the consequences of removing deliver.db? As i understand, nothing
> critical.
>
> Killing ctl_deliver usualy results in a lmtp hang and cyrus restart is
> needed to recover.
>
> I think it would be smart for ctl_deliver to check if some other
> ctl_deliver process is already running ...
>
> --
>
> Jure Pecar
>
--
Igor
More information about the Info-cyrus
mailing list