echo 65536 > /proc/sys/fs/file-max
My Cyrus box has ~18000 open files right now with 350 imapd processes running, and IIRC the default Linux file-max is 8192.
I talked with a guy from Sendmail, Inc. at LinuxWorld last year and he admitted that their IMAP message store was forked from the 1.x Cyrus tree a while back. They said they saw large IMAP performance improvements when using reiserfs with the 'notail' mount option, versus other Linux filesystems. Reiserfs seems to be much more well-optimized for situations when you have lots of very small files.
-Jules
Jared Watkins wrote:
Hello all...
I'm working on a migration from a single linux Iplanet (aka Netscape aka Sun One) messaging server with Iplanet ldap backend for the user database TO cyrus on linux with an active directory backend. I have about 2500 accounts on this sytem.. and from the mta logs I go through about 100k messages and 5GB a day of mail volume usually with delivery peaks of no more than 300 messages a minute. Most users get their mail via pop.. but we will encourage more of them to use imap along with sieve. We use a wide range of client apps.. all versions of outlook.. outlook express.. eudora.. netscape.. mozilla.. act.. and some others. (This has me most worried) We also require the use of SSL/TLS for any logins from outside our lan.
I'm planning to deliver mail via lmtp from our postfix relays... letting them deal with virtual user/domain issues through ldap lookups... we have only one namespace with the first initial last name style of usernames. I'm already well on my way to finishing some web based cyrus/AD admin tools.. and AD migration scripts...
Hardware wise... it will be dell on either a dual or quad xenon system.. with 2G of ram.. and either an 7 disk local raid array or a FC attached SAN. For the actual data migration... I have a simple plan. Since most people use pop.. I'll just cut mail delivery over to the new system.. and provide a page on our intranet for people to move their old mail from one server to the other.. this way I already have their password since they are logged into our intranet.
Has anyone done a migration like this before? I'm looking for some gotchas or left field sort of problems I may encounter... I've also read some about performance and recovery best practices.. but I'm sure there is more I could learn from all you fine people. I hope to catch most of the problems through my testing process.. but you never really know what you are going to have problems with until it's in the wild of production.
Thanks in advance...
Jared
-- Jules Agee System Administrator Pacific Coast Feather Co. [EMAIL PROTECTED] x284
