On Tue, 17 Jun 2003, Jure Pecar wrote: > On Tue, 17 Jun 2003 10:54:06 -0400 (EDT) > Rob Siemborski <[EMAIL PROTECTED]> 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