[Dovecot] 1.0rc8 status report
David Lee
t.d.lee at durham.ac.uk
Wed Oct 11 15:54:59 UTC 2006
A quick status report on how 1.0rc8 behaved in service for a few hours
with several hundred simultaneous users, at a site very new to dovecot.
Oh, and a question at the end.
Summary: Reasonable for a first shot but one significant problem,
requiring backing off.
Background:
We have a long-established UW-IMAP service for a user population of about
20,000 based on a few Linux (Redhat) machines running IMAP/POP and inbound
delivery. We try to ensure, but cannot guarantee, that all activity for a
given user takes place within one machine. Each machine mounts the INBOX
area ("/var/spool/mail"; traditional UNIX mbox) via NFS with tight NFS
arguments ("noac,actimeo=0", etc.) and similarly mounts the users' folder
areas which are subdirs of their home directories. (We know that Mark
Crispin recommends against NFS for UW-IMAP, but we seem to have been OK.)
There is also some processing: .forward->"| procmail"->folder-or-inbox
Each machine typically has several hundred simultaneous IMAP connections.
This has basically worked well, but the UW-IMAP loading has been heavy.
The plan:
In an ideal world, I would like to restructure the above. But our world
is not ideal, so we have to stay with the structure. But we are looking
for a transparent (user perspective) migration to dovecot.
The dovecot experience:
Yesterday, I quietly adjusted a DNS entry to redirect one of the live
email hostnames at an additional machine in the "farm", running dovecot
1.0rc8, including deliver/LDA (and taking into account some post-rc7
dovecot changes in this area).
On an earlier, smaller-scale test, one problem had been some periods of
"temporary authentication failures". Increasing "login_processes_count"
and "login_max_processes_count" (each by a factor of 8) seems to have
fixed this, and I'm not aware of any problems in that area yesterday.
It basically went well. But just over two hours hours later I had to back
off, because of a significant dovecot problem, namely that dovecot
crashed, almost silently. The only traces of this event in the log file
seem to be:
Oct 10 16:26:12 [...] dovecot: child 24525 (login) returned error 89
Oct 10 16:26:14 [...] dovecot: Login process died too early - shutting down
Any thoughts? Any fixes? If the problem needs debugging (or additional
data/log collection) how might that be attempted in this environment?
--
: David Lee I.T. Service :
: Senior Systems Programmer Computer Centre :
: Durham University :
: http://www.dur.ac.uk/t.d.lee/ South Road :
: Durham DH1 3LE :
: Phone: +44 191 334 2752 U.K. :
More information about the dovecot
mailing list