[Dovecot] Indexing Performance Question (was tpop3d vs dovecot)

Timo Sirainen
Thu, 01 Feb 2007 22:24:42 -0000

On 1.2.2007, at 3.39, Nate wrote:

> 3.  Third connection.  It takes ~40 seconds to display a LIST after
> login.  The index files are untouched; however, during the 40
> seconds I'm waiting, I can catch a few of these in lsof.
> pop3    1971 postfix   10r   REG    8,3    4196 205963 /var/spool/
> mail/test.visp.net/natetest/cur/1157863512.V902I1f3867.s3.visp.net:2,S
>
> This tells me even though there is no new email, it is re-scanning
> the cur/ directory somewhat.  It doesn't take near as long as the
> initial index build, but certainly takes longer than it would for
> the system to read any or all of the listed index files above.  Why
> would dovecot need to even enter cur/ if the index file is up to
> date?  Is it verifying that the index file is up to date by re-
> reading some or all of the many files in cur/?  If so, could it not
> get the info it needs by simply doing the equivalent of a ls, which
> would take considerably less time?

The reason why the messages are read in the first place is because
the message sizes need to be returned so that linefeeds are counted
in CR+LF format, while they're typically stored in LF-only format. So
if Dovecot just stat()ed the file and returned that as the message's
size, it would be violating the POP3 spec. tpop3d seems to be doing
that.

It sounds like dovecot.index.cache file doesn't contain all the
messages' sizes for some reason, and Dovecot goes and re-reads those
files again to get the sizes. I'm not sure why it wouldn't contain
the sizes though, so it sounds like a bug somewhere.

I think this fixes it: http://dovecot.org/list/dovecot-cvs/2007-
February/007582.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20070202/1f9bcc2b/attachment.bin>