On 10 Apr 2017, at 21.49, Mark Moseley <moseleymark@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-ep... <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.