imap-processes are not terminating

[Enrico Tagliavini]

Hi Jan,

just a guess, I have no experience with such an high amount of users, but
did you tried to disable IDLE in cyrus imap? Now be aware, this is not
really elegant, but probably better than having a server crashing going OOM.

IMAP IDLE is useful because it allows real time notifications, but for that
to happen you need to keep the connection with the IMAP server open all the
time. This might be the cause of the issue. There is not timeout possible
here, the connection is meant to stay there indefinitely. If the client
doesn't disconnect cleanly TCP timeout will apply.

So it is bad to disable, since it is a useful feature, but it can be a
temporary solution (provided this is actually the primary source of the
issue). You should probably evaluate the possibility of moving to a more
powerful server.

Hope it helps.
Best regards.

Enrico

On 2 October 2014 22:04, Jan Kowalsky <jankow at datenkollektiv.net> wrote:

> Hi all,
>
> we have a situation where we see a increasing number of imap-processes
> during the time. It seems that some clients don't terminate their
> connections correctly.
>
> We have about 500 User and on a normal day there are about 150-200
> parallel connections. But there is a increasing number of processes up
> to 30 days and older (if we don't restart cyrus) so that the total
> number of processes reaches more than 1000 and meets the limit of memory.
>
> There are some curiosities: inspecting processes with strace we see,
> that most of them belong to only a few users and again are related to
> only some folder. Most popular: the drafts folder.
>
> Because of the network connections (some are at the same time logged in
> via dsl-provider and g3 networks) we guess they come from smartphone
> clients.
>
> Is there any possibility to set a timeout or a max. duration for an
> connection in cyrus?
>
> Anybody else has the same experience?
>
> Best Regards
> Jan
> _______________________________________________
> users mailing list
> users at lists.kolab.org
> https://lists.kolab.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/users/attachments/20141006/15715b2a/attachment.html>