imapd 2.2.10 performance

[Gabriele Bulfon]

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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20100118/6d5bf865/attachment.html