A NOTE has been added to this issue.
======================================================================
http://www.dbmail.org/mantis/view.php?id=539
======================================================================
Reported By: paul
Assigned To: paul
======================================================================
Project: DBMail
Issue ID: 539
Category: IMAP daemon
Reproducibility: always
Severity: minor
Priority: normal
Status: assigned
target:
======================================================================
Date Submitted: 17-Mar-07 16:42 CET
Last Modified: 21-Mar-07 20:34 CET
======================================================================
Summary: Mailclient times out opening large mailboxes
Description:
When a mailclient like Thunderbird opens a large mailfolder with many
unread messages an error is returned to the user saying that opening the
folder takes too long.
======================================================================
----------------------------------------------------------------------
cmayo - 19-Mar-07 20:27
----------------------------------------------------------------------
I see the same timeouts with 2.2.4. Analysing the Postgresql 8.1.8 logs
with pgfouine updating the recent flags with:
update dbmail_messages set recent_flag = 0 where message_idnr in
is taking a lot of time.
----------------------------------------------------------------------
paul - 19-Mar-07 22:11
----------------------------------------------------------------------
Interesting.
As part of this bug I'm actually working on avoiding long-running queries
against the envelope and header caches. Such queries shouldn't scale 1/n
with the number of messages in a mailbox before returning some data to the
client.
At first glance however, your case smells like a different beast.
Why is postgres taking so long to run the update query that flushes recent
flags?
I assume that postgres doesn't suffer from locking issues due to mvcc.
Right?
Are you sure this is the query that is triggering timeouts in the client?
----------------------------------------------------------------------
cmayo - 19-Mar-07 23:20
----------------------------------------------------------------------
Sorry, looks like it was my database getting stale. It did appear to be the
updates activity that were slowing the connection - I could see them by
doing tail -f on the log file, and they would continue for a while even
after the client had timed out.
However, I'd done a vacuum analyze and a vacuum full on my database and it
seems the solution was:
reindex table dbmail_messages
----------------------------------------------------------------------
cmayo - 21-Mar-07 20:34
----------------------------------------------------------------------
Well, performance drops off again and another reindex speeds it up for
while and then it slows. May well be a problem with my database, which I
will keep looking for.
I ended up taking drastic action and patching dbmail-imapsession.c:
@@ -1764,7 +1764,7 @@
int dbmail_imap_session_mailbox_update_recent(struct ImapSession *self)
{
- imap_session_update_recent(self->recent);
+ /* imap_session_update_recent(self->recent); */
g_list_destroy(self->recent);
self->recent = NULL;
Hopefully this hasn't broken anything significant.
Issue History
Date Modified Username Field Change
======================================================================
17-Mar-07 16:42 paul New Issue
17-Mar-07 16:42 paul Status new => assigned
17-Mar-07 16:42 paul Assigned To => paul
19-Mar-07 20:27 cmayo Note Added: 0001927
19-Mar-07 20:28 cmayo Issue Monitored: cmayo
19-Mar-07 22:11 paul Note Added: 0001928
19-Mar-07 23:20 cmayo Note Added: 0001929
21-Mar-07 20:34 cmayo Note Added: 0001933
======================================================================
_______________________________________________
Dbmail-dev mailing list
[email protected]
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
