Lee,
I've been following some of your postings reguarding SM and Cyrus.. I don't
claim to have the solution to your troubles, but here at TI, we have a similar
setup and I wanted to ask you how Cyrus is configured in your installation.
The reason I'm replying is because we had a meltdown when upgrading to Cyrus 2.1.x
from the older Cyrus 1.5.x series and while SquirrelMail helped it melt down
quicker, what we found was by shutting down SquirrelMail, the problem didn't go
away.. with an average of 1,100 *active* IMAP connections on a SunFire V880 with 2
processors and 4GB of RAM and insanely fast IO rates, what we discovered was a
problem with using Berkeley DB for a few of the shared databases Cyrus uses
(mailboxes.db in particular) -- there are quite a few notes on the Cyrus mailing
lists about this, and we have since switched to using --with-mboxlist-db=flat and
--with-duplicate-db=skiplist.
Later we learned that increasing cache settings for the Berkeley DB may have bailed
us out (creating DB_CONFIG with 'set_cachesize 0 524288 1' and watching DB Cache
performance with db_stat -m), but after being bitten with Berkely DB, we opted for
flat file storage of the mailboxes.db since it's at least as fast as skiplist for
reads.
Since making these changes, we've turned SquirrelMail back on and the mail server is
screaming along without any performance hits.. in fact, Mozilla is placing more load
on these mail servers because of the default of allowing 5 cached IMAP connections
to the server.
I don't disagree SquirrelMail is quite chatty.. I'm not sure how much of this
chattiness is required.. I remember a thread from one of the fine folks at CMU who
works with the Cyrus project discussing a similar issue - SquirrelMail appeared to
be making too many IMAP calls to get the information it was searching for, and the
SM developers were considering an option to reduce the number of calls for Cyrus
since it provides the results (not dictated by the IMAP RFC) in fewer IMAP calls..
but since this isn't required behavior according to the RFCs, other IMAP server
implementations would not return the necessary data without these extra calls.
I'll be happy to talk with you further about Cyrus and SquirrelMail performance
issues off-list if you would be interested.. hopefully I'm not reiterating
information that you already know! I would also be interested in learning how hard
this V880 is being hit with IMAP traffic and how many IMAP accounts are on this
system.
Anyway, hope this is helpful!
--
Chris Winterrowd
Unix E-mail Administrator
Texas Instruments Inc.
[EMAIL PROTECTED]
> My apologies for the extreme length, but I do want to include what
> information I have.
>
> When Cornell upgraded from SquirrelMail v1.4.1 from v.1.2.11, our IMAP
> servers started to buckle and die under the load from the increased IMAP
> traffic. This server is no slouch (Sun VX880 w/8 processors & 32G RAM) so
> it was very surprising to everyone here that it did happen. I was forced
> to downgrade back to 1.2.11 to reduce the load on the IMAP serer.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
--
squirrelmail-users mailing list
List Address: [EMAIL PROTECTED]
List Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=2995
List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
