On Wed, 22 Sep 2004, Timo Sirainen wrote:
On 22.9.2004, at 01:17, dovecot@spam.turbolink.net wrote:
T 192.168.199.48:57262 -> 192.168.196.53:143 [AP] 27 uid store 5957 -Flags (\Seen)..
very large delay here, 60-90 seconds
Hmm. I can't really think of many reasons for this to happen.. Have you set mbox_dirty_syncs=no? If not, try it and see if it makes any difference?
I did try it both ways, because I wasn't sure whether yes or no would produce the behavior described in the example. It didn't seem to make much of a difference.
Only reason why it would do rereading there is if the message wasn't at the expected position in the mbox file. And if no-one else modified the mbox, the only reason for it is if Dovecot had somehow corrupted the message offset in index file.
How/where exactly could I check for these conditions? I'm pretty familiar with gdb but not with the new indexing code. I set a breakpoint on mbox_sync and tried to follow it through but I haven't been able to pinpoint exactly where the decision is made to re-read or not.
Your indexes are stored in NFS too? Have you set mmap_disable=yes then?
No, indexes are not on NFS. I was doing some performance testing with indexes on a local disk (XFS) and also with indexes in a ramdisk, but it occurred with both.
- Mike