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