Hello,
we're observing a strange issue on our dbmail setup: sometimes accepting an imap connection will take unacceptably long, tens of seconds or even minutes before imap login banner is displayed.
We can't reproduce that in test environment. Running time echo ". logout" | localhost 143 returns as expected within 0.01s. However in production environment we see majority of these return within 0.01s, every now and then there's a period when times go over 20s, longest observed was just over 4 minutes.
I did a strace of dbmail-imap process while running this test in a loop. At that time it was handling about 80 concurrent users (based on netstat established connection list). Once this problem appeared, I checked strace output for clues between last logout and next banner print. However there was nothing between last close() and next accept(), just a bunch of
read|write|[e]poll|futex calls dealing with existing clients. It is as if nothing would get to the socket itself.
Has anyone observed such behaviour? If yes, how did you solve it?
It could save me some digging around src/server.s, libevent docs and kernel networking code to understand what's going on ...
Btw, judging by the mix of poll and epoll calls, there's still some codepath using poll instead of epoll. Is this desired/intended?
El7, kernel 3.10, dbmail 3.2.3, libevent 2.0.21.
--
Jure PeÄar
https://jure.pecar.org
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
we're observing a strange issue on our dbmail setup: sometimes accepting an imap connection will take unacceptably long, tens of seconds or even minutes before imap login banner is displayed.
We can't reproduce that in test environment. Running time echo ". logout" | localhost 143 returns as expected within 0.01s. However in production environment we see majority of these return within 0.01s, every now and then there's a period when times go over 20s, longest observed was just over 4 minutes.
I did a strace of dbmail-imap process while running this test in a loop. At that time it was handling about 80 concurrent users (based on netstat established connection list). Once this problem appeared, I checked strace output for clues between last logout and next banner print. However there was nothing between last close() and next accept(), just a bunch of
read|write|[e]poll|futex calls dealing with existing clients. It is as if nothing would get to the socket itself.
Has anyone observed such behaviour? If yes, how did you solve it?
It could save me some digging around src/server.s, libevent docs and kernel networking code to understand what's going on ...
Btw, judging by the mix of poll and epoll calls, there's still some codepath using poll instead of epoll. Is this desired/intended?
El7, kernel 3.10, dbmail 3.2.3, libevent 2.0.21.
--
Jure PeÄar
https://jure.pecar.org
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail