Re: Hard-limits for kern.maxproc
Re: Hard-limits for kern.maxproc
- Subject: Re: Hard-limits for kern.maxproc
- From: Nathan <email@hidden>
- Date: Thu, 29 Jan 2009 18:41:37 -0700
On Thu, Jan 29, 2009 at 5:47 PM, Andrew Myrick <email@hidden> 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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden