<div style="font-family: Verdana; font-size: 12px;">That's really interesting.<br>Yes, I'll do this, my /iserver/var/imap (config dir) is about 150Mb.<br>I'll have to think about how though...those on VMWare can be done easily, but<br>those on hardware...they usually have 2 partitions (one for the system and a second one<br>for the whole data, taking all the disk space), both mirrored.<br><br>Thanks again for all your answers.<br>Gabriele.<br><div><br>
<table border="1" cellspacing="0">
<tbody><tr>
<td align="right"><a target="_blank" href="http://www.sonicle.com">
<img src="http://www.sonicle.com/images/mailcard.jpg" wid="" th="350" border="0" height="45"></a></td>
</tr>
<tr>
<td align="right">
<font size="1" face="Arial">
Gabriele Bulfon - Sonicle S.r.l.<br>
Tel +39 028246016 Int. 30 - Fax +39 028243880<br>
Via Felice Cavallotti 16 - 20089, Rozzano - Milano - ITALY<br>
<a href="http://www.sonicle.com">http://www.sonicle.com</a>
</font>
</td>
</tr>
</tbody></table></div><tt><br><br><br>----------------------------------------------------------------------------------<br><br>Da: Dietmar Rieder <adrieder@sbox.tugraz.at><br>A: info-cyrus@lists.andrew.cmu.edu <br>Data: 18 gennaio 2010 18.16.35 CET<br>Oggetto: Re: imapd 2.2.10 performance<br><br></tt><blockquote style="border-left: 2px solid rgb(0, 0, 128); margin-left: 5px; padding-left: 5px;"><tt>On 01/18/2010 05:44 PM, Gabriele Bulfon wrote:<br>> Thanx so much for your reply.<br>><br>> Yes, I forgot about some technical details...<br>> Systems are all Solaris 10 5/08, some are x86 multicores, some are sparc<br>> T multicores, some<br>> are virtual servers inside VMWare infrastructure, but I must say the<br>> degradation is almost<br>> the same indipendently of the underlying hardware.<br>> These machines have been changed in time, upgrading to modern hardware<br>> and latest<br>> Solaris 10 releases, everytime by reconstructing all the db from the<br>> imap spool on a fresh<br>> install of our Intranet Server distribution (that contains cyrus and all<br>> the other software).<br>> All the cyrus base runs on top of a ZFS mirrored pool.<br><br>so ZFS....<br>we also hit a huge performance problem when our zpool on which we stored <br>all cyrus data was exceeding 80% of the available space.<br><br>Our soloution was to transfer the data from "configdirectory" (usually <br>/var/imap but see your imapd.conf) to a separate zfs that was big enough <br>to hold all data (from "configdirectory") there and still not being <br>filled up to 80% of the capacity. In our case the data from <br>"configdirectory" is about 500 Mb for ~16k users.<br><br><br>> We never suffered problems from Cyrus, and we never found "imapd" on top<br>> of the processes.<br>> Now these updated machines are running for at least a couple of years<br>> (Solaris 05/08 :) ).<br><br>Did you ever update and/or apply the recommended patches from SUN, there <br>were changes in ZFS.<br><br>> I believe that the degradation has been slowly coming to this point, and<br>> only now<br>> I started to have feedback from users tired of waiting some seconds to<br>> delete and so on.<br><br>I bet it is the same ZFS problem as we had. Try to relocate the data <br>from "configdirectory".<br>It would also be a good idea to install the solaris/zfs updates.<br><br>><br>> I think I should anyway start by upgrading, and then check again.<br>> Do you think I can safely rebuild the new cyrus with the same flags and<br>> make install on my binaries?<br>> This is how I was building my 2.2.10:<br>><br>> ./configure --prefix=/iserver --with-auth=unix --with-ldap=/iserver<br>> --with-bdb=/iserver --with-sasl=/iserver --with-cyrus-prefix=/iserver<br>> --without-snmp --with-openssl=/usr/sfw<br>><br>> The SASL built inside the "iserver" is cyrus-sasl-2.1.20.<br><br>Didi<br>----<br>Cyrus Home Page: http://cyrusimap.web.cmu.edu/<br>Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki<br>List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html<br><br><br><br></tt></blockquote></div>