cyrus perdtion , connections not dying
Ian Eiloart
iane at sussex.ac.uk
Mon Apr 7 06:12:43 EDT 2008
--On 4 April 2008 20:04:37 -0700 Robert Banz <rob at nofocus.org> wrote:
>
> Why are you using perdition, when you could be using Cyrus' "murder"
> clustering which will work to the same end, with added bonuses of
> being able to share folders between users on both servers, easier
> administration, etc.
>
> -rob
>
There are good reasons. For example, we used Perdition during migration of
users from a UoW IMAP server to Cyrus. We ran into the same problem, the
performance limitation on our front end cluster was (is) the number of
processes. They're OSX servers, and the one really annoying thing about
them is the artificially low number of processes allowed.
Now, we've completed the migration and wish to switch from Perdition to
Cyrus front ends. Unfortunately, the same problem applies. Actually, it's
worse. Cyrus processes use more RAM: typically 2.0-3.5 MB per process as
opposed to 1.5 - 1.9 MB per process. I've even seen cyrus processes with up
to 30MB.
Now, autologout timeout is required to be at least 30 minutes by section
5.4 of RFC2060, <http://www.apps.ietf.org/rfc/rfc2060.html#sec-5.4>, and
that's the default value of "timeout" in imapd.conf and in perdition.conf.
You could set this to a lower value, but your connected mail clients might
do strange things if connections close unexpectedly.
Is there a way to limit Cyrus process sizes at all? I guess I can take a
look at my compilation options to try to reduce the starting size, but can
I limit the process growth?
--
Ian Eiloart
IT Services, University of Sussex
x3148
More information about the Info-cyrus
mailing list