Re: Hard-limits for kern.maxproc
Re: Hard-limits for kern.maxproc
- Subject: Re: Hard-limits for kern.maxproc
- From: Nathan <email@hidden>
- Date: Fri, 6 Feb 2009 11:39:20 -0700
On Fri, Feb 6, 2009 at 10:47 AM, Amanda Walker <email@hidden> wrote:
> On Feb 6, 2009, at 12:25 AM, Nathan wrote:
>>
>> I don't follow your logic. How does providing a large amount of
>> services for a smaller amount of users obviously less
>> resource-intensive for a computer than providing only one service for
>> more users in a generalized case?
>
> Because the software that Apple bundles with Mac OS X, and hooks up to their
> GUI management console, tends to use a "fork a process per active user"
> approach (Cyrus for imap, Apache for http, pppd for VPN connections, etc.).
> The process load in particular scales more closely with the number of users
> than the number of tasks a particular user is trying to perform.
Then I doubly don't understand your conclusion. Given a O(1)-ish
amount of processes used per user per task, then 100 users using one
service would use a comparable amount of processes to 10 users using
10 services. Given your argument, I would come to the conclusion that
the OS design is comparably hobbled in both the low-user / multi-use
and high-user / single-use cases.
The fact that Apple's _other_ services also tend to "fork a process
per active user" reinforces what I've been saying and seriously flies
in the face of Apple's stated position. Check this out from the reply
to my radar on this issue:
------------
29-Jan-2009 02:19 PM KIT CHEUNG :
Engineering has requested the following information in order to
further investigate this issue:
1) Use a mail server that starts a thread per client instead of a
process per client
- processes are incredibly wasteful of scarce resources
- this is 2009; threads are "in", even if you don't believe the
future is multicore
[snip]
------------
If you are correct in the fact that in practice leans towards using
processes, then they're seriously pulling in two opposite directions
at the same time. I'm sure there's some analogy I could make with a
yoke of oxen here, but it's escaping me.
> This isn't to say that there's anything inherent (or particularly kernel
> related) about this--Apple could certain switch to using lighttpd for the
> web server, a non-forking imap server for mail, etc. if they thought scaling
> up to lots of users was a priority.
Ya, they could certainly do that. They could also just tweak their
kernel slightly to allow more processes. For a technical list, I've
received an unusual amount of hand-waving to explain away why they
won't do that.
>> I disagree with the "hardware" part of that statement. There's
>> nothing wrong with the hardware from an enterprise standpoint.
>
> I disagree. The XServe is a beautiful box, but it's got poor airflow, high
> noise, lack of lights-out management until very recently, very deep rack
> depth, non-standard drive mounting, and high power consumption. Its main
> advantage is that it runs Mac OS X--for any other application, a box built
> from generic Intel chassis (or equivalent) is more cost effective to manage,
> especially in large quantities.
Fascinating. I guess we'll have to just agree to mostly disagree on
that point, then. My generic rackmount boxes are louder, use the same
amount of power, and each have their own type drive mounting (unless I
get more than one server from the same major chassis vendor). I don't
get my other servers from enterprise suppliers, though. I definitely
agree that the generics are cheaper. Typically about 1/3 the cost for
almost equivalent computing hardware.
>> And NONE of my other
>> servers have bright blue LED cpu usage lights on the front of an
>> aluminum case. :-)
>
> Apple does win on style, I'll grant :-). No large production environment
> I'm aware of cares about style in the data center...
>
>> That's the first time I've heard the enterprise market called
>> low-margin.
>
> I worked for a "white box" integrator for a couple years. The hardware part
> of the enterprise business is commoditized; it's the service, custom
> assembly and configuration, and support side that's where the money is--and
> enterprise service and support is one of Apple's weakest areas.
I'll give you that. I thought you were talking about the margin on
their whole hardware+software package.
> But I'll stop here, since we're clearly in "market positioning" territory.
>
> Going back to kernel geeking: please do share your experience with a
> recompiled kernel, once you've gathered some data. I'm quite curious about
> how well it works--I was only objecting to the idea that Apple should have
> done it out of the box :-).
Absolutely will do, but I don't foresee actually recompiling the
kernel until we start hitting the 2500 process limit.
~ 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