Re: imapd 2.2.10 performance

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <adrieder@xxxxxxxxxxxxxx>
A: info-cyrus@xxxxxxxxxxxxxxxxxxxx
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

[Index of Archives]     [Cyrus SASL]     [Squirrel Mail]     [Asterisk PBX]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [KDE]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux