imapd 2.2.10 performance

[Gabriele Bulfon]

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.
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 :) ).
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 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.
Thanks a lot for your help.
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: Michael Menge
A: info-cyrus at lists.andrew.cmu.edu
Data: 18 gennaio 2010 17.11.55 CET
Oggetto: Re: imapd 2.2.10 performance
Hi,
Quoting Gabriele Bulfon
:
Hi,
in the recent months I started to have performance issues on some
installations
deployed happily for many years.
I tried running a reconstruct of all mailboxes during the weekend,
but no results.
Maybe the amount of mail is now affecting imap performance?
These installations has 50-100 users, many of them keeping 2-8Gb of history.
How can I get back to the normal cyrus performance? (without archiving)
It is hard to help you to fix this issues, without knowing
where the bottleneck is.
So lets try to find the bottleneck. If it was running fine for many
years did the performance droped at one point or did it go down slowly?
What has changed? More users/ larger mailboxes?
Harddisk getting old and slower?
Is the system swaping?
What hardware does this run on?
Which OS?
Which filesystem?
- would reducing checkpoint from 30m to 5m help?
no, these checkpoints are only backups in case databasecorruption.
- would switching db from Berkley to Sleepycat help?
I don't know if Sleepycat is faster than Berkley DB. And i don't
know if your bottleneck is the db-access. You can try to use skiplist
for some dbs but you should combine this with a more recend version of
cyrus, as the
skiplistcode has been improved in the last few versions.
- would an upgrade to 3.x help? (and would just a rebuild work
without any conversion?)
I would guess that upgrading cyrus to 2.3.16 could improve your
performance, nevertheless should you upgrade you cyrus version as your
version is very old.
Cyrus 2.3.16 has many new features i don't want to miss and many bugs
have been fixed since 2.2.10
--------------------------------------------------------------------------------
M.Menge                                Tel.: (49) 7071/29-70316
Universität Tübingen                   Fax.: (49) 7071/29-5912
Zentrum für Datenverarbeitung          mail:
michael.menge at zdv.uni-tuebingen.de
Wächterstraße 76
72074 Tübingen
----
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/da34280e/attachment.html