Hey all, im experimenting with dovecot stats service, and graphing the result. My initial results are kind of interesting. Check out this graph showing connected sessions and users: http://grab.by/dReu At first I thought maybe one of our 35 imap servers was having issues sending data, but all individual servers show this patters. Here is a bunch of individual servers: http://grab.by/dReC Anyone have any idea what could cause such a pattern? Maybe dovecot does some cleaning up of idle sessions at specific intervals? Or maybe our loadbalancers do, or the imapdirectors. regards, Cor
On 29.5.2012, at 13.23, Cor Bosman wrote:> Hey all, im experimenting with dovecot stats service, and graphing the result. My initial results are kind of interesting. Check out this graph showing connected sessions and users: > > http://grab.by/dReuHow do you get the list? Are you periodically just getting list of sessions/users with doveadm stats dump?> Anyone have any idea what could cause such a pattern? Maybe dovecot does some cleaning up of idle sessions at specific intervals? Or maybe our loadbalancers do, or the imapdirectors.doveadm stats dump by default dumps a lot of historic data as well. If you want to see only the currently connected sessions/users, add "connected" parameter. Note that I'm not entirely sure what would be the best API for getting the stats. I'm also thinking that for best behavior the stats process should simply be dumping the data to some permanent database, and you'd do the lookups from there. Otherwise data is lost when Dovecot restarts. The dumping to db could already be done with a "doveadm stats dump" cronjob that runs e.g. once a minute. And/or perhaps stats process should be saving its state permanently to /var/lib/dovecot/ and loading it at startup. Still, a permanent DB would probably be better for some purposes.
On 29.05.2012 12:23, Cor Bosman wrote:> At first I thought maybe one of our 35 imap servers was having issues sending data, but all individual servers show this patters. Here is a bunch of individual servers: > http://grab.by/dReC > Anyone have any idea what could cause such a pattern? Maybe dovecot does some cleaning up of idle sessions at specific intervals? Or maybe our loadbalancers do, or the imapdirectors.A shot in the dark ... Maybe some kind of TCP or session timeout on a packet filtering device or loadbalancer? Maybe that time is shorter than the IMAP idle timeout. So TCP connections are "killed". Such a TCP stateful device may not send any active RST packets to the client. This way it's up to the client to recognize a broken TCP connection. This may then only occur when the client believes it's time to renew the IMAP idle and then finds the TCP connection gone. 1) Check the config/logs of any >= layer 4 devices for "session teardown" or "session timeout" 2) Check the dovecot logs and sort certain patterns by the minute. Maybe you find dovecot logging more "client timeout" or "connection reset by peer" at certain minutes than others. Maybe also group by other parts of the log entries such as usernames to find any patterns. 3) Connect to the imap server yourself and sniff an IMAP IDLE session with wireshark. Make sure you use the same path as the users ou there and not bypass the loadbalancer or whatever. Regards Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4076 bytes Desc: S/MIME Cryptographic Signature URL: <http://dovecot.org/pipermail/dovecot/attachments/20120529/cf8d7d54/attachment-0004.bin>