Re: Hard-limits for kern.maxproc
Re: Hard-limits for kern.maxproc
- Subject: Re: Hard-limits for kern.maxproc
- From: mm w <email@hidden>
- Date: Thu, 29 Jan 2009 18:05:53 -0800
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 <email@hidden> wrote:
> 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
>
--
-mmw
_______________________________________________
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