Re: Hard-limits for kern.maxproc
Re: Hard-limits for kern.maxproc
- Subject: Re: Hard-limits for kern.maxproc
- From: Amanda Walker <email@hidden>
- Date: Fri, 6 Feb 2009 09:47:41 -0800
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.
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.
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.
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.
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 :-).
--Amanda
_______________________________________________
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