IMAP hibernate and scalability in general

Timo Sirainen tss at iki.fi
Mon Apr 10 23:11:24 EEST 2017


On 10 Apr 2017, at 21.49, Mark Moseley <moseleymark at gmail.com> wrote:
> 
> Timo, any sense on where (if any) the point is where there are so many
> connections on a given login process that it would get too busy to keep up?
> I.e. where the sheer amount of stuff the login process has to do outweighs
> the CPU savings of not having to context switch so much?

There might be some unexpected bottleneck somewhere, but I haven't heard of anyone hitting one.

> I realize that's a terribly subjective question, so perhaps you might have
> a guess in very very round numbers? Given a typical IMAP userbase
> (moderately busy, most people sitting in IDLE, etc), I woud've thought 10k
> connections on a single process would've been past that tipping point.
> 
> With the understood caveat of being totally subjective and dependent on
> local conditions, should 20k be ok? 50k? 100k?

I only remember seeing a few thousand connections per process, but the CPU usage there was almost nothing. So I'd expect it to scale well past 10k connections. I think it's mainly limited by Linux, and a quick google shows 500k, but I guess that's per server and not per process. Still, that's likely not all that many CPUs/processes. http://stackoverflow.com/questions/9899532/maximum-socket-connection-with-epoll <http://stackoverflow.com/questions/9899532/maximum-socket-connection-with-epoll>
> Maybe a better question is, is there anywhere in the login process that is
> possible to block?

Shouldn't be. Well, logging, but all the login processes are sharing the same log pipe so if one blocks the others would block too.

> If not, I'd figure that a login process that isn't using
> up 100% of a core can be assumed to *not* be falling behind. Does that seem
> accurate?

Should be. In general I haven't heard of installations hitting CPU limits in proxies. The problem so far has always been related to getting enough outgoing sockets without errors, which is a server-wide problem. 2.2.29 has one tweak that hopefully helps with that.



More information about the dovecot mailing list