couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: stray couchjs processes
Date Sat, 16 Apr 2011 12:39:10 GMT
Hi Ning,

the correlation between couchjs and HTTP requests is that whenever a
request needs couchjs for anything, it will use one that is around and
idle. When CouchDB starts, none are idle and it will for and exec a 
new couchjs process. A couchjs process is not idle when a request is
using it. So for every concurrent request, you will get a new fork &
exec of a couchjs process.

I haven't looked at the current implementation in a while, but we
should look into implementing some configurable ceiling that can't
be crossed with more fork & exec. Requests then could either wait
until a couchjs is idle and eventually timeout if none get freed
or they could get served a Service Unavailable (503) — That behaviour
should also be configurable.

CCing dev@ to see if we can get more feedback on this.


On 15 Apr 2011, at 20:16, Ning Tan wrote:

> A while back there was a post about stray couchjs processes that had
> no apparent resolution. A similar situation happened in our
> environment that resulted in hundreds of couchjs processes, which
> caused out-of-memory problems for the server.
> We are investigating the cause and would appreciate any help in
> pinpointing the problem. One thing that was curious to me is, how many
> couchjs processes are needed to support concurrent requests. I
> couldn't reproduce a large number of couchjs processes in my local
> environment. It seems that all my view/filter requests were handled by
> just one couchjs process.
> The environment that had problems was using 1.0.1. I've been testing
> locally with 1.0.2.  Would that make any difference?
> Also, the problematic environment had proxies sitting in front of the
> couch boxes, so that's another variance in our analysis. But it's hard
> to tell without knowing the relationship/cardinality between an HTTP
> connection and a couchjs process. In the original post, connections
> not properly closed were hinted as a potential culprit. However, it's
> still unclear to me how mishandled HTTP connections can result in
> multiple couchjs processes. If I'm not mistaken, couchjs only talks
> via stdin/stdout and is not handling a connection directly.
> Sorry if this question doesn't have enough information. We are still
> in very early stages of our analysis and don't have a lot of leads
> yet.
> Thanks!

View raw message