<quote who="Chris Winterrowd">
> Lee,
>
> 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.
I don't know how our Cyrus IMAP software is built. I've forwarded this
email to our IMAP administrators and hopefully they'll pass the info along
ASAP.
> 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.
Interesting. Our IMAP administrators have commented that the IMAP spec is
followed differently by different IMAP server software developers. It must
make development of a client extremely difficult.
> 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.
According to the latest info given to me by our IMAP administrators, we
assign 10,000 accounts to a single V880 (32G RAM, 4 processors [@ 750 MHz
IIRC]). There's approximately 1000 simultaneous IMAP connections from FAT
clients (Eudora, Apple Mail, Evolution, etc) and 400 connections from
SquirrelMail during the business day. This chews up 22 of the 32G of RAM
and puts average load across the processors at 85% user (The rest divvied
up between system, I/O, and idle).
I'm not the only one with these problems with this setup. If you're not
having problems I feel I'd like to keep the discussion on the list so that
others can see what you've done and what I and others are going through.
Thanks for your help.
Lee
--
Barking moonbat: noun. Someone on the extreme edge of whatever their -ism
happens to be.
Usage:"Definition of a 'barking moonbat': someone who sacrifices sanity
for the sake of consistency"
-Adriana Cronin
-------------------------------------------------------
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
