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