>>
>> My suggestion would be to switch to skiplist and get rid of those
>> "lockers". I never heard anyone complaining after switching to skiplist.
>> The listarchives can tell you more about it.
>>
>> Regards,
>> Simon
>>
>
> As far as I know I did switch to skiplist. I upgraded to 2.3 from a 2.1
> install and one of the steps was:
>
> rm -f /var/imap/db/*
> cp /var/imap/mailboxes.db /var/imap/mailboxes.db.old
> cvt_cyrusdb /var/imap/mailboxes.db berkeley /var/imap/mailboxes.db.new
> skiplist
> mv /var/imap/mailboxes.db.new /var/imap/mailboxes.db
> rm -f /var/imap/db/*
> touch /var/imap/db/skipstamp
> chown -R cyrus:other /var/imap
> for fl in `find /var/imap/user name \*.seen`; do
> /usr/cyrus/bin/cvt_cyrusdb $fl flat ${fl}.new skiplist; mv ${fl}.new
> $fl; done
>
> Is there something besides mailboxes.db and the user .seen files that
I'm quite sure in your case the problem is with duplicate_db (deliver.db).
Otherwise you wouldn't see those locker errors because they are not coming
from skiplist. So I suggest to convert deliver.db the same way to
skiplist.
> should be converted? Also, the load on the box in terms of connections
> and messages is roughly equivalent as other days when this doesn't
> happen. I looked through postfix and I noticed these errors:
>
> Jul 15 08:10:58 ssmail postfix/lmtp[23685]: [ID 197553 mail.info]
> 10C722DB6E0: to=<xxxxxxx@xxxxxxxxxxx>,
> relay=cpimail.cpicorp.com[/var/imap/socket/lmtp], delay=29096,
> delays=19403/5509/3583/600, dsn=4.4.2, status=deferred (conversation
> with cpimail.cpicorp.com[/var/imap/socket/lmtp] timed out while sending
> end of data -- message may be sent more than once)
>
> Jul 15 08:10:58 ssmail postfix/lmtp[23915]: [ID 197553 mail.info]
> 1D1AA2DB845: to=<s41270@xxxxxxxxxxxxxxxxxxx>,
> relay=cpimail.cpicorp.com[/var/imap/socket/lmtp], delay=29038,
> delays=19345/6092/3001/600, dsn=4.4.2, status=deferred (conversation
> with cpimail.cpicorp.com[/var/imap/socket/lmtp] timed out while sending
> end of data -- message may be sent more than once)
>
> Postfix is configured with a hard limit of 10 concurrent lmtp processes.
> Is that too high? If it happens again, does anyone have some dtrace
> scripts for figuring out what lmtpd is doing?
I don't even remember how I configured the postfix limits on larger
systems but 10 concurrent lmtp connections doesn't seem bad. I'm quite
sure that should not be a problem.
Simon
----
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
