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 01:25:27 -0700
On Thu, Feb 5, 2009 at 6:19 PM, Amanda Walker <email@hidden> wrote:
> On Feb 5, 2009, at 3:48 PM, Rand Childs wrote:
>> One would hope that Apple's Mac OS X designers and developers will
>> eventually provide the same modern kernel resource allocation and
>> configuration features that are already provided in other Unix/Linux
>> operating systems if Apple hopes to be able to sell Mac OS X Server into any
>> kind of serious production environment.
>
> Depends on what you mean by "serious". While Apple marketing strategies are
> probably not terribly on topic for darwin-kernel, I'll make a few
> observations:
>
> - Mac OS X (and as a result Darwin) is aimed at machines with individual
> users.
I think you're trying to say "a small amount of users." I've never
met a user who wasn't individual, yet. :-) I will have to half-agree
with you here.
Apple's positioning always say "workgroup" which implies certainly
sounds "smallish." On the other hand "SMB" meaning small-to-medium
business. On the other hand, according to Apple's own user
registration page (which I've filled out dozens of times), a "medium"
business is 100 to 1000 employees. So according to that definition,
I'm on the lower end of medium.
This page has both "workgroup" and "SMB" references:
http://www.apple.com/server/
> - Mac OS X Server has been primarily aimed at workgroups and small
> enterprises as a multiple-function server, not at large enterprises as a
> single-purpose server for large numbers olf users.
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?
> - Most large enterprises wouldn't even consider Apple hardware for "serious
> production environments", for a wide variety of reasons having nothing to do
> with kernel tunability.
I disagree with the "hardware" part of that statement. There's
nothing wrong with the hardware from an enterprise standpoint.
Standardized parts. Easy to replace the parts with overnight shipping
of an identical part. Support contracts. The same hardware
architecture as everything else. Etc. etc. The only servers that I
have in production that are MORE capable than my Xserve, with respect
to hardware, are my phone server (we record a lot of simultaneous
calls) and my datacenter database server. And NONE of my other
servers have bright blue LED cpu usage lights on the front of an
aluminum case. :-)
> - Apple has never pursued (and has on occasion outright spurned) the
> "serious production environment) because it's a low-margin commodity
> business where Apple's traditional advantages are simply not applicable.
That's the first time I've heard the enterprise market called
low-margin. I agree that Apple hasn't trained their guns on the
enterprise market, though.
> Frankly, if "mail server for thousands of users who depend on instant
> delivery and high availability" is your use case, a Mac OS X Server box is
> just the wrong solution. This is not a failure of Apple OS design, it's a
> failure to pick the right tool for the job.
I disagree with that as well. My hardware is sitting at 1% average
network/cpu/disk usage (99% idle) with my 200 users connected (250
employees, about 200 of them are connected at peak time). It
occasionally spikes up to 10%-ish for a few seconds when someone
emails a really large file to their entire department. I'll hit the
arbitrary process limit long before my hardware suffers. But if I do,
I'll recompile the kernel with higher limits and the machine will keep
on chugging. Sounds like software design issue to me.
This is the second list that I've been repeatedly lambasted as
choosing the wrong tool for the job, though with some simple limit
tweaks the server more than capably handles the job. With a
kernel-recompile the server could handle even more jobs. By the way,
the other list is email@hidden.
~ 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