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 ... 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
