Re: Hard-limits for kern.maxproc
Re: Hard-limits for kern.maxproc
- Subject: Re: Hard-limits for kern.maxproc
- From: Terry Lambert <email@hidden>
- Date: Fri, 30 Jan 2009 00:25:29 -0800
On Jan 29, 2009, at 10:55 PM, Steve Checkoway <email@hidden> wrote:
On Thu, Jan 29, 2009 at 07:46:59PM -0800, Terry Lambert wrote:
1) Cyrus uses a process per client connection. It could use threads
instead (which would be best), or it could use a process per client
and
route in-bound sockets to the clients server instance using
descriptor
passing over UNIX domain sockets.
Burning a process per connection is a fairly standard thing to do. For
example, apache.
Actually, if you use apache 2.0, it uses threads. If you use antique
apache, it's a work-to-do model, and tends to tear down the connection
each time (HTTP 1.0 spec.) or uses an FSA and chunking (HTTP
1.1spec.). So in the first place, a few engines can handle requests
from a lot if clients, and in the second, the dedicated processes are
typically shirt-lived, unless the are doing something like pushing
video over a multipart/refresh MIME type.
2) Your mail client is incorrectly designed. The IMAP protocol was
specifically designed to allow session multiplexing by transaction
ID over a single connection to the IMAP server from a client.
Unfortunately, the clients I've seen (Mail and Thunderbird, to be
precise) open a new connection for every mailbox. I was bitten by this
even in a single user setting where when I connected to my mail
server, Cyrus was limited in the number of children it would start and
this was--by default--fewer than the number of mailboxes I had.
I was unaware that Mail was being a bad IMAP client. I suppose I
should file a bug.
If Mail does this then you *definitely* should file a bug. He stated
here, and in his numerous posts on the other mailing lists, that he
had only a few Mac OS X client machines, so I had assumed he was
thinking about some other client.
3) Your mail client behaves incorrectly when it can't get a
response; it
opens another connection without closing the first one.
I was going to ask how you were able to make that determination, but
thinking about my experience using Mail, that seems pretty likely.
Mail actually doesn't do this, but the most probable IMAP client on
the mist probable non-Mac OS X platform does...
I'm aware of this because I worked for a company that sold Cyrus-based
mail appliances and started contributing patches to Cyrus in 1996. We
saw this sort of thing all the time with certain mail clients on
certain platforms.
Sometimes connections will get "stuck" and have to be killed manually
(by clicking the stop icon). Sounds like another bug in Mail. Who knew
it was so buggy?!
I wasn't taking about Mail because his clients are predominantly not
Mac OS X based, so they aren't running Mail. If you have problems
with Mail, it's likely the darwin-kernel mailing list is not the most
profitable place to talk about them to get them resolved, and I'd
suggest filing a bug report instead.
-- Terry
_______________________________________________
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