> You have got to be kidding me. Unless there's actually something which
> requires the files to be rewritten (i.e. an expunge event) then this
> should not happen. Again, Cyrus 2.4.x will be much more efficient in
> this regard, only rewriting if you have explicitly enable immediate
> expunge rather than "default" expunge.
It is a 2.3.16. Tu be sure I have tested again with a fresh downloaded tarball. Just sending a mail in LMTP and opening the mailbox several times (SELECT/CLOSE only)
A binary diff indicated that Generation Number is incremented but nothing else.
A binary diff indicated that Generation Number is incremented but nothing else.
> So don't use NFS.
>> With a 6GB's mailbox that contains almost 100.000 emails. cyrus.index is
>> about 8MB and cyrus.cache is about 120MB
>> - on SELECT nfsstat shows 300 NFS READ => 9600KB on-the-wire NFS READ. OK it
>> is less that the size of cyrus.index and cyrus.cache
>> - on CLOSE nfsstat shows 4105 NFS READ and 4144 NFS WRITE => 2x130MB
>> on-the-wire NFS.
>>
>> In such situation mmap doesn't help because everything is read and write. I
>> hope this behaviour can be optimized.
NFS is not a problem here. I have flushed the buffered cache to see what's happen. Most of the time files are cached by the kernel.
---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
