Deliver.db and Checkpoint/Recovery

[Joshua Van Horn]

Hi, 

We recently encountered a problem with our Cyrus installation involving
the checkpoint/recovery of the deliver.db file.

We are running Cyrus 2.3.8 on Solaris 10.  The server houses about
28,000 users, with a large volume of email.  After our latest round of
patching, we ended up removing the existing deliver.db database
(skiplist).  This didn't seem to be a problem at the time.

Shortly thereafter, we noted that several lmtpd processes would run a
checkpoint/recovery of the deliver.db database.  This happens every time
the database doubles in size (which is quite often when starting from
0).  This wouldn't be an issue, except that mail delivery stops while
this process is going on.  Also, instead of one instance of lmtpd
performing this action, anywhere from 1 to all of the currently running
lmtpd processes will do this in succession.  This can prevent mail
delivery for up to an hour (the database is still small ... around 40 MB
now).

I am wondering if anyone has experienced this issue and how they dealt
with it?  Since we don't use duplicate suppression, we are looking at
the possibility of patching the code to prevent the deliver.db from
being check-pointed automatically.  Another possibility is to change the
code to only allow checkpoints to be done during the evening hours.

Thoughts?

Thanks,

 

Joshua Van Horn
Data Center & Client Services
jvanhorn at ucdavis.edu
(530) 754-6699