site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=W2zjzJW8EvAFNyvbtuchA23xebz6BWQXWZAXlVcious=; b=TmitldZQaHrGSLQKhgA46NciHo8YSeMkWNm0CCWWemkOCqGL2JTvYjaM2GbRLzovNn fiLdtX9RvR+pIMyEWRW9YC6/+gWEtMZxJLuqi4t8+bVKIqPVEQWx3Js5K7cpZJY64Nlx CxnKoX1H8gEI6GhyIksYB43oERoYXsT9TK6uI= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Zagf/Y/vvoOgl4JQnbUmRzw97T+o/gFzeo6Mv+wUkiiYie/FH1AZEQtBji4SdNbHOW ylY4aoV1xLWPGYxbwCb0XY3Tvcmz9zUETMfbcZiGI4WbH48Nrd6vnooYNPbGw10whZWo SC6X2UPc6T4GUCgyl4JkUenW38cqnHHfWu59U= Nathan, you are right on those points, the end-user first, the technology is tool to give the opportunity to people to do their job, anyway I don't understand why if you knew this you choose Mac OS server? why have you created an heterogeneous environment, in case of you had already a stable Linux conf / environment that fit to your needs? but anyway I don't think patching the kernel in your environment is the good/right solution, each time you would self-update your Mac OS server you have to rebuild your kernel, making diffs, you paid for an embedded server solution, isn't it tricky? For now, you should keep your Mac OS servers for other jobs and keep your email server env on Linux, and maybe wait for an Apple solution. Cheers! On Thu, Jan 29, 2009 at 5:41 PM, Nathan <nathan.stocks@gmail.com> wrote:

On Thu, Jan 29, 2009 at 5:47 PM, Andrew Myrick <amyrick@apple.com> wrote:

...

Nathan,

On Jan 29, 2009, at 4:29 PM, Nathan wrote:

...

As I stated earlier, it just uses lots of processes, so as soon as we were able to discover that and raise the process limits in the kernel and launchd, all our severe problems disappeared.

I believe that Cyrus has a "maxchild" option that limits the number of processes it uses internally. I'm curious, what is the behavior of Cyrus if you limit it to a few hundred processes in this environment? That seems pretty common based on the conf files that I found with Google, and I would expect Cyrus is capable of handling a few hundred users with a few hundred processes as long as it knows that it can't make more. Is that not the case? Three processes per Mail.app user seems like an awful waste otherwise. Being a kernel engineer, however, my knowledge of IMAP servers is rather limited. Does Cyrus start rejecting connections in that case? Or is performance just unacceptable?

-Andrew

Andrew,

Thank you for your response! First off, let me explain why I'm reluctant to even try to find the answer to what you are curious about:

At our organization, we have experienced an enormous benefit from sub-second delivery of our internal emails. This is made possible by having everyone use IMAP clients that keep their connections open to the mail server, so that when new email is available cyrus literally already has an open connection to the recipient's mail client which it pushes the mail down to. The email response time is _the_ reason that I was able to get justification for the expense of buying an Xserve and administering it in-house, rather than use a much cheaper hosting service located across the nation.

So, with that in mind, if there were any significant portion of our users that were not able to keep a connection open to the mail server, then its entire existence at our organization would be unjustified, and I would be asked to sell it or return it and reinvest the cost into training my staff into either another vendor's solution or putting all the pieces ourselves on a Linux server. We have enough value-adding projects to keep us busy without adding email administration to the mix, that I hoped for a more out-of-the-box solution for email -- and now that the process limit has been raised slightly to solve all of the severe problems (multiple reboots per day, bounced and never-delivered mail, etc) -- my users absolutely love it!

Suffice it to say that I absolutely believe that limit is compiled with a value that's way too low, and I highly encourage a full-scale review of all the related kernel limits (kern.maxfiles, etc.). The bang-for-the-buck that you would get out of that would be enormous--I think that's the root of OS X Server's reputation (among people I've talked to) that it's only suitable for very small organizations.

I'm a big open-source proponent (I have 200 employees on Linux, about 50 on OS X, and nearly three dozen Linux servers -- we're a medium-sized technology/SAS company), so now that I've solved the problem for ME, I'd like to get the problem fixed for everyone else, and the easiest way that I've found to do that in many cases is to push for patches upstream.

As I've never encountered this problem on my linux servers, which have defaulted to a default max process limit of 32,768 ever since they've been on the 2.6 kernel (as far as I'm aware), I am hoping to convince whoever's in charge of xnu to raise kern.maxproc to something more reasonable than 2500.

Then I'll try to get /etc/rc.server to actually work, which should handle the default settings for kern.maxproc and related kernel and launchd limits. See rdar://6536876 for my "side note" which goes into a bit more detail on how it's not actually adjusting the parameters based on the available RAM, even though it's obviously intended to. That radar also contains more of my lengthy rants ;-) [Sorry about the rants, I'm not trying to be offensive or annoying, I just want change!]

And last of all, I appreciate the idea about lowering the amount of processes that cyrus uses, but since that goes counter to my organizations goals of really-dang-fast-email, I don't have the willpower to look into it. I'm reaching the limit of how much I'm willing to push for reasonable fixes for everyone else now that I've already fixed for myself anyway.

~ Nathan _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/openspecies%40gmail.com

This email sent to openspecies@gmail.com

-- -mmw _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com