<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">&gt; To be honest - it doesn&#39;t actually hurt too badly once it&#39;s in memory<br>

&gt; cache.  The cyrus.cache file isn&#39;t generally needed to be entirely<br>
&gt; read, and the secret of mmap is that you only read the bits you need<br>
&gt; as you need them - it&#39;s lazily loaded.<br>
<br></blockquote><div>I am fully agree with you. But I don&#39;t know what Cyrus really reads on SELECT to fulfill the mailbox structure. <br>Since strace doesn&#39;t help to see what mmap reads on SELECT, so I made a test on NFS server.<br>
<br>With a 7MB&#39;s mailbox that contains 250 emails. cyrus.index is about 20KB and cyrus.cache is about 350KB.<br>- on SELECT, nfsstat shows 15 NFS READ =&gt; 480KB on-the-wire NFS READ. It seems that both cyrus.cache and cyrus.index are read<br>
- on CLOSE, nfsstat shows 19 NFS WRITE and strace shows that both files are rewritten<br><br>With a 6GB&#39;s mailbox that contains almost 100.000 emails. cyrus.index is about 8MB and cyrus.cache is about 120MB<br>- on SELECT nfsstat shows 300 NFS READ =&gt; 9600KB on-the-wire NFS READ. OK it is less that the size of cyrus.index and cyrus.cache<br>
- on CLOSE nfsstat shows 4105 NFS READ and 4144 NFS WRITE =&gt; 2x130MB on-the-wire NFS.<br><br>In such situation mmap doesn&#39;t help because everything is read and write. I hope this behaviour can be optimized.<br><br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
&gt; There&#39;s no real answer if you&#39;re doing a sort on the messages,<br></blockquote><div>Yes I am worried about IMAP SORT and some poors IMAP clients <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

&gt; unless you go to multiple indexes (a la database engines).  That&#39;s<br>
&gt; a whole different ballgame - but the the multiplier factor gets<br>
&gt; higher.  For sane sizes of N (up to 20-30 thousand messages) the<br>
&gt; O(N) of the way Cyrus does it is cheaper than a more complex<br>
&gt; database.<br></blockquote><div>I don&#39;t think about database but about MapReduce.  <br><br>Sébastien<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<font color="#888888"><br><br>
</font></blockquote><br>
</div><br>