Stability of idled
brong at fastmail.fm
Mon Aug 15 13:00:32 EDT 2011
On Mon, 15 Aug 2011 16:57:14 +0300, Pascal Gienger
<pascal.gienger at uni-konstanz.de> wrote:
> Just a little remark:
> We have > 4000 connections in IDLE state(*) and idled works flawlessly.
> I had some headaches because some members of this list pointed out that
> imapd was not tested for thousands of connections.
> It justs works.
> Cyrus IMAPD 2.3.19.
Typo I'm sure ;) I've never seen 2.3.19 in the wild.
> (*) due to a heavily migration to Thunderbird including Lightning
> (connecting to our SOGo servers) in many of the faculty and professors'
I don't believe idled has any real dependency on the number of open
connections for load purposes - just on the number of actions that
happen to idled mailboxes.
Now what you will find is that idled communicates by throwing processes
around, so if you have heavy process churn and a small pid space, then
processes which died without telling idled about their being closed (for
whatever reason - in our case nginx proxy restart usually) then you'll
get random processes being killed by the idled signal monster. It is
kinda happy to throw random SIGUSR1 and SIGUSR2 at processes without
checking first if they're still the same process.
But it's all hash tables internally - there's no reason it won't scale
up to big numbers.
Using Opera's revolutionary email client: http://www.opera.com/mail/
More information about the Info-cyrus