> > 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.
> > >> 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. > > > So don't use NFS. > 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/